Why Didn't We Spot That?

T he Secure Sockets Layer (SSL) protocol and its standards-track successor, the Transport Layer Security (TLS) protocol, 1 were developed more than a decade ago and have generally withstood scrutiny in that the protocols themselves haven't been found to have security flaws. Until now. In August 2009, Marsh Ray and Steve Dispensa discovered a design flaw in the TLS protocol (and published it in November 2009 due to independent rediscovery of the flaw by Martin Rex) 2 that affects all versions of the protocol up to and including the current version. Whereas the vulnerability itself is serious , it need not affect many deployments once administrators apply suitable patches to disable renegotiation, leaving TLS sufficiently secure in most cases because exploiting the vulnerability requires the attacker to be an active man-in-the-middle, redirecting traffic between victims (for example, a browser and a Web server). However, because security problems only ever get worse, a change to the protocol is required and is now being developed as a high priority in the IETF (http://tools.ietf.org/wg/tls). If all goes well, a new RFC with the fix might be published soon after this article appears. The vulnerability is an interesting attack in itself, but perhaps more interesting is the question , why didn't we see this earlier? In this article, I explore this question but, unfortunately, can't answer it. Hopefully, simply asking the question might prompt developers to reexamine assumptions they've forgotten they've even made. The TLS protocol starts with the so-called " handshake " phase in which two parties agree on the types of cryptography and on the keys to use for protecting application data. The handshake requires a couple of roundtrips, as the client and server exchange and then verify parameters after they've established shared keys. After the handshake, the keys established during the handshake protect the application data (for example, HTTP traffic). Figure 1 — modeled on figures from Eric Rescorla's Inter-net draft 3 — provides an abstract view of such an exchange, showing the initial handshake messages that aren't encrypted, followed by protected application-layer traffic between the client and server. The problem arises due to the fact that TLS also lets clients and servers renegotiate or, in other words, do a second handshake, and this second handshake isn't cryptographically bound to the initial one. TLS allows this for a couple of reasons. Perhaps its most common use today is to enable protection …