Plugging the Authentication Gap in SSL

The IETF has announced a draft document that specifies changes to the SSL protocol which closes the "authentication gap" exploited by the renegotiation attack announced last November. I posted a plain English explanation of the attack here, and you can find better graphical explanation here by Thierry Zoller (check for updates at his blog). The IETF and several vendors, including Google, Microsoft, and PhoneFactor, have been working on plugging this authentication gap since October. Until now, the best defence against the attack was to disable renegotiation in SSL.

The attack was initially dismissed as a quirk in the protocol - unexpected yet harmless - but it has ultimately resulted in several relatively small yet fundamental changes to SSL that introduce cryptographic state from one run of the handshake protocol to the next. The threat profile of the attack was raised when proof-of-concept code was written to demonstrate how the attack could be applied to steal Twitter passwords. PhoneFactor has described the attack as the most "severe" against the core SSL protocol to date.

The vulnerability that was uncovered is the observation that SSL does not distinguish between the initial protocol handshake of the client connecting to server, and any subsequent in-band handshakes for the renegotiation of cryptographic parameters. An attacker can establish an SSL session with a server and then later highjack an initial client SSL connection request to the same server, and splice the client request into the existing SSL session that the attacker has with the server. This is possible since the server interprets the client connection request as a renegotiation by the attacker. Any pending commands that the attacker has established with the server are then injected into the next client SSL-protected web session and executed in the context of the client (using the client cookies for example).

The solution proposed by the new IETF draft is for both client and server to cache the validation data that is currently computed and exchanged as the last step in the existing handshake protocol. A new protocol field has been introduced which indicates if the handshake is an initial or subsequent run (renegotiation), and in the latter case, the cached validation data is included in the renegotiation protocol. This prevents two independent sessions from being spliced together since the required validation data will either be absent or mismatched between the client and server.

It now remains to make any final tweaks to the protocol and to then deploy the revised protocol in existing SSL and TLS libraries, which is expected to be a slow and tedious undertaking. One of the authors of the new draft, Eric Rescorla, was a co-author in a recent study to examine the rate at which weak keys produced by a flaw in the random number generator of OpenSSL on Debian from 2008 were being patched. The study tracked a collection of approximately 50,000 public web servers over a period of 6 months. Initially around 1.5% of the servers (751 to be exact) were using Debian-flawed keys in their certificates, and 30% of the Debian-flawed certificates were still not re-issued after almost 180 days. Let’s hope for a better rate of patching in this case.