Man-in-the-Middle Attack Against SSL 3.0/TLS 1.0

It's the Browser Exploit Against SSL/TLS Tool, or BEAST:

The tool is based on a blockwise-adaptive chosen-plaintext attack, a man-in-the-middle approach that injects segments of plain text sent by the target's browser into the encrypted request stream to determine the shared key. The code can be injected into the user's browser through JavaScript associated with a malicious advertisement distributed through a Web ad service or an IFRAME in a linkjacked site, ad, or other scripted elements on a webpage.

Using the known text blocks, BEAST can then use information collected to decrypt the target's AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.

The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0­which would be most secure sites, since follow-on versions of TLS aren't yet supported in most browsers or Web server implementations.

While Rizzo and Duong believe BEAST is the first attack against SSL 3.0 that decrypts HTTPS requests, the vulnerability that BEAST exploits is well-known; BT chief security technology officer Bruce Schneier and UC Berkeley's David Wagner pointed out in a 1999 analysis of SSL 3.0 that "SSL will provide a lot of known plain-text to the eavesdropper, but there seems to be no better alternative." And TLS's vulnerability to man-in-the middle attacks was made public in 2009. The IETF's TLS Working Group published a fix for the problem, but the fix is unsupported by SSL.

Another article.

EDITED TO ADD: Good analysis.

Posted on September 23, 2011 at 1:37 PM • 34 Comments

Comments

Glenn MaynardSeptember 23, 2011 1:58 PM

Most webservers and several major browsers are open source, the flaw has been known for years and the fix has been published for over a year.

Forcing people to release source is clearly the solution to our security woes.

Steve DispensaSeptember 23, 2011 2:21 PM

SSL 3.0 could have implemented the renegotiation indication extension, and in any case, most implementations of ssl 3.0 are also implementations of tls 1.0. I am not certain if any ssl3-only clients implemented the RI extension, but it was designed as it was intentionally, in part to leave open the possibility of SSL 3.0 implementations. Recall that the SSL was not an IETF standard, so the IETF WG would not have been able to require or standardize RI for SSL3.

On the current attack, preferring rc4-sha should work around the problem, at least according to the early details. I blogged about it in the linked URL above.

Kenny PatersonSeptember 23, 2011 2:49 PM

The problem discovered by Duong and Rizzo and exploited by their BEAST tool is NOT the same as the one made public in 2009. The fix to that 2009 problem is irrelevant to the attack of Duong and Rizzo. Your comment is pretty much terminally confused here.

Kenny PatersonSeptember 23, 2011 3:01 PM

Something more constructive in comparison to my previous comment:

The vulnerability on which the new attack is based is indeed well known. It's due to the use of predictable IVs for CBC mode encryption in SSL3.0 and TLS1.0. That this can cause problems was first observed by Dai and Rogaway, as noted by Bodo Moeller here:

http://www.openssl.org/~bodo/tls-cbc.txt

Also relevant is a 2006 article by Greg Bard, showing how the distinguishing attack of Dai and Rogaway might be turned into a plaintext recovery attack under certain circumstances:

http://eprint.iacr.org/2006/136

Essentially, Duong and Rizzo have rediscovered Bard's attack and made it work for real against https cookies. To do this, they had to come up with some new twists, and much kudos is due to them for that.

The long term solution is to switch to TLS 1.1 or 1.2, which mandates per-packet, random IVs. A full security analysis of this scheme is to appear in a forthcoming paper at Asiacrypt 2011 (this is a shamless plug for my own work with Tom Ristenpart and Tom Shrimpton).

However, this is not an easy transition to make because of lack of support in clients and servers for these versions of TLS. There are other workarounds, including the sending of a dummy packet for each real packet on the TLS connection. This hack was already implemented in OpenSSH some years ago because of exactly the same issue with predictable IVs there.

Glenn MaynardSeptember 23, 2011 3:25 PM

Your comment is terminally misdirected: if anything's "confused", it's the quoted article, which talks about one MITM attack and then links to a different MITM attack.

That's irrelevant, of course: "the vulnerability that BEAST exploits is well-known", and yet here we are.

The notion of effectively forcing companies to release their source, or else be ground into the dust by frivolous lawsuits, is absurd.

Kenny PatersonSeptember 23, 2011 6:08 PM

@Glenn: my bad, I didn't realise that what was posted was just a quote from some random article. I guess Bruce is too busy these days to check for accuracy himself or actually write his own commentary :-)

Fred WhelpsSeptember 23, 2011 8:49 PM

A dumb question. If the attacker is capable of injecting javascript into the session for the purpose of implementing a known-plaintext attack, isn't the attacker as equally able to simply fetch the browser cookies directly, using javascript, and skipping the complex plaintext attack entirely?

jakeSeptember 23, 2011 9:16 PM

injection of malicious javascript as part of ads on a page is a neat trick. if that's the attack vector it can be blocked by blocking ads using e.g. adsuck.

Mark TwainSeptember 23, 2011 9:38 PM

