Re: [TLS] potential attack on TLS cert compression

[Salz, Rich]

  *   TLS records are carried over TCP segments. What if an attacker can change 
the way records are divided into segments, and thereby trigger a bug in the 
record parser?

Why do you think this is possible?  The sizse of the record is part of what’s 
secured.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] potential attack on TLS cert compression

[Victor Vasiliev]

Did we ever reach any agreement about what to do here?

For me, the threat model here seems fairly far-fetched and infeasible, in
the sense that the threat only exists in some very specific bugs in
multithreaded decompressor.

I'd be less reluctant to do this if it were not for the fact that all
solutions I've considered for this are quite annoying.  Putting the hash on
the wire means wasting bytes, and altering the transcript hash introduces a
lot of complexity into some implementations.

On Thu, Mar 22, 2018 at 11:39 AM, Thomas Pornin  wrote:
>
> 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.
>

This is roughly my intuition -- you could parse certificate messages in a
streaming manner, but if you're on a sufficiently limited platform that
this is a worthwhile investment, you're probably not going to use
certificate compression anyways.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] potential attack on TLS cert compression

[Thomas Pornin]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] potential attack on TLS cert compression

[Ilari Liusvaara]

On Thu, Mar 22, 2018 at 05:11:33PM +, 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] potential attack on TLS cert compression

[Subodh Iyengar]

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 <tls-boun...@ietf.org> on behalf of Subodh Iyengar <sub...@fb.com>
Sent: Thursday, March 22, 2018 10:11:33 AM
To: David Benjamin
Cc: tls@ietf.org
Subject: [Potential Spoof] Re: [TLS] potential attack on TLS cert compression


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 <david...@chromium.org>
Sent: Thursday, March 22, 2018 9:58:57 AM
To: Subodh Iyengar
Cc: tls@ietf.org
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 
<sub...@fb.com<mailto:sub...@fb.com>> 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 u

Re: [TLS] potential attack on TLS cert compression

[Subodh Iyengar]

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 <david...@chromium.org>
Sent: Thursday, March 22, 2018 9:58:57 AM
To: Subodh Iyengar
Cc: tls@ietf.org
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 
<sub...@fb.com<mailto:sub...@fb.com>> 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
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=yZJNzjyJxeApb_xGj4SpKqxVUsFz0DyksR6sTiyXlR4=sdRxUMYuldew6KHHPkg-b0LPwURwzvSq_9t95kFD2ss=>
___
TLS mailing list
TLS@ietf.or

Re: [TLS] potential attack on TLS cert compression

[Ilari Liusvaara]

On Thu, Mar 22, 2018 at 04:58:57PM +, David Benjamin wrote:
> 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.

As I read it, it was the latter: Nondeterministic result with the same
chunking.
 
> 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.)

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] potential attack on TLS cert compression

[David Benjamin]

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.
>
>
> Subodh
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] potential attack on TLS cert compression

[Subodh Iyengar]

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls