HTTP compression continues to put encrypted communications at risk

Researchers improve the BREACH attack to extract sensitive data from encrypted HTTPS connections faster

Security researchers have expanded and improved a three-year-old attack that exploits the compression mechanism used to speed up browsing in order to recover sensitive information from encrypted Web traffic.

The attack, known as BREACH, takes advantage of the gzip/DEFLATE algorithm used by many Web servers to reduce latency when responding to HTTP requests. This compression mechanism leaks information about encrypted connections and allows man-in-the-middle attackers to recover authentication cookies and other sensitive information.

The BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) attack was first presented at the Black Hat USA security conference in August 2013 by security researchers Angelo Prado, Neal Harris and Yoel Gluck. While it theoretically affects all SSL/TLS ciphers, their version of the attack was most effective against connections encrypted with stream ciphers, such as RC4.

Another team of researchers, Dimitris Karakostas from the National Technical University of Athens and Dionysis Zindros from the University of Athens, have since made improvements to BREACH that make it practical for attacking TLS block ciphers, like AES, that are more commonly used today than RC4.

Karakostas and Zindros presented their BREACH optimizations at the Black Hat Asia security conference last week and also released an open-source framework called Rupture that can be used to launch such compression-related attacks.

Their presentation included two proof-of-concept attacks against Gmail and Facebook Chat to demonstrate that many websites, including some of the most security-conscious ones, are vulnerable.

BREACH requires the attacker to be in a network position that allows the interception of a victim's Web traffic. This can be achieved on an wireless network, by compromising a router, or higher up in the Internet infrastructure by ISPs or intelligence agencies like the NSA.

The attacker will then have to find a vulnerable part of an application that accepts input through an URL parameter and reflects that input somewhere into the encrypted response.

In the case of Gmail, the researchers found that the search function on its mobile site allowed for such input reflection: a search string passed through an URL parameter was included in the response page, for example in a message saying that there were no results for that particular string. Also, if the request was made from an authenticated session, the response also included an authentication token identifying that session.

The way gzip compression works in HTTP is that, if there are multiple instances of the same string in a response, the first instance is kept and the rest will be replaced with short references to the first instance's location. This reduces the size of the response.

Therefore, in the Gmail case, if the user searches for the exact string that matches the authentication token -- or even a portion of it -- there would be two instances of the same sequence of characters in the response. Because of compression, the response would be smaller in size than other responses for a different search string.

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 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.

This mechanism was primarily intended to protect against cross-site request forgery (CSRF) attacks, but breaks BREACH as well, because the attack relies on a similar method of initiating rogue cross-site requests.

Google Chrome will enable support for same-site cookies in version 51, which will reach stable status in May. However, unless the mechanism is implemented in all browsers there will be little incentive for website owners to start using the new "SameSite" flag for their cookies.

Join the CSO newsletter!

Error: Please check your email address.

Tags securityHTTPencryption

More about FacebookGoogleNSA

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Lucian Constantin

Latest Videos

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

  • 150x50

    IDG Live Webinar:The right collaboration strategy will help your business take flight

    Speakers - Mike Harris, Engineering Services Manager, Jetstar - Christopher Johnson, IT Director APAC, 20th Century Fox - Brent Maxwell, Director of Information Systems, THE ICONIC - IDG MC/Moderator Anthony Caruana

    Play Video

More videos

Blog Posts