Re: [TLS] potential attack on TLS cert compression

[Ilari Liusvaara <[e-mail]>]

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