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
(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:
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
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:
E.g., the attacker would send:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
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
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
And the server uses the victim's account to send a pizza to the attacker.
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,
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
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
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. ]
to post comments)