BREACH attack

There were some interesting developments with regard to crypto and TLS this year at the BlackHat security conference. This first article is about the BREACH attack, CVE-2013-3587. For background, take a look at my earlier article that talks about TLS encryption algorithms.

BREACH is a refinement of the CRIME and TIME attacks. This attack takes advantage of the side channel information leak caused by compression. In the earlier CRIME attack, the attacker had to use TLS compression, but this attack uses HTTP compression which is very common and used on most pages. The attack recovers secrets from within the HTTP response body. The authors used it onstage to obtain a CSRF token and then to forge a request. I have no doubt this could be used in other ways with other secrets obtained from the response. Note that authentication cookies should not be in most responses, so they are safe for now.

The attack needs a man in the browser (MitB) who can send multiple requests to the same page. The MitB appends some data to the request and watches the size of the response. He makes sequential guesses and looks at the compressed size of the returned page to see if he guessed right.

For example, if your CSRF token on a particular page load is "CSRFToken=badguy", the attacker will cause the response to send an extra "CSRFToken=a" in the response. Let's assume "CSRFToken=" is compressed into 1 byte. Our response page would be 2 bytes larger; one byte for the compressed "CSRFToken=" and one byte for "a". The attacker then causes another load with "CSRFToken=b". This time, the response page is only 1 byte longer, which means that the compression algorithm successfully compressed the whole token. Now the attacker knows the first byte of the token. He starts iteratively guessing again at "CSRFtoken=ba" until he finds the whole string.

Note that this works against HTTP compression or TLS compression. It also works against any cipher.

The authors offer some mitigation options on their page. The easiest is to disable HTTP compression on any user input pages. This may be expensive. Two other suggestions are to separate user content from secrets and to randomize secrets per request. This last may be doable with an iRule, but I haven't tried yet. I also wonder if adding a few bogus secrets on each page would be able to slow the attacker.

So what does this mean to you? My suggestion would be to disable HTTP compression on any user input pages. Static content can continue to be compressed.

We knew this was coming; the CRIME & TIME attacks pointed out that it was possible and they even left room for better attacks. Now we have a proof of concept.

Published Aug 09, 2013
Version 1.0

Was this article helpful?


  • One might be able to quickly mitigate the BREACH attack (CVE-2013-3587) against webserver cookies [fn1] when the webserver is behind an LTM virtual server with an HTTP Profile in two complementary steps:



    1. Add an iRule which hooks HTTP_REQUEST and HTTP_RESPONSE. On HTTP_RESPONSE the iRule should prepend a timestamp to the value element of each Set-Cookie header the webserver sends, and on HTTP_REQUEST the iRule should remove that timestamp (if present [fn1]) from each value in an incoming Cookie header. The reason for all this is just to make sure the values differ from one request/response to another.


    2. Enable 'Encrypt Cookies' in the HTTP Profile for all the cookies. Since the cookies will differ per Step 1, they will be encrypted to different "random-looking" values on each response/request. This completely stymies BEAST-like attacks.



    [fn1] Some web applications expect Javascript to read or write cookies. Such behaviour may be incompatible with the LTM modifying and/or encrypting cookie contents (even though the changes are temporary and invisible to the webserver).
  • Turning off HTTP Compression is not an option. There are many other possible mitigations.



    What is F5 doing to protect their customers against this attack?