10

It has been one year since BREACH made our way into our hearts, and there does not seem to be any articles or posts or patches since then, is my Google-fu weakening?

  1. Has BREACH been mitigated or patched in Apache/nginx?
  2. Can we enable GZIP on SSL if we provide further protections?

migrated from stackoverflow.com Aug 18 '14 at 2:39

This question came from our site for professional and enthusiast programmers.

10

BREACH is a vulnerability that is present when several conditions are met:

  • HTTP compression is used,
  • A part of the input is reflected,
  • A static secret is present in the HTTP body of the response,
  • The attacker can read the size of the encrypted response,
  • The attacker can forge requests to the site under attack.

Each of these conditions pose no threat in themselves, but combined they lead to a vulnerability. This is partly the reason that there is no clear-cut solution to this vulnerability: simply upgrading Apache or OpenSSL is not enough. Disabling gzip compression for everything does not make much sense. Reflecting user input is totally fine most of the time. There is not really a simple solution, but there has been made some progress in the last years to mitigate BREACH.

One of the most promising solutions is the same-site cookie flag. This makes cookies no longer work on cross-origin requests, which solves CSRF-attacks and thus also BREACH. Somebody is working on a specification and it is already implemented in Chrome, Firefox, and Edge on Windows 10.

There are also several projects that randomize the response length. Some modules put a random HTML comment in each response, which is a total hack. Padding support has been formalized in TLS 1.3, but it will take some time before that is implemented in servers.

Some frameworks have also taken steps to mitigate BREACH attacks, particularly to prevent guessing of the CSRF token. Django randomizes the CSRF token on each request, so that it can not be guessed over multiple requests. This is relatively new, released this year in Django 1.10.

There has also been some progress for attackers. This year researchers have shown that BREACH can also be converted to a timing attack (HEIST), where it is exploitable by just running Javascript in the browser. Finally, a new toolkit (Rupture) has also been developed this year to exploit compression side-channel vulnerabilities.

  • It's been two years since this answer, any updates? – Element Zero Oct 14 '18 at 3:40
  • SameSite cookies are now supported in more browsers. I've edited the answer accordingly. – Sjoerd Oct 15 '18 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy