Re: [TLS] TLS 1.3 - Support for compression to be removed

[Jeffrey Walton <[e-mail]>]

>> An even more executive-level lesson might be that security layers should
>> not provide non-security services, but that is not really convincing because
>> if there was a separate compression layer that you could compose with the
>> security layer in TLS, CRIME would still be possible. To compress HTTP
>> without the danger of CRIME you need to either not compress header fields
>> with sensitive information, not compress header fields that might be
>> controlled by an attacker, or at least delegate those to a separate
>> compression state.
>
>
> The attack you're describing (or one fairly close to it) already happened,
> and it's called BREACH. It impacts HTTP compression, and allows attackers to
> recover things like CSRF tokens in page bodies.
>
> The takeaway for me is you can't mix compression, any fixed value an
> attacker wishes to learn, and attacker-controlled data, or there will be a
> compression side-channel.

Is that necessarily true?

Deflate violates semantic security by allowing the attacker to gain
information across messages (even though any single message is
secure). So perhaps its the mode of compression ot the way compression
was implemented, and not compression itself.

Jeff