Two researchers have developed a new attack on TLS 1.0/SSL 3.0 that enables them to decrypt client requests on the fly and hijack supposedly confidential sessions with sensitive sites such as online banking, e-commerce and payment sites. The attack breaks the confidentiality model of the protocol and is the first known exploitation of a long-known flaw in TLS, potentially affecting the security of transactions on millions of sites.

The attack, developed by Juliano Rizzo and Thai Duong, will be presented at the Ekoparty conference in Argentina on Friday, and, unlike many other attacks on TLS and SSL, it has nothing to do with the certificate trust model in the protocol. Instead, the researchers have developed a tool called BEAST that enables them to grab and decrypt HTTPS cookies from active user sessions. The attack can even decrypt cookies that are marked HTTPS only from sites that use HTTP Strict Transport Security, which forces browsers to communicate over TLS/SSL when it’s available.

The researchers use what’s known as a block-wise chosen-plaintext attack against the AES encryption algorithm that’s used in TLS/SSL. In order to execute their attack, Rizzo and Duong use BEAST (Browser Exploit Against SSL/TLS) against a victim who is on a network on which they have a man-in-the-middle position. Once a victim visits a high-value site, such as PayPal, that uses TLS 1.0, and logs in and receives a cookie, they inject the client-side BEAST code into the victim’s browser. This can be done through the use of an iframe ad or just loading the BEAST JavaScript into the victim’s browser.

After the BEAST agent is loaded, the second part of the tool, a network sniffer, looks for active TLS connections and then grabs and decrypts the HTTPS cookie, enabling the attacker to hijack the victim’s session with that site. Once that encrypted connection with the site is established, the victim can move off to another tab or do other things on the machine and the attack will still work. The attack forces the browser to load pages from the target site, and the tool then decrypts the first part of the request to the Web server, which includes the secure cookie. The researchers have the ability to decrypt those cookies from within SSL sessions, which essentially negates the confidentiality promise of the protocol.

The decryption process is fast enough that it’s likely imperceptible users, and the researchers said that in a targeted attack, they likely could steal the cookie from a specific site within five minutes of loading the tool. Rizzo and Duong said that their attack exploits a vulnerability in the TLS 1.0 protocol that has been known for quite some time, but was thought to be unexploitable.

“It is worth noting that the vulnerability that BEAST exploits has been presented since the very first version of SSL. Most people in the crypto and security community have concluded that it is non-exploitable, that’s why it has been largely ignored for many years. Our work has two contributions,” Duong said in an email interview. “We introduce a practical and efficient plaintext-recovery attack for that vulnerability. It’s an enhancement of something crypto people call ‘block-wise chosen-plaintext attack’. We present one application the attack: BEAST. BEAST focuses on SSL implementations on browsers which is HTTPS. BEAST works for most major browsers and websites.”

The researchers said that the browser-based attack is just one variant. They said they also could implement a similar attack against other services that use SSL, such as instant-messaging clients or VPNs.

“While other attacks focus on the authenticity property of SSL, BEAST attacks the confidentiality of the protocol. As far as we know, BEAST implements the first attack that actually decrypts HTTPS requests,” Duong said. “While fixing the authenticity vulnerabilities may require a new trust model, fixing the vulnerability that BEAST exploits may require a major change to the protocol itself. Actually we have worked with browser and SSL vendors since early May, and every single proposed fix is incompatible with some existing SSL applications.”

Rizzo and Duong are well-known in the security world for the research last year, also presented at Ekoparty, on the padding oracle attack on ASP.NET applications. That research prompted an emergency out-of-band patch from Microsoft. Opera already has implemented a fix for the TLS attack, and the researchers have been in touch with the other major browser vendors, but it’s not clear when their fixes will be available.

“Browser vendors are implementing a workaround to stop this attack but the real solution is switching to a new protocol,” Rizzo said.

A spokesman for Opera said that the gorup has found that the patch to fix this problem breaks a small number of sites and most users employ the browser’s default configuration, which is not vulnerable to this attack.

“In fact, we do have a patch as you alluded to, but we have not put it in the final release of the browser because, according to our testing, it breaks some sites. Since the vast majority of Opera’s users use the default security configuration and are thus not vulnerable, we decided to pull it at this time rather than risk site breakage,” Opera’s Thomas Ford said in an email.

About Dennis Fisher

Dennis Fisher is a journalist with more than 13 years of experience covering information security.

This is a ridiculous amount of hype for a vulnerability that has been known for almost a decade.

“Browser vendors are implementing a workaround to stop this attack but the real solution is switching to a new protocol…” and we could call that protocol TLS 1.1! Wait, theIETF already created something with that name! In 2006….

Wouldn’t the practice of good journalism require you to include at least one quote from an expert in this field, to confirm that this is a vulnerability which is so severe that it requires us to replace SSL?

Oh, that’s right, you can’t, because the details haven’t been released yet, so there’s no way to know what this actually does or whether these claims are just exaggerated. It’s probably fine, nobody ever exaggerates anything in the security industry.

If the browser architecture is remotely reasonable, then the fix might be easy an straightfoward: Don’t let the different environments (the rightful page and the BEAST communication) share the same socket for the communication. As soon as seperate network sockets are used for the communication, even when resuming the same underlying TLS session on each, the traffic encryption and mac keys differ, and the attack on CBC-mode of encryption will no longer work!

For a browser this should be much easier to do than for an SSL-VPN channel.

If I’m correctly understanding what the researchers are saying then you don’t need a MITM attack – just have a sniffer running on any infected machine in a network segment and it could decrypt SSL traffic passing by in real time (either itself, or using compute clusters) capturing “secure” cookies, usernames/passwords and other confidential information.

I’m just trying to get a better understanding of this from a laymans standpoint. The way I understand it is that someone (anyone really) must first have their browser/computer comprimised and the code running on their system. Once that ocurrs, then the encrypted SSL/TLS traffic can be sniffed and eventually decrypted, negating that particular certificate, correct? So it’s not a function of having to comprimise EVERY browser, simply one and you can get ahold of the key for that particular cert and decrypt all traffic from that website?

These are all silly comments. MITM attacks against SSL/HTTPS have been and will be just as much a problem, long after TLS v.1.2 has been around. Just look at ssl-strip and ssl-sniff. That problem will not go away until there are fundamental changes in the client-server model.

The whole point of SSL is to protect the connection, not the end points. If one of the end points is compromised, then there are a host of attacks that can be performed. I don’t see how anyone can make the possision that atacking an end point is an attack on SSL. That’s not what SSL is designed to protect.