Fred Whelps: nope. When you are inside an iFrame of a different origin, you can't simply grab the cookies of the main window.

Browsers security do not allow you to read the content (that includes cookies) that is coming from a different domain.

PeterSeptember 24, 2011 1:37 AM

So if i understand correctly:
Browsers security does not allow javascript to read content/cookies from a different domain, but it does allow you to read low-level packets from a different domain?

That just seems like a really weird choice.

Bernd MaySeptember 24, 2011 6:32 AM

Two things that hit me while reading article and comments:

1. The IETF's TLS Working Group published a fix for the problem, but the fix is unsupported by SSL. I guess this means just SSL not TLS, because as far as I know OpenSSL for example did implement the RFC into their library quite soon after the publication of the standard link So as long as TLS is used and no fallback to SSL is allowed, this should effectively close the vulnerability from 2009.

2. As far as I understood the new "attack" is actually divided into two parts. The first one being to inject a javascript that generates known plaintext packets into a website. The second part is then to sniff the network of a client that opened this website (or the network of the server) and to use the encrypted packets of your script with the known plaintext to get at the encryption keys. This is only because the current algorithm uses the encrypted version of the last packet as the IV for encryption of the next one.

Did I get that right?

anon-yeah-rightSeptember 24, 2011 11:44 AM

All this talk about "browsers" is misleading. The exploit is fundamentally about TLS, so SSH would be vulnerable too, say in a wireless context. Correct me if wrong.

Natanael LSeptember 24, 2011 3:36 PM

So... Time to scrap SSL completely? :)
Maybe we should make a TLS 1.3 right away (or go for using TLS 1.2) and start a campaign to just get everything below that dropped.

9ac322038b09b254b658252a35c4fae7f9b84b9dSeptember 24, 2011 9:02 PM

@anon-yeah-right

SSH uses its own protocol and not TLS. You build OpenSSH with the OpenSSL library only for the crypto support.

DanielSeptember 24, 2011 9:13 PM

While I can appreciate the technical achievement that this represents, I don't believe that it presents any reason to panic (or even change).

If I can inject Javascript into your browser/webpage there are many easier ways to information from your session than decrypting your SSL session.

Nick PSeptember 24, 2011 11:20 PM

@ Daniel

"If I can inject Javascript into your browser/webpage there are many easier ways to information from your session than decrypting your SSL session."

One potential application that justifies the trouble is inline encryption or SSL sessions of apps that are privacy-preserving. In other words, plenty of potentially useful data can be recorded in encrypted form but is inaccessible afterwards during a compromise. Compromising the key gives access to previous data. Additionally, if the key is used for authentication too, the attacker might have a forgery opportunity they can use without maintaining control of an actual machine (e.g. MITM).

I haven't even gotten started on APT's. There's quite a lot of potential for cracking a protocol which people assume will be secure.

BrianSeptember 25, 2011 4:19 PM

I wonder if this could be the final nail in the coffin for the idea of using a block cipher in CBC-mode for encrypting communications channels. It has no real security advantages over a stream mode (like counter or OFB) or a stream cipher, and is more complicated to implement correctly due to issues like padding and having to implement the decryption side of the cipher. Bruce argued in "Practical Cryptography" back in 2003 that counter mode was probably the way to go, and he wasn't the only one saying so, yet it still feels like an oddity when it does show up in real life.

John RSeptember 26, 2011 7:53 AM

The exploit as presented relies on the WebSocket API. However, the WebSocket API really should be preventing the connection due to the same-origin policy (as the port is different). This wouldn't be the first security flaw in WebSockets.

The paper claims that Java and Silverlight can also be attacked. What these should be doing isn't clear, but they probably should be enforcing the same-origin policy too.

LinkTheValiantSeptember 26, 2011 8:17 AM

The obvious "NoScript" springs to mind, since no JavaScript means no attack. Which is sad, because instead of fixing the problem the best answer we currently have is "block the broken thing".

And by "fixing the problem", I mean "use something other than JavaScript". It's not as if we don't have other tools available. It makes me think of a caveman persisting in using a rock to hunt when a spear is demonstrably better, if a little more work to set up initially.

The real 9ac322038b09b254b658252a35c4fae7f9b84b9dSeptember 27, 2011 9:34 AM

Nice try pseudo-9ac322038b09b254b658252a35c4fae7f9b84b9d!!

QuitchSeptember 28, 2011 4:20 AM

Given that TLS 1.1 and 1.2 improved on 1.0, does anyone know why IE9 has them disabled by default? What reason is there to not enable these out-of-the-box?

Clive RobinsonSeptember 28, 2011 6:03 AM

@ Quitch,

The simple answer is "compatability issues" with web servers nearly none of which run anything other than SSL 3.0 / TLS 1.0.

martinrSeptember 28, 2011 8:54 PM

A couple of comments.

I like Eric Rescorla's writeup about the BEAST attack:
http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html

