Re: [TLS] potential attack on TLS cert compression
* 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
It seems to me that if this is a valid threat model, then all software is potentially vulnerable. 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? On Fri, Apr 20, 2018 at 9:40 AM, Victor Vasiliev wrote: > 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 > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] potential attack on TLS cert compression
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
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
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
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 on behalf of Subodh Iyengar 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 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 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 __
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 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 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&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=yZJNzjyJxeApb_xGj4SpKqxVUsFz0DyksR6sTiyXlR4&s=sdRxUMYuldew6KHHPkg-b0LPwURwzvSq_9t95kFD2ss&e=> ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] potential attack on TLS cert compression
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
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
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