BREACH Compression Attack Steals SSL Secrets

msm1267 writes "A serious attack against ciphertext secrets buried inside HTTPS responses has prompted an advisory from Homeland Security. The BREACH attack is an offshoot of CRIME, which was thought dead and buried after it was disclosed in September. Released at last week's Black Hat USA 2013, BREACH enables an attacker to read encrypted messages over the Web by injecting plaintext into an HTTPS request and measuring compression changes. Researchers Angelo Prado, Neal Harris and Yoel Gluck demonstrated the attack against Outlook Web Access (OWA) at Black Hat. Once the Web application was opened and the Breach attack was launched, within 30 seconds the attackers had extracted the secret. 'We are currently unaware of a practical solution to this problem,' said the CERT advisory, released one day after the Black Hat presentation."

Re:Why use HTTP Compression?

[mstefanro]

Open the Net panel of Firebug on this page and then refresh it a couple of times. Order the HTTP requests by Size. You will see that the HTML of this page is takes the vast majority of bandwidth. Images are simply a "304 Not modified", whereas the HTML is a "200 OK" of ~41KB at this time.
So in case of Slashdot, HTML is the bandwidth bottleneck, not images.

Re: Seems pretty dangerous

[mstefanro]

This attack has little to do with SSL itself or the cryptosystems used. It's more about the preservation of size when encrypting. Combined with compression, information about the amount of entropy in the plaintext is leaked. If you are allowed to manipulate parts of the plaintext a lot of times, then amount of entropy leakage provides with an answer to the question "does the injected substring appear anywhere else in the plaintext?".

Re:Piece of Cake

[phantomfive]

Here's the list of requirements from CERT. All of these must be true for the attack to work. From this list, a creative person could think of many ways a website could avoid this exploit, but it's harder for the client.

1. HTTPS-enabled endpoint (ideally with stream ciphers like RC4, although the attack can be made to work with adaptive padding for block ciphers).
2. The attacker must be able to measure the size of HTTPS responses.
3. Use of HTTP-level compression (e.g. gzip).
4. A request parameter that is reflected in the response body.
5. A static secret in the body (e.g. CSRF token, sessionId, VIEWSTATE, PII, etc.) that can be bootstrapped (either first/last two characters are predictable and/or the secret is padded with something like KnownSecretVariableName="".
6. An otherwise static or relatively static response. Dynamic pages do not defeat the attack, but make it much more expensive.

Re:Piece of Cake

[viperidaenz]

Client protection is simple. Disable HTTP content compression using the Accept-Encoding HTTP request header.

Re:Piece of Cake

[Anonymous Coward]

what do i modify it to?

gzip;q=0,deflate;q=0