Users login

Create an account »


Users login

Home » Hacking News » Hacking HTTPS in under 30 seconds

Hacking HTTPS in under 30 seconds

by Nikola Strahija on August 6th, 2013 Department of Homeland Security issued an on Friday (02 Aug) following a vulnerability disclosure in all versions of the transport layer security (TLS) and secure sockets layer (SSL).

The vulnerability is called Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH attack). A sophisticated attacker may be able to derive plaintext secrets from the ciphertext in an HTTPS stream with all protocols (TLS and SSL) being vulnerable.

The full details of the vulnerability were disclosed Thursday (01 August, 2013) at Black Hat conference in Las Vegas by Angelo Prado (Salesforce), Neal Harris (Square) and Yoel Gluck (Salesforce).

How does it work?

An attacker can learn information about the HTTPS responses by injecting plaintext into an HTTPS request and measuring its size. To recover a particular secret in an HTTPS response the attacker needs to guess each character by sending a pair of requests for each guess.
The correct guess will result in a smaller HTTPS response.

The first request includes a payload of the form of:
target_secret_name=<already known part of secret>+<guess>+<padding>

while the second payload looks like this:

target_secret_name=<already known part of secret>+<padding>+<guess>

If the size of the first HTTPS response is smaller than the second one, this indicates that the guess has a good chance of being the correct candidate. If multiple candidates are found, move forward in parallel with both candidates until it becomes clear which guess is correct.

With a token of length 32 and a character space of size 16 (for example hex), the attacker needs an average of approximately 1,000 HTTPS request if no recovery mechanisms are needed. "In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests."

Google Chrome or IE are able to issue this number of requests in under 30 seconds including callbacks.

To conduct this attack the following conditions must be true

1. HTTPS-enabled target (ideally with stream ciphers like RC4, although this 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 (deftlate, gzip)
4. A request parameter is reflected in the HTTPS response body
5. A static secret in the body (CSRF token, sessionId, VIEWSTATE, etc.) that can be bootstrapped (either first/last two characters are predictable and/or the secret is padded with something like KnownVariableName=""
6. An otherwise static or relatively static response. Dynamic pages do not defeat the attack, but make it much more expensive.

Prado and his fellow researchers have promised to release a related tool to allow businesses to test whether their sites are susceptible to a BREACH-style attack.

Some workarounds

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 attacksw
6. Obfuscate the length of web responses by adding random amounts of arbitrary bytes

Newsletter signup

Signup to our monthly newsletter and stay in touch with IT news!

Free E-books

We've got ebooks! But they're not online. :( Please give us a few days to bring downloads back.


Have something to say or just wanna drop us a line? Please keep this in mind: to spam, we reply with spam.

Contact us »