Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

HTTP compression continues to put encrypted communications at risk

Lucian Constantin | April 5, 2016
Researchers improve the BREACH attack to extract sensitive data from encrypted HTTPS connections faster

With BREACH, the goal of the attacker is to trick the user's browser to send a large number of requests to a vulnerable application -- like the mobile search feature in Gmail -- with the goal of guessing the authentication token. The authentication token would be encrypted in the response, but every time the search string would match a bit of the authentication token, the response observed over the wire would be smaller.

This eventually allows the sequential guessing of every character in the authentication token by constantly modifying the search string in new requests to include the already discovered characters. It is essentially a brute-force attack on every character, with variations in HTTP compression serving as success indicators.

The Rupture framework allows the attacker to inject rogue code into every unencrypted HTTP connection opened by a user's browser. That code is designed to force the browser to make requests to a vulnerable HTTPS application in the background.

Unlike stream ciphers, block ciphers introduce noise into responses because they add dummy bits known as padding to data before encrypting it, so that it can be split into blocks of a specific size. Canceling out this noise and recovering the encrypted data using the BREACH technique requires executing a significantly larger number of requests than would be necessary had the same data been encrypted with a stream cipher.

At first glance this would appear to make the attack less practical. However, Karakostas and Zindros have devised a statistical-based method of bypassing the noise by calculating the mean response length of multiple responses sent for the same tested character. They also made other optimizations and introduced browser parallelization that drastically improve the original attack's speed against TLS connections that use block ciphers.

Three years later after BREACH was announced, RC4 is considered unsafe and most websites use the AES block cipher, the researchers said in their technical paper. "Some services, such as Facebook, also went on to incorporate mechanisms to prevent BREACH. However, the fundamental aspects of BREACH are still not mitigated and popular websites, including Facebook, continue support for vulnerable end-points."

"Our work demonstrates that BREACH can evolve to attack major web applications, confirming the fact that TLS traffic is still practically vulnerable," the researchers concluded.

A proposed Internet standard called first-party or same-site cookies could protect websites against the BREACH attack. If adopted by browsers, this mechanism would prevent cookies from being included in requests sent to a website if those requests were initiated by a different website.

That is, if code on site A instructs the browser to initiate a request to site B, that request will not include the user's authentication cookie for site B, even if the browser does have an active, authenticated session with site B.


Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.