Secure Sockets Layer version 3: A Eulogy

As we put OP_NO_SSLv3 in all our software, we close a chapter of the history of the Internet. We’re laying to rest a faithful companion, one that gave us the commercial Internet we have today, and we’re also saying goodbye to one of the last closed protocols in mainstream use. And finally, we’re saying goodbye to the last immediate legacy of one of the early giants in the industry, as well as the reason for many of the existing giants’ dominance.

The Secure Sockets Layer was developed by Netscape Communications in around 1994, based around the X.509 Strong Authentication mechanism and its associated infrastructure of secure associations – in turn used by the X.500 directory standard which later spawned LDAP. As such, its roots go back to the 1988 publication of X.509 itself.

SSLv1 was stillborn, and its sibling, SSLv2, wasn’t much better – it survived just a year before being superseded by SSLv3 in 1996, which not only fixed flaws in SSLv2, but brought new functionality – like client authentication – from its parent X.509. But bizarrely, many people continued to use SSLv2 – Internet Explorer continued to use it for ten years until IE7 disabled it in 2006.

But SSLv3 was a winner – gradually Internet storefronts, and then banks, grew to trust the protocol so much that they were willing to offer financially-critical services over the Internet. This drove the Internet’s expansion as a mail-order, and then general commerce, system.

Similarly, when RSA spun off a small company called Verisign in 1996, few would have realised that a Certification Authority would grow to control much of the critical infrastructure on the Internet.

But early security experts weren’t sold on SSLv3; it was considered too risky to publish directly through the IETF (in fact it was historically documented as RFC 6101, some 8 years after being submitted). Instead experts worked hard to close the more obvious holes in the protocol, such as the ability of an attacker to interfere with the handshake traffic, forcing a downgrade to the fatally flawed SSLv2. Their efforts were published in 1999, as the Transport Security Protocol, version 1. Gone were downgrade attacks, the dependency on the rather weak MD5, and countless little flaws in SSLv3 that worried the wider community. As a community-developed open standard, TLSv1 was born considerably stronger than its predecessor.

And again, implementors ignored the new protocol, instead offering support for SSLv3 for nearly 18 years – despite two newer versions of TLS increasing security more and more. Worse, SSLv3 has no downgrade attack protection – a server can’t tell if a client trying SSLv3 is doing so because the client doesn’t do TLSv1, or whether an attacker has tricked the client into thinking the server only supports SSLv3. (The TLS Fallback SCSV offers a way to fix that, published just last summer).

And then, finally, a flaw was found in SSLv3 this week that couldn’t be easily fixed. SSLv3, a protocol designed behind closed doors within the long-dead Netscape Communications, is finally being taken out of action. “POODLE” is partly reliant on the cryptographic choices in SSLv3 that the designers of TLSv1 identified and avoided, but also on the downgrade attack that allows an attacker to force SSLv3. Neither apply to TLS. We built much of the modern internet on SSLv3 and its promise, but nevertheless, I’m glad we’re finally off it.

Of course, we’re not out of the woods yet – we need to be disabling TLSv1 before it reaches this point, and moving to TLSv1.2 well ahead of time. Because if there’s a lesson to be learnt here, it’s that every dog has its day.