Re: [TLS] potential attack on TLS cert compression

David Benjamin <> Thu, 22 March 2018 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6C71126D3F for <>; Thu, 22 Mar 2018 09:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.761
X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MaeMUcYm1Aqz for <>; Thu, 22 Mar 2018 09:59:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F1B2120726 for <>; Thu, 22 Mar 2018 09:59:10 -0700 (PDT)
Received: by with SMTP id j4so9661571qth.8 for <>; Thu, 22 Mar 2018 09:59:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TfPX6wrr/e6mac9Cc3lnlMovNos5FV381OZcPxg2m0U=; b=Hkn3QhzMG2t/0Rptoa3IX19VAI2x6oxVc32sKZcIeeVqsYC4ftjkrNHTfzU7O4JokV C7TwgT4EORGkqopleZaO/h7T4wIyTGjcSTB2WtQGziRUY41sh1LPXtiuBkskd5bAoY2g 3Wodu5xjSiSb0IGWFK1vEPv4KOeHs+tvq8Bqw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TfPX6wrr/e6mac9Cc3lnlMovNos5FV381OZcPxg2m0U=; b=My067U854UyYteKqd0r9eboxs4Kad6c93dHgge+UmSbh+A1zxdqjvnztEja85qWyiC TASwiQx2zeQj2r4EzmoWgdTUmWS10RvlXsiiO0tKMd8rPGiEVk2qPfYy3+D58i5LjJle c9PHCy0w3BLvN16TM55fc961m+AovkXY4QgJhlovR7JwBgHYzF2RHG/UxMY6Ieey3NbJ sJspdu4kSLyU7lL41IDe6/agYU9KkCItAHYxb6MES2bN+Y/+fcQW5i1JTtpMKAmieXe0 DL7hS2bZ396QOo+IGUZibLXC+/cxCbypHSmJygzsGoYTh12jCJfO+LJF0uy8TXe2i85o oBUQ==
X-Gm-Message-State: AElRT7GdaSTW3bgj08S0nJoe1WGv3OM9RVKsI+4EI7y3RVC6MkiQeTjT IZK/yBvPzJO/ASd9cQuNP3hugu9IRjDs1IYqOZqfZa4=
X-Google-Smtp-Source: AG47ELspyUVg36kh3KJFhFRsVdx4nAHxLI34fy7zhJppuwtGqkghSPOkDTgWSbyuflBeNGv0TfjeMtLtkFaVm0BtX9o=
X-Received: by with SMTP id z92mr34821579qtc.303.1521737949173; Thu, 22 Mar 2018 09:59:09 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Thu, 22 Mar 2018 16:58:57 +0000
Message-ID: <>
To: Subodh Iyengar <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="94eb2c122928e77e79056803393f"
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 16:59:13 -0000

To make sure I understand the issue, the concern is that your decompression
function provides a chunk-by-chunk interface, there's a bug and the
division into chunks produces a different result? Or are you suggesting
that, with the same chunking pattern, the result is still non-deterministic
somehow? I could imagine the former kind of bug, but I'm not sure about the

If the former, I don't see follow how an attacker might control the
division into records. It's easy in TLS 1.2, but we punted compression from
1.2, and in TLS 1.3, the handshake records are encrypted.

Either way, I'm also not sure I've ever seen a TLS stack that processes
messages chunk-by-chunk. Usually the message is reassembled from multiple
records, if necessary, and then only processed when complete. I'm sure, in
the vast space of implementations, such a stack exists, but it seems the
same transcript consideration then applies without compression. Otherwise
you'd need a correct streaming version of all TLS message parsing, ASN.1,
and whatever else TLS calls into. Those are ad-hoc whereas decompression
implementations are at least intended to stream correctly. (Then again,
decompression is also a bit more complicated, probably.)

Did I understand the issue correctly?

On Thu, Mar 22, 2018 at 12:04 PM Subodh Iyengar <> wrote:

> Antoine and I were discussing draft-ietf-tls-certificate-compression over
> lunch today and we think there could be a potential attack on the current
> scheme which could be fixed with some changes.
> Currently the CompressedCertificate is included in the handshake
> transcript. However let's say a server fragments it's compressed
> certificate message into multiple records, and an attacker has found a
> vulnerability in the decompression function based on the timing in which
> the data is delivered to the decompression function due to a race
> condition. They could manipulate the CompressedCertificate message to
> manipulate the peer to decompress something other than what the sender sent
> even though the handshake transcript remains the same..
> Normally this wouldn't matter if there were only certificates, however we
> have extensions in certificates which could manipulate how certificates can
> be interpreted. This creates a time to check to time to use bug which
> relies on the security of the decompression function to determine the
> security of the TLS exchange.
> This is definitely a far fetched attack I don't think this is desirable to
> base the security of TLS on the security of a decompression function. This
> is probably solvable by hashing in the uncompressed cert message into the
> TLS transcript rather than the compressed message which seems more secure
> because it enforces that the client and server have the same state of the
> uncompressed message.
> Subodh
> _______________________________________________
> TLS mailing list