When Renegotiation is a Bad Thing: MITM Attacks on SSLv3/TLS Protocol

Over the last few days, an attack against the SSLv3/TLS protocol was made public.  The following is my opinion based on public information and industry discussion.

TLS is the current version of a protocol that was originally developed by Netscape (under the name of SSL).  The protocol was originally developed to secure connections between a web browser and a web server.  The protocol has since found application in areas as diverse as protecting email services to virtual private networks.  It is the Internet standard for communication between programs running on different machines on the Internet.

This attack has potentially serious implications because it could affect all the uses of TLS.  It is an attack on the TLS protocol, not the implementations, so programs that use anyone’s TLS stack are vulnerable.

At this point, the web use of TLS is the main focus of concern.  All web sites that are accessed via a HTTPS URL can be subject to this attack if the attacker can insert themselves somewhere on the network (not necessarily an easy task) between the web browser and the server.

This specific attack allows a “Man In The Middle” (MITM) to splice prefix bytes onto a client’s TLS session. Typically, there is no way for the MITM to then pass control of the TLS connection back to the unsuspecting client, and this is where TLS renegotiation comes into play.

TLS renegotiation allows an existing TLS session to re-do its handshake, establishing new keys, cipher and client (or even server) certificates.  Renegotiation was intended for use in situations like long-lived connections where keys needed refreshing, the server requesting the client to use a client certificate, or upgrading the security strength of the connection.

For the attack, the MITM grabs the client’s initial connection request, and then connects to the server.  After finishing the handshake and passing in some prefix bytes, the MITM either requests a renegotiation or, in the case of a web server where the requested URL requires a cipher-suite upgrade or a client certificate, the server initiates the renegotiation. The MITM then forwards the client’s initial connection request and just proxies the messages back and forth between the client and server.  Once the new handshake is finished, the MITM is unable to view the connection because it is encrypted, but the MITM was able to inject initial prefix bytes.

The problem is the server cannot tell the difference between the client’s initial connection request and a renegotiation request since both use the same byte code in the TLS protocol.  The original SSLv3 specification should have used different byte codes for these two messages.  The two messages are identical, but are used in different places in the handshake.  Future protocol designers should remember to allocate message identifiers to indicate the use of a message, not its structure.   So, now that I've briefly described the protocol attack, how does this apply to applications?

In the case of HTTPS, an ingenious attack was proposed by security researcher Ray Marsh where the MITM sends an initial HTTP request, but without a newline terminator on the last header line.

POST /very-bad HTTP/1.0
X-ignore-what-comes-next:

Since there is no newline on the 'X-ignore-what-comes-next:', the client’s GET/POST line will be appended and ignored by the web server.  The problem is the remaining header bytes will be present, so any authentication cookies will be used to authenticate the attacker’s URL.

If the client supplied a certificate, the URL will be enacted upon as though it had the client certificate presented, even though the MITM presented the data.  All data that came before the client certificate request should not be trusted or, for a web server, all header bytes that came after the first HTTP line should be discarded.  But even this is not enough, since unless the web server ignores the second (genuine) HTTP request sent by the client, the MITM's URL will be used with the credentials of the MITM.

For other protocols, the MITM can inject data up until the point that the client needs to provide data that the MITM does not have, like a password.  If a protocol allows the following type of command sequence:

DEBUG_LOCATION: bad-machine.com:3000
USER: abc
PASSWORD: xyz

The attacker could add the first line.  At the point of authentication, all previous configuration information should become suspect since it could have been injected by the attacker. 

What do we do about all this?

The simple answer is to disable all renegotiation.  Client renegotiation is just pure evil, but if the MITM can trigger the server to initiate renegotiation, then server renegotiation is also bad.

Unfortunately disabling all renegotiation will break many things.  A solution for websites is to have an initial site that redirects to a new site with client-authentication and/or stronger ciphers.  This works because the web server will not allow the initial connection without client authentication, so no upgrade occurs, no attack point.  Unfortunately, this involves reconfiguring websites.

The long term solution is to change the renegotiate message to be different from the client-hello message.  There is an IETF specification for adding an extension (which is a backward compatible way of extending the TLS protocol) that must have a particular value (empty) on an initial client hello, and a value from the last handshake (the finished message(s)) if renegotiation is occurring. Once this is deployed to both client and server, life can continue as before.

So there are several ways to proceed.

• Wait for a new patched version of your TLS library, then redeploy your application.
• Modify your application to use a TLS library API to disable renegotiation.
• Use a TLS library API callback to monitor the library and abort renegotiations.

The last solution, if written correctly can be done in a forward compatible way so the application will disable renegotiations for old TLS libraries, but will allow libraries implementing the renegotiation extension to work.

And finally, what is EMC/ RSA doing about this?

The official word from EMC’s Product Security Response Center is that we are working on assessing and remediating any potential TLS vulnerabilities in our own products and doing so in an expeditious and timely manner. Further communications on this matter to our customers and channel partners is forthcoming.

Post A Comment

Your Name
Your Email	Publish email?: Yes No
Your Blog
Subject
Comment
Verification Word