The attack exploits TLS's renegotiation feature, which allows a client and server who already have a TLS connection to negotiate new parameters, generate new keys, etc. Renegotiation is carried out in the existing TLS connection, with the new handshake packets being encrypted along with application packets. The difficulty is that they're not otherwise tied to the channel, which gives the attacker a window. The simplest form of the attack is shown below [cribbed from draft-rescorla-tls-renegotiate.txt]
Client Attacker Server ------ ------- ------ <----------- Handshake ----------> <======= Initial Traffic ========> <-------------------------- Handshake ============================> <======================== Client Traffic ==========================>
So, in order to mount the attack, the attacker first connects to the TLS server. He can communicate with the server as much as he wants, including making an arbitrary number of requests/responses, etc. This traffic is all encrypted and shown as ==. Then when he's ready, he hijacks the client's connection to the server (in practice he might start by hijacking the connection and then connect to the server but it doesn't matter) and just proxies the client's traffic over the encrypted channel. The client negotiates with the server and from that point on the client and the server communicate directly. Note that the client is communicating with the attacker in the clear but the second handshake is encrypted and goes over the attacker's channel. Thus, the client does not know that he is renegotiating. However, the server thinks that the initial traffic with the attacker is also from the client. There are also other (probably less useful) variants where both sides see a renegotiation but of different connections.
Impact on Existing Applications
TLS itself is just a security protocol, so the impact of this attack depends on the application protocol running over TLS. The most important of these protocols is of course HTTP over TLS (HTTPS). Most Web applications do initial authentication via a username/password pair and then persist that authentication state with HTTP cookies (a secret token that is sent with any request). An attacker might exploit this issue by sending a partial HTTP request of his own that requested some resource. This then gets prefixed to the client's real request.
E.g., the attacker would send:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This:
And leave the last line empty without a carriage return line feed. Then when the client makes his own request
GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 Cookie: victimscookie
the two requests get glued together into:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 Cookie: victimscookie
And the server uses the victim's account to send a pizza to the attacker.
You can mount a similar attack if the server uses certificate-based client authentication: it's common (well, common in the small number of cases where client certs are used at all) for the server to let the client connect and request a resource and then if the resource is protected renegotiate asking for a certificate. The attacker can exploit this by doing the initial handshake and asking for the resource and then letting the client do the renegotiation, at which point the server acts as if the initial request was made by the client.
It's important to note that in both the cases we just described the attacker doesn't get to see any sensitive information directly: that's just sent back encrypted to the client. However, he can exploit side effects of the exchange, e.g., to get a pizza. It may also be possible to exploit HTTP features to directly access the data. For instance, he might be able to generate a combined request that would cause the server (or perhaps somehow mirrored through the client) to send the original client request to the attacker. If the request contains the client's cookie or password, this would cause their credentials to leak. It's not clear to me if this is possible, but I'm hoping some of the Web security specialists will weigh in.
The impact on other protocols (IMAP, SIP, etc.) would depend on those protocols and I haven't seen complete analyses of these yet.
Eventually there will be a TLS level protocol fix (see below). However, in the meantime options are limited.
For 99+% of applications, the mitigation is very simple: the server should simply disable all renegotiation, which stops the attack. (OpenSSL will helpfully automatically renegotiate which facilitates the attack even if the application isn't otherwise set up to do renegotiation). Unfortunately, there is no similar defense on the client side. In the example I showed above, the client is unaware that renegotiation happened. Moreover, the client can't tell that the server will refuse renegotiation (it could explicitly probe but the attacker could of course fake a failure). So, the client can't really do anything useful to protect itself.
The second drawback is that there are a small number of cases (e.g., the certificate authentication one I described above) where renegotiation actually should happen. The most practical defense on the server side is to restructure the site so that requests which require client auth are redirected to a different address or port which always requests a certificate and itself refuses renegotiation. However, this obviously requires major work on many sites.
There are a few other legitimate reasons for renegotiation, but they're mostly things one doesn't need to do. For instance, people sometimes renegotiate to force the generation of fresh keying material. This is not necessary with modern cryptographic algorithms. Another example provided by Ray is sites that support algorithms with differential strength. Again, this isn't really necessary. Unless you're doing certificate-based client authentication it's very unlikely you need to renegotiate and if you are using it, the workaround above is the simplest.
Despite the existence of some defenses, it seems clear that TLS should really defend against this. There's a fairly obvious defense that at least three people have independently come up with: carry information about handshake n-1 in handshake n (if n==1 you just carry an empty field). This prevents attacks where the client and server have different views of the negotiation state. The predisclosure group that worked on this after Ray discovered this worked to develop a draft describing this technique which can found at draft-rescorla-tls-renegotiate.txt and we'll be submitting it to the TLS working group shortly. Of course, this will take a very long time to make it into enough clients and servers to make a real difference, so for now we're mostly stuck with the mitigations I've described.
The Software Situation
People have also developed patches for existing implementations. These fall into two categories:
- Just disable renegotiation (really important for OpenSSL because of the aforementioned automatic renegotiation) issue.
- Implement the long-term fix.
As far as I know none of these have been formally released yet. Ben Laurie's OpenSSL disabling patch can be found here. I've developed a patch that performs the long-term fix protocol pieces but it doesn't disable non-fixed renegotiation so it's usable primarily for interop testing right now. That can be found here. Expect both of these to eventually appear in official OpenSSL distributions/patches. I don't know the release status of other fixes.
Big Picture Perspective
Now that we've covered how this attack works, how bad is it? It's being billed as a man-in-the-middle attack, but it's really far more limited than your classic MITM. Rather, it's a plaintext injection attack. I'm not saying that's good, but we need to put it into perspective: over the past two years, we have seen two separate issues that allow a complete TLS server impersonation: the Debian PRNG bug (see our paper here for a description of the issue [which we did not discover] and its impact) and the TLS certificate "NULL" issue. Both of these issues had much more severe impact since they allowed the attacker access to all the data sent by the client. However, it's worth noting that they differed from this issue in that they were detectable/fixable on the client side so people could in principle protect themselves. As a practical matter, however, most clients never checked the Debian keys against a blacklist, so that protection was minimal at best.
Second, it's important to remember that even simple MITM attacks with fake certificates don't seem that hard to mount. Cranor et al. report that users very frequently ignore browser warnings of bad certificates, which more or less obviates any security protections TLS provides. If the user will accept the attacker's certificate, there's no need to do anything as limited as the attack described here. Obviously, that's not information that should give you a huge amount of confidence in any form of Internet communications security, but it does provide some perspective on the marginal impact of this attack.
One other comparison point is a remote vulnerability in the server. TLS implementations have historically had and continue to have remote vulnerabilities which would allow an attacker to subvert the server. Such an attacker could read all your traffic to that server. As with this issue, you can't really detect that from the client side and need to rely on the server being upgraded. So, this issue is somewhat less serious than a remote vulnerability in a really popular server stack like OpenSSL. It's primarily unusual because it's an issue in the protocol not the software and those are quite rare.
As I said at the beginning, this obviously isn't good. We'd like SSL/TLS to provide it's nominal security guarantees and it clearly doesn't. There likely to be exploitable attack paths using this issue. It's far less clear whether they will actually see exploitation, given that these attacks aren't necessarily as powerful as other already known paths. In the not too distant future you should expect most important servers to have fixed, at which point most of your Web server interactions will be safe (even though you can't verify it easily). In the long term, most clients and servers will adopt the protocol fix at which point clients will be able to be sure that the servers they are interacting with are safe.