The BEAST attack exploits predictable IVs for future SSL records of the same connection for TLS cipher suites with block ciphers in CBC-modes in SSLv3 and TLSv1.0. This is possible because of the "running IV", i.e. reuse of the last cipherblock from the previous SSL record as initial IV for a new SSL record. And all what BEAST succeeds in doing is recovering blocks of plaintext by lots of guessing (trial and error), BEAST does _not_ recover any encryption keys.

A prerequisite for the BEAST attack is that your Browser will happily execute arbitrary malware of the attackers choice (Man-in-the-Browser attack) allowing that malware to send arbitrary requests to any attacker-chosen Web Servers and where the Browser will obediently insert allegedly confidential existing Cookies into the header of each request performed by the malware. Really, this is a "you are p0wnd" prerequisite, so it is just mildly interesting that the Browser did not serve that Cookie to the malware on a golden platter as well. But I hope it helps to remind folks that lightheartedly mixing and matching untrustworthy code with sensitive data in protocols may have unintended consequences on confidentiality, and it is a bad idea to make bold assumptions about properties of protocols beyond their design limits.

Quoting the TLSv1.2 spec: http://tools.ietf.org/html/rfc5246#page-16

Any protocol designed for use over TLS must be carefully designed to
deal with all possible attacks against it. As a practical matter,
this means that the protocol designer must be aware of what security
properties TLS does and does not provide and cannot safely rely on
the latter.

SSLv3 and TLSv1.0, with their running IV for cipher suites with block ciphers in CBC mode provide an "encryption oracle" (enabling a "chosen plaintext attack") when supposedly confidential data is mixed with arbitrary data from an attacker, and the attacker is allowed to watch SSL records on the wire before submitting new data that will be transmitted at the beginning of new SSL records on this very connection.

Different TLS connections (even when resumed from the same cached TLS session) and even both directions of the same TLS connection use distinct encryption and MAC keys, so they're isolated from each other.

The distortion that TLSv1.1 adds with the use of explicit IVs for each new TLS records should provide a sufficient security margin for this kind of attacks, but the security margin depends on the ciphers block size rather than its key size. A non-predictable IV distorts the output of a "CBC encryption oracle" against chosen plaintext attacks. Fortunately the SSL records use a MAC for integrity protection inside the CBC-encryption as an integral part of the protocol, or the explicit IV prepended to the ciphertext could have created a "CBC decryption oracle" in return.


As far as Authentication cookies are concerned -- these aren't "valuable secrets on their own" but rather a means for a specific purpose (limit who can submit a request that will be executed under an existing session). So with respect to what BEAST did in the PayPal attack (it uncovered the plaintext of an SSL-Cookie that was silently assumed not to be accessible to malware running in the browser), there is really *nothing* that it gained from that particular attack and could not have done directly and without the attack: submitting requests that are executed under the session identified by that SSL-cookie. Would BEAST directly submit evil requests, then the server would have not the slightest indication that it is being attacked. BEAST's guessing attack itself is noticable heuristically on the server from its amount of network traffic and traffic characteristic (a high number of strange requests with lots of small, dribbling SSL records containing fairly random binary junk).

martinrSeptember 30, 2011 12:16 PM

btw. this would be one possible mitigation for SSLv3 and TLSv1.0:
http://src.chromium.org/viewvc/chrome?view=rev&revision=97269
OpenSSL has been able to do this for years with empty (instead of one-byte) SSL records, but "empty" is a real border case that might face more interop problems than a prepended fragment of 1 byte.

It is important to do this only for application data records (and it is only necessary for application data records), because a large number of the installed base of TLS implementations will abort the connection when faced with fragmented handshake messages, e.g.:
http://support.microsoft.com/kb/2541763

This solution incurs some additional overhead (slightly more on the receiver), because of the additional TLS record that needs to be processed, and is only necessary for SSLv3&TLSv1.0. Although the TLS protocol has always explicitly stated that message boundaries will not be preserved by the record layer
http://tools.ietf.org/html/rfc2246#section-6.2.1
there might exist a few brittle application designs that choke on such a newly imposed additional fragmentation of application data.

jouySeptember 30, 2011 3:04 PM

@martinr You misunderstood, there isn't any malware in the browser. They force the browser or its plug-ins to make SSL connections. Those requests have secret cookies that the attacker can't get just with javascript (httponly/secure). The server can't detect the attack, the MiTM can drop the data packets once he reads them.

martinrOctober 1, 2011 8:55 PM

@jouy: The BEAST attack is all and only about malware in the browser. Malware that can be entirely remote controlled by the attacker. And that malware requires a feedback loop from a ccoperating network monitor in order to make the attack adaptive, i.e. trickle out a new SSL record on the established TLS connection where the Cookie had been sent, read the SSL record on the network to learn the last ciphertext from it and calculate the next "guess" to make it an adaptive chosen plaintext attack. If it was just about sending requests, then there would not be any advantage for SSLv3/TLSv1.0 over TLSv1.1.

NypeJune 20, 2012 6:27 AM

Hello everyone,

Have your ever think what happen if you first ISP router is captured and then route your connection to other site and then back to your ISP?

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..