This blog post will totally change the way you look at SSL and TLS. It will be story of war, love, betrayal and dragons. As a direct follow-up on my post “HTTPS is DROWNING“, may I present you the history of SSL and TLS (and HTTPS)!
SSL history lesson
Once upon a time in a country far, far away some knights at Netscape created SSL 1. “Behold!” they said, “for we have created something that’ll make communication secure!” and so SSL 1 were born. SSL 1 had so many major security flaws that it had to be contained securely at the Netscape lab and was never shown any sunlight.
And so the saga began and they afterwards released versions one through three. Building on the ideas and theories of SSL 1, SSL 2 got released in 1995 – and it had it all! It supported many encryption algorithms that were already deemed insecure at the time – for instance DES support with only 56 bits key length! The reason for this awkward support was that back in the 90’s exporting strong encryption were forbidden in the United States. Other merits of SSLv2 as stated in RFC 6176:
SSL version 2.0 [SSL2] deficiencies include the following: o Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151]. o Handshake messages are not protected. This permits a man-in-the- middle to trick the client into picking a weaker cipher suite than it would normally choose. o Message integrity and message encryption use the same key, which is a problem if the client and server negotiate a weak encryption algorithm. o Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session.
SSLv2 got deprecated in 2011. But, its successor were already published back in 1996! Since the knights had no imagination, they dubbed it SSLv3. This version was to finally nail the shortcomings of SSLv2.
Even though SSLv3 was intended to be a safer alternative, it failed too. It was vulnerable to the Poodle attack and various other funny things. Poodle, for instance, affected all block ciphers in SSL; and RC4, the only non-block cipher supported in SSLv3. SSLv3 were deprecated in June 2015.
The failures of SSLv3 lead to TLSv1.0, which was an upgrade to SSLv3 without any dramatic differences. Except it precluded interoperability between TLSv1.0 and SSLv3. The draft of TLSv1.0 were defined in 1999. But wait, this version needed an update too!
So – next version out was TLSv1.1, fixing issues present in TLSv1.0. It was defined back in 2006. The differences this time?
- Added protection against cipher-block chaining (CBC) attacks.
- The implicit initialization vector (IV) was replaced with an explicit IV.
- Change in handling of padding errors.
- Support for IANA registration of parameters.
… And then TLSv1.2 followed in 2008. It was based on TLSv1.1 and differences included:
- The MD5–SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option to use cipher suite specified PRF’s.
- The MD5-SHA-1 combination in the finished message hash was replaced with SHA-256, with an option to use cipher suite specific hash algorithms. However the size of the hash in the finished message must still be at least 96 bits.
- The MD5-SHA-1 combination in the digitally signed element was replaced with a single hash negotiated during handshake, which defaults to SHA-1.
- Enhancement in the client’s and server’s ability to specify which hash and signature algorithms they will accept.
- Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and CCM mode of Advanced Encryption Standard encryption.
- TLS Extensions definition and Advanced Encryption Standard cipher suites were added.
None versions of TLS has been deprecated yet. But if you want to follow the PCI Standard you should support the newest protocols. You can still use TLSv1.0 but some restrictions may apply.
In March 2011 all TLS version were further refined removing their backward compatibility with SSL. This means TLS session never will negotiate the use of SSLv2.0.
Given that the latest version of TLS is 1.2, next is 1.3. I bet you didn’t see that coming… It hasn’t been released since it still is a working draft and the details are provisional and incomplete. It differs from TLSv1.2 in the following ways:
- Support for weak and lesser used named elliptic curves (see Elliptic curve cryptography) removed
- Support for MD5 and SHA-224 cryptographic hash functions removed
- Requiring digital signatures even when a previous configuration is used
- Integrating HKDF and the semi-ephemeral DH proposal
- Replacing resumption with PSK and tickets
- Supporting 1-RTT handshakes and initial support for 0-RTT (see Round-trip delay time)
- Support for many insecure or obsolete features including compression, renegotiation, non-AEAD ciphers, static RSA and static DH key exchange, custom DHE groups, point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers dropped
- SSL or RC4 negotiation for backwards compatibility prohibited
- Integrating use of session hash
- Deprecating use of the record layer version number and freezing the number for improved backwards compatibility
- Moving some security related algorithm details from an appendix to the specification and relegating ClientKeyShare to an appendix
- Adding of Curve25519 and Ed25519 to the TLS standard.
And so the history lesson ends. For now.
- What’s left of TLS incomplete security
- RFC 6176
- The most brutal security bugs: Freak, Shellshock, Poodle, Heartblead and BEAST
- SSLV2, why are you still around?
- Acunetix: recommendations for TLS/SSL Cipher Hardening
- WireShark Wiki: Secure Socket Layer (SSL)
- Wikipedia article on SSL and TLS