Early web browsers 2 – Transport Layer Security at a Glance
The very first SSLv1 draft had no integrity protection at all. In subsequent revisions of that draft, a Cyclic Redundancy Check (CRC) was added. This, however, didn’t solve the message integrity problem because CRC was originally designed as an error-detection code to detect accidental bit flips in communication messages. Unlike cryptographic hash functions, CRCs are invertible, and it is easy to find CRC collisions where two different messages lead to the same CRC value, allowing the attacker to undetectably change messages. As a result of these security flaws, Netscape never released the specification or implementation of SSLv1.
SSLv2, the second version of the SSL protocol, was publicly released in November 1994 and integrated into Netscape Navigator 1.1 in March 1995. In SSLv2, the CRC was replaced by MD5, a cryptographic hash function that was eventually broken in 2004 and is no longer secure.
However, soon after its release, a number of further security weaknesses were discovered in SSLv2. Among other things, the same cryptographic key was used for both encryption and message authentication. In addition, SSLv2 turned out to be vulnerable to length extension attacks and didn’t protect the initial handshake or the explicit message close, making it vulnerable to man-in-the-middle attacks. Finally, SSLv2 was designed to support a single service and a fixed domain certificate, making it unusable with the popular feature of virtual hosting in web servers.
Learning from the previous security flaws, Netscape decided to re-design SSL from scratch and released SSLv3 in late 1995. SSLv3 fixed previous security problems and added a number of new features, including the use of the Diffie-Hellman key agreement protocol and the application of the Digital Signature Standard. In 2011, the specification of SSLv3 was published in the historical IETF document RFC 6101.
In May 1996, the Internet Engineering Task Force (IETF) formed a working group to standardize an SSL-like protocol. The standardization process took around three years and the Transport Layer Security (TLS) standard 1.0 was published as RFC 2246 in January 1999. While TLS 1.0 in principle closely resembled SSLv3, changes made to key expansion and message authentication turned it into a protocol without backward compatibility with SSLv3.
Almost seven years later, in April 2006, IETF published RFC 4346 defining the successor TLS version 1.1. Among the most important changes compared to TLS 1.0 was the added protection against cipher-block chaining attacks.
In 2008, IETF published RFC 5246 and with it a new version TLS 1.2. The most notable change was the addition of so-called authenticated encryption using the Galois/Counter Mode (GCM) and the Counter with Cipher Block Chaining Mode (CCMP) of the Advanced Encryption Standard (AES) cipher (see Chapter 14, Block Ciphers and Their Modes of Operation).
After a number of practical attacks on TLS 1.2, work began on TLS 1.3 in August 2013. During this period, security researchers kept publishing attacks on TLS 1.2. Eventually, IESG approved the 28th revision of TLS 1.3 as a Proposed Standard. In August 2018, five years into its development, TLS 1.3 was published as RFC 8446. A compact overview of SSL and TLS history can be found at https://www.feistyduck.com/ssl-tls-and-pki-history/.In March 2021, IETF published RFC 8996, which formally deprecates the previous TLS versions, 1.0 and 1.1. IETF gives several technical reasons for deprecating these TLS versions. First, they require the use of older cryptographic algorithms that are no longer considered secure. Second, they don’t support state-of-the-art cryptographic mechanisms, most notably authenticated encryption with associated data. Third, the key establishment integrity and the authentication of peers depend on SHA-1, a hash function that was shown to have certain weaknesses by security researchers from CWI Amsterdam and Google in 2017. Although these weaknesses are not yet exploited in practical attacks, there was concern that this might happen in the future. Finally, the need to support four different TLS protocol versions would increase the misconfiguration likelihood.