Where
AND
AND
-Infinity
0
Severity
5.9
Infoleak, CSRF
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Angelo Prado, Neal Harris and Yoel Gluck reported [1],[2] that SSL/TLS attacks are still viable via a "BREACH" (Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext) attack, which they describe as:

While CRIME was mitigated by disabling TLS/SPDY compression (and by modifying gzip to allow for explicit separation of compression contexts in SPDY), BREACH attacks HTTP responses. These are compressed using the common HTTP compression, which is much more common than TLS-level compression. This allows essentially the same attack demonstrated by Duong and Rizzo, but without relying on TLS-level compression (as they anticipated).

BREACH is a category of vulnerabilities and not a specific instance affecting a specific piece of software. To be vulnerable, a web application must:

Be served from a server that uses HTTP-level compression Reflect user-input in HTTP response bodies Reflect a secret (such as a CSRF token) in HTTP response bodies

It is important to note that the attack is agnostic to the version of TLS/SSL, and does not require TLS-layer compression. Additionally, the attack works against any cipher suite. Against a stream cipher, the attack is simpler; the difference in sizes across response bodies is much more granular in this case. If a block cipher is used, additional work must be done to align the output to the cipher text blocks.

CERT has an entry describing the flaw as well [3]. Currently no CVE is assigned as MITRE is attempting to determine whether one CVE will suffice, or whether it will require multiple CVEs (one per affected product). [4]

Mitigations are noted by the researchers as follows

1. Disable HTTP compression. 2. Separate the secrets from the user input. 3. Randomize the secrets in each client request. 4. Mask secrets (effectively randomizing by XORing with a random secret per request). 5. Protect web pages from CSRF attacks. 6. Obfuscate the length of web responses by adding random amounts of arbitrary bytes.

[1] http://breachattack.com/ [2] http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf [3] http://www.kb.cert.org/vuls/id/987798 [4] http://www.openwall.com/lists/oss-security/2013/08/07/1

1 / 2
Source: Red Hat
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203