This attack is compression at the application layer not ssl compression. TLS fails to protect the application layer data. On Aug 6, 2013 10:18 AM, "Viktor Dukhovni" <openssl-us...@dukhovni.org> wrote:
> On Tue, Aug 06, 2013 at 09:20:06AM -0500, Rodney Beede wrote: > > > Why can't we get a simplified version of TLS that has only one option of > > the most secure cipher and isn't vulnerable to things like BEAST, CRIME, > or > > BREACH? > > These are not TLS problems, these are a special case of cross-site > HTML/HTTP problems, that TLS fails to exclude. Most application > protocols are not subject to the chosen plaintext injection attacks > facilitated by browsers. > > > Could we define a TLS version 2.0 with one cipher that was not vulnerable > > and one simple config? All clients would simply be vulnerable until they > > upgraded or patched to support TLS 2.0. For web servers that don't > support > > the fixed and simplified version have the browser show a warning that the > > site is not secure regardless whether or not the ssl cert is valid. > > TLS can't prevent all problems with HTTP. Avoiding compression > helps. Browsers should disable compression at the TLS layer, and > let the application layer handle compression when applicable. > > When I compiled OpenSSL for previous employer, I always disabled > compression, even before the various compression attacks were made > public. I always thought that compression belonged elsewhere in the > protocol stack, and the SSL layer never had enough information about > whether to optimize for bandwidth or CPU cost. > > -- > Viktor. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
