Re: [TLS] potential attack on TLS cert compression

Thomas Pornin <pornin@bolet.org> Thu, 22 March 2018 18:40 UTC

Return-Path: <pornin@bolet.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A73126D85 for <tls@ietfa.amsl.com>; Thu, 22 Mar 2018 11:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZbEoxwm8kun for <tls@ietfa.amsl.com>; Thu, 22 Mar 2018 11:40:13 -0700 (PDT)
Received: from brontes.bolet.org (www.bolet.org [62.210.214.227]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51B21242EA for <tls@ietf.org>; Thu, 22 Mar 2018 11:40:12 -0700 (PDT)
Received: by brontes.bolet.org (Postfix, from userid 1000) id 2054620383; Thu, 22 Mar 2018 19:39:41 +0100 (CET)
Date: Thu, 22 Mar 2018 19:39:41 +0100
From: Thomas Pornin <pornin@bolet.org>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20180322183941.GA31902@bolet.org>
References: <MWHPR15MB1821D5D75667B3C8F4132A1EB6A90@MWHPR15MB1821.namprd15.prod.outlook.com> <CAF8qwaBgpMnQ=dNgMOZrQRGwQUEswQiz6hDkyNiDVJXvh36X6A@mail.gmail.com> <20180322171000.GA23594@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180322171000.GA23594@LK-Perkele-VII>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zCxyy1WmWjewXcn3tJwFssyzKY4>
Subject: Re: [TLS] potential attack on TLS cert compression
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2018 18:40:15 -0000

On Thu, Mar 22, 2018 at 07:10:00PM +0200, Ilari Liusvaara wrote:
> I think BearSSL processes messages chunk-by-chunk. I think it even can
> process individual X.509 certificates chunk-by-chunk.

That's correct. In fact, it can process a complete handshake, including
the X.509 certificate chain, even if each individual byte is sent in its
own record. The only elements that are reassembled in memory are public
keys and signature values, on which I can enforce strict size limits
(e.g. at most 512 bytes for a signature, which is good for up to
RSA-4096).


> The reason why chunk-by-chunk processing is so rare is how difficult it
> is to program.

BearSSL does that by doing all the parsing in a dedicated coroutine,
which is itself implemented with a Forth-like language. This allows a
"normal", nested parsing that can be interrupted and resumed at will, as
data bytes become available.


Certificate compression would be challenging to implement, though.
Usually, compression relies on at least a "window" over the decompressed
data (32 kB for Zlib/Deflate). Some rudimentary forms of compression
don't need that (e.g. run-length encoding) but usually offer poor
compression ratios. A 32 kB window is a lot for the kind of architecture
that BearSSL targets.


	--Thomas Pornin