Re: [TLS] potential attack on TLS cert compression

Subodh Iyengar <> Thu, 22 March 2018 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF8AB126CF6 for <>; Thu, 22 Mar 2018 10:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.712
X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=L5C05fo9; dkim=pass (1024-bit key) header.b=CyE07Mxf
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MqF9vsW4vX7I for <>; Thu, 22 Mar 2018 10:11:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15CC112D96A for <>; Thu, 22 Mar 2018 10:11:38 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w2MH0Bsm027467; Thu, 22 Mar 2018 10:11:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=aa8iOy+O9Y27PtynHpabElNicJOjh+48SDXGhP7kTsk=; b=L5C05fo9QPsYS729WLluKiYxsMrDRcNUuf79H0NfZHyS7LfKJ0pbWhXI0nUKszTtZZU5 K5pBDFviqkWRw2mTTVcPSkYD+C+guD3JZ2qT/1uYvY5dlchGC5DXUtUmL2hPRln9cAWE TQnaaaJMbjRdnq3CnT9L3mir1xU4Teudzb0=
Received: from ([]) by with ESMTP id 2gvg5pg3yp-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Mar 2018 10:11:36 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Mar 2018 10:11:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aa8iOy+O9Y27PtynHpabElNicJOjh+48SDXGhP7kTsk=; b=CyE07Mxfgyh+dDET+ueKojoziJ5r+6R22d3xlUfdC5VXqAj8qiGGLnYlr+0wmGocaAfUgVE8F9ZT+zEAn5ufATNNIKWZsn1WZsbtRO1/E3IwEU448tCIB2T8lkCltrkSH2wQ6VWw8JNj69bh+G/Ycz4jKWgom03hJlw8meesr6I=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Thu, 22 Mar 2018 17:11:33 +0000
Received: from ([fe80::b431:b2fb:1912:34d8]) by ([fe80::b431:b2fb:1912:34d8%17]) with mapi id 15.20.0588.017; Thu, 22 Mar 2018 17:11:33 +0000
From: Subodh Iyengar <>
To: David Benjamin <>
CC: "" <>
Thread-Topic: [TLS] potential attack on TLS cert compression
Thread-Index: AQHTwfUqvzIdgGnQXkqEA9sKCzBOZ6PcejeAgAAAeSM=
Date: Thu, 22 Mar 2018 17:11:33 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2620:10d:c092:180::1:daa7]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1853; 7:OslKHBDYpg0PPj1kccs3nd+GdGR7zO00ocn+74EEpNw7BmthoScCYc1MvNWVzF+LbVxoDef4HVTTtIahf5UcDjAq9gbR7XHNZooYkpxu5N0//TfLfgSOJ7ji7q6Q6CpP6gkwflv4ZgaRhqtR/77qb0drApd2sDUdppVlHZPgkWR/VW+BQmEUJWy0iKqDxwkJB97AQkGOi/ZRLkByeTPY+q9zGptwTdmOCHx002s+XAeK9kpCHUSQz2iF3MYN5pB5; 20:khNUU2264wgLdu/32gyxsjbbvzmWY/njQ3Jl93U79hR6G5iyQ9B7zPj2L6agQoNWlXGxdRrH1Zg3B6/HzVfDkNfzRyYd2uoEdAKogZZkCBIrHgVnepDnHwZSx28vFAbWTyB22wOqkeXBi2yXl7S6bfOIB1kdhYMyQo9Bsy0932k=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 92128b17-d9f4-41da-b6b8-08d59017f6a0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1853;
x-ms-traffictypediagnostic: MWHPR15MB1853:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705)(67672495146484);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(11241501184)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:MWHPR15MB1853; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1853;
x-forefront-prvs: 0619D53754
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(39380400002)(366004)(396003)(189003)(199004)(6606003)(478600001)(19627405001)(7696005)(6246003)(3660700001)(2900100001)(966005)(81166006)(6916009)(8676002)(81156014)(8936002)(59450400001)(25786009)(99286004)(76176011)(105586002)(7736002)(53936002)(74316002)(86362001)(6306002)(54896002)(68736007)(5250100002)(229853002)(53546011)(6436002)(5660300001)(14454004)(6506007)(9686003)(236005)(55016002)(46003)(33656002)(97736004)(102836004)(316002)(606006)(446003)(2906002)(3280700002)(4326008)(6116002)(186003)(106356001)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1853;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: QZl6AevBVevdwUh3x3C7C9jhqK5yMobVmz3fmBIQUgsOnOoC7A8oPcveix7cA2kk9K8R1ecJ519p3I6uWXV+qcH5DCoANiE6f8H3TGpwdzAdFtNMzc8nBsR1j4UZXUt6K5dQP+njFPmSXTW79CXHQfoOD2iLl3rRelbdYUCZ+nAOuch2dbySOgIcSadUm5lK4ZOwDrt4RBPgGd43xcSvbA+F6e58zBmxLCVKPEAWjHgDjxx1Lr/TZi8WBdpsSssQoSA6ifHP74HuepM4xvA56eBv245bU7e/JegE12QGzKBL7eNIcPRYiJftzZYroMgvwvn/CUHrQCsgDJwG7rNNjA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18214B1DCADF9369915DCE0CB6A90MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 92128b17-d9f4-41da-b6b8-08d59017f6a0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2018 17:11:33.7449 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1853
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-22_09:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
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:11:50 -0000

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.

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 😊

Compression libraries can get complicated especially ones that use multiple cores do speed up decompression. It's not necessary that the library does ASN.1 streaming, but you can imagine an implementation where a lower layer could stream the compressed cert message into a uncompressed buffer, and then send the uncompressed buffer to an ASN.1 parser. The attack assumed malleability in the former process because records are already streaming so the data can be parsed in a streaming way.

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.


From: David Benjamin <>
Sent: Thursday, March 22, 2018 9:58:57 AM
To: Subodh Iyengar
Subject: Re: [TLS] potential attack on TLS cert compression

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 latter.

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.


TLS mailing list<><>