Subject: [TLS] potential attack on TLS cert compression

From: Subodh Iyengar <[email-masked]>
Date: Thu, 22 Mar 2018 16:03:00 +0000

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

---

From: David Benjamin <[email-masked]>
Date: Thu, 22 Mar 2018 16:58:57 +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
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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 22 Mar 2018 19:10:00 +0200

> somehow? I could imagine the former kind of bug, but I'm not sure about the

As I read it, it was the latter: Nondeterministic result with the same
chunking.
 
> decompression is also a bit more complicated, probably.)

I think BearSSL processes messages chunk-by-chunk. I think it even can
process individual X.509 certificates chunk-by-chunk.

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

-Ilari

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 22 Mar 2018 17:11:33 +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.

Subodh

________________________________
From: David Benjamin <[email-masked]>
Sent: Thursday, March 22, 2018 9:58:57 AM
To: Subodh Iyengar
Cc: [email-masked]
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.)

On Thu, Mar 22, 2018 at 12:04 PM Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

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

Subodh

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=yZJNzjyJxeApb_xGj4SpKqxVUsFz0DyksR6sTiyXlR4&s=sdRxUMYuldew6KHHPkg-b0LPwURwzvSq_9t95kFD2ss&e=>

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 22 Mar 2018 17:18:16 +0000

Former and latter is a horrible way to refer to attacks :)
what I really meant is that when a receiver processing of timing of same TLS record chunks triggers a bug in the decompressor.

Subodh

________________________________
From: TLS <[email-masked]> on behalf of Subodh Iyengar <[email-masked]>
Sent: Thursday, March 22, 2018 10:11:33 AM
To: David Benjamin
Cc: [email-masked]
Subject: [Potential Spoof] Re: [TLS] potential attack on TLS cert compression

Subodh

Subodh

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 22 Mar 2018 19:19:59 +0200

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.

-Ilari

---

From: Thomas Pornin <[email-masked]>
Date: Thu, 22 Mar 2018 19:39:41 +0100

> 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

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