Re: [TLS] potential attack on TLS cert compression

Ilari Liusvaara <> Thu, 22 March 2018 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 820EF126B6D for <>; Thu, 22 Mar 2018 10:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F2g0ka0kwjcG for <>; Thu, 22 Mar 2018 10:20:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B5C4126579 for <>; Thu, 22 Mar 2018 10:20:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C7B481837; Thu, 22 Mar 2018 19:20:03 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id pl5ufqBR5N8M; Thu, 22 Mar 2018 19:20:03 +0200 (EET)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1C18A79; Thu, 22 Mar 2018 19:20:00 +0200 (EET)
Date: Thu, 22 Mar 2018 19:19:59 +0200
From: Ilari Liusvaara <>
To: Subodh Iyengar <>
Cc: David Benjamin <>, "" <>
Message-ID: <20180322171959.GA23663@LK-Perkele-VII>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <>
Subject: Re: [TLS] potential attack on TLS cert compression
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Mar 2018 17:20:06 -0000

On Thu, Mar 22, 2018 at 05:11:33PM +0000, Subodh Iyengar wrote:
> Ya I think you have the right idea. The former attack is the one
> that I'm more concerned about, i.e. compression libraries almost
> always provide streaming interfaces. Another case is that TLS
> implementations which are the users of some decompression api
> might also provide the frames to the decompression library in
> non-deterministic order.

I could understand bugs like that in DTLS (and those are unlikely
even there), but not TLS 1.3. The TLS 1.3 datastream is always
processed in-order. 

> With draft-25 we've authenticated the record header so the
> attacker can't force the data to be processed in a different
> chunking than the server which is why I mentioned that the only
> leverage the attacker has is timing. We missed the draft-23
> bus on pointing out the attack 😊

The fixes in draft-25 only concern changing the ignored parts
of the record header. The implicit sequence numbers prevent
reordering in TLS 1.3 (and have for a long time).

> Compression libraries can get complicated especially ones
> that use multiple cores do speed up decompression. 

Multithreading with language that can not reason about multithreading
(or other forms of concurrency) is hard. And very few languages can
reason about multithreading.
> I admit this depends on the implementation and various other magic
> factors, however it seems unfortunate to base the security of TLS
> on the security of the decompression function and the way that an
> implementation might use the decompression function, when there
> seems to be a simple? way to solve it.

AFAIK, Altering handshake messages for handshake transcript in the
middle of it is unprecidented in TLS.