Yea, I mean BREACH. When the framing is in the clear, one cannot hide the fact that one is adding padding, and/or how much. Having the bytestream be opaque allows the server/client to add padding and thus at least linearly increase the amount of effort needed to verify a hypothesis against a compression context. -=R On Tue, Nov 19, 2013 at 8:30 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Nov 19, 2013 at 05:03:35PM -0800, Roberto Peon wrote: > > > reducing jitter and increasing throughput/goodput. Exposing the > > framing/length of things that would be in an encrypted-by-TLS bytestream > > today, however, does worry me-- it makes BEAST/CRIME-like attacks > > significantly more difficult to protect against. > > You mean BREACH/CRIME (the two attacks exploiting compression), right? > BEAST was bad use of CBC mode and has seemingly nothing to do with > compression. > > Also, I don't think even HTTP/2.0 style muxing would help with > adaptive compression attacks (like BREACH and CRIME) unless the > target site is being actively used. > > -Ilari >
Received on Wednesday, 20 November 2013 04:57:02 UTC