TLS renegotiation vulnerability

Transport Layer Security (TLS), and its predecessor Secure Sockets Layer (SSL), are commonly used protocols for encrypting internet traffic, so TLS vulnerabilities can potentially affect a wide range of internet services. A recently disclosed flaw in the TLS protocol—though there is some dispute whether TLS is at fault—allows an "injected plaintext" attack against an encrypted session. This allows a "man in the middle" (MITM) attacker to prefix a victim's request with their own data, which gets interpreted by the server as if it came from the victim.

The flaw was disclosed on the Internet Engineering Task Force (IETF) TLS mailing list by Martin Rex of SAP on November 4, but it had actually been discovered two months earlier. Marsh Ray of PhoneFactor, Inc. discovered the problem in early August, but kept it quiet while alerting the IETF and various TLS developers and vendors. Those organizations came together as "Project Mogul" to find a solution to the problem. But once Rex had posted publicly about a possible MITM attack—independently discovered—against TLS (specifically Microsoft's IIS), Ray and his colleague Steve Dispensa released additional information showing that it was a pervasive problem for TLS (including Apache web servers, OpenSSL, GNUTLS, and others).

TLS allows clients and servers to renegotiate various session parameters within the TLS connection. When the renegotiation is done, however, TLS applications still accept data that came in before the renegotiation as if it were in the new security context. That hole allows a MITM attack. By arranging that the last data received is from the attacker, then causing a renegotiation with the victim, the attack effectively prepends the attacker's payload to the victim's request.

While it may sound rather theoretical, there is already a proof of concept (PoC) program available, and that has been adapted into a way to steal Twitter credentials. Other kinds of attacks are possible as well, some of which may exploit other internet protocols that use TLS, for example: SMTP (email), FTP, XMPP (Jabber), and some VPN implementations. Exploiting the vulnerability requires the attacker to control some node in between the client and server, which is not that difficult to do these days because of pervasive WiFi. Users are accustomed to using any available access point—especially if they use encrypted connections for their web/email/etc. connections—and that access point could be compromised.

Injecting the attacker's text into an existing TLS session may not seem like a particularly potent attack, but there are several examples of how it could work. Rex's original disclosure was related to web servers configured to require client certificates for some resources, and not for others, which will often lead to renegotiation. That led some to believe that this relatively rare configuration was required, but subsequent examples and explanations make it clear that there are other ways to cause, and exploit, renegotiation.

To attack a web-based application, the attacker typically would send their prefix to the server, then cause the renegotiation to occur. That renegotiation would actually be done between the victim's client and the server (with the MITM attacker just proxying the traffic). Due to the bug, the server would process the prefix in the new security context that gets established via the renegotiation. So, neither the client nor the server have any idea that this has occurred, and the attacker gets to insert his payload into the the client's secure session.

Eric Rescorla is one of those working on a long-term fix, but he also has a fairly straightforward example of the plaintext injection:

    GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
    X-Ignore-This:

    GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
    Cookie: victimscookie

    GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
    X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
    Cookie: victimscookie

The Twitter attack uses a similar scheme, but exploits the REST-based API for Twitter. In that case, the attacker's Twitter feed shows the victim's server request, which includes the base64-encoded username and password of the victim. In Thierry Zoller's "TLS/SSLv3 renegotiation vulnerability explained" [PDF]—a comprehensive guide to the problem—there is an example of hijacking email traffic using a similar technique: the attacker prepends SMTP commands to send an email to himself, then leaves the DATA command unterminated, effectively capturing the victim's outgoing email message.

Shortly after the initial disclosure, OpenSSL released a workaround that disabled renegotiation. According to Rescorla, almost all servers could disable renegotiation without impacting any needed functionality, but that doesn't fix the problem on the client side. Clients cannot detect whether the server allows renegotiation because the attacker could always fake a rejection of the renegotiation request.

A more long-term fix has been proposed—that site, ironically, has an invalid SSL certificate—by Rescorla, Ray, Dispensa, and Nasko Oskov of Microsoft. Their proposal would extend TLS to add information to each renegotiation about the previous renegotiation. In that way, clients could detect that their connection is not being negotiated for the first time, which would mean that a MITM had done a TLS negotiation already.

While TLS is the right place to make the fix, Adam Langley is unhappy that TLS is being blamed for the problem. His contention is that the applications are making unwarranted assumptions about what TLS provides. While that may be true, "every single protocol that is layered on top of TLS got this wrong", as Ben Laurie points out.

Zoller's paper also has a good summary of other protocols and programs that use TLS, along with their vulnerability status. It may be a hard vulnerability to exploit, because it requires a MITM position along with an ability to predict the client's traffic, but it is rather serious. As Rescorla and others note, though, MITM attacks simply using an attacker's certificate are generally fairly successful because users are willing to accept any certificate presented to them. It really isn't necessary to go to the lengths that are required to exploit this vulnerability until that changes.

[ Thanks to Tzvetan Mikov who suggested this as a topic shortly after it was made public. ]