The Transport Layer Security (TLS) protocol as it stands today has evolved from the Secure Sockets Layer (SSL) protocol from Netscape Communications and the Private Communication Technology (PCT) protocol from Microsoft that were developed in the 1990s, mainly to secure credit card transactions over the Internet.
It soon became clear that a unified standard was required, and an IETF TLS WG was tasked. As a result, TLS 1.0 was specified in 1999, TLS 1.1 in 2006, TLS 1.2 in 2008, and TLS 1.3 will hopefully be released soon. Each protocol version tried to improve its predecessor and mitigated some specific attacks.
As is usually the case in security, there is a “cops and robbers” game going between the designers and developers of the TLS protocol and the people who try to break it (be it from the hacker community or from academia). Unfortunately, this game is open-ended, meaning that it will never end and has no winner.
Since the early days of the SSL/TLS protocols, the security community has been struggling with various attacks that have made many press headlines. Examples include protocol-level attacks, like BEAST, CRIME, TIME, BREACH, Lucky 13, POODLE, FREAK, Logjam, DROWN, SLOTH, Sweet32, and the triple handshake attack, as well as pure implementation bugs, like Apple’s “goto fail” and Heartbleed.
In the evolution of the SSL/TLS protocols, all of these attacks and incidents were considered. For example, the weaknesses and vulnerabilities that enabled attacks like BEAST, POODLE, and Lucky 13, led to TLS 1.1. All remaining weaknesses and vulnerabilities have been taken into account in the specification of TLS 1.3 (the protocol version may still change, because the protocol changes are fundamental and substantial).
From a security perspective, TLS 1.3 is a major breakthrough and tries to get rid of all cryptographic techniques and primitives that is known to be weak and exploitable. For example, ciphers are only allowed in TLS 1.3, if they provide authenticated encryption with additional data (AEAD). Most importantly, this disallows all block ciphers operated in cipherblock chaining (CBC) mode that has been the source of many attacks in the past. It also disallows the formerly used technique to first authenticate data (by generating a message authentication code) and then encrypting it. Instead, both operations must be invoked simultaneously.
TLS 1.3 also disallows cryptographic algorithms that are known to be weak, such as stream ciphers like RC4, hash functions like MD5 or SHA-1, and block ciphers like 3DES, as well as all types of export-grade cryptography. Due to attacks like CRIME, TIME, and BREACH, we know today that the secure combination of compression and encryption is tricky, and TLS 1.3 therefore abandons TLS-level compression entirely. Finally, TLS 1.3 is highly efficient and can therefore get rid of session resumption and renegotiation. These shortcut features have led to distinct attacks in the past, i.e., session renegotiation and triple handshake attacks.
The bottom line is that TLS 1.3 represents the state-of-the-art in cryptographic research. Does this mean that the series of attacks, countermeasures, and counterattacks will eventually come to an end, and that we are going to see a stable situation in terms of security? Probably not. Once again, the problem is in the difference between theory and practice. To put it into the words of Albert Einstein: “In theory, theory and practice are the same. In practice, they are not.” This quote is true, and it is certainly also true for TLS 1.3. In theory, TLS 1.3 is secure, but in practice, we don’t know.
There are at least two uncertainties: First, we don’t know how well the protocol is going to be implemented (keep in mind that in any nontrivial security protocol, implementation bugs are likely to occur). Second, the implementations of the protocol need to be configured and used in proper ways (keep in mind that security breaches often occur, because security products are misconfigured or misused).
This is similar to the real world: If we have a security system in place (e.g., a burglar alarm system), we can still misconfigure it or use it in a way that is inappropriate and makes its security obsolete.
Security is and remains to be a tricky and multifaceted business. There are many things that can go wrong. A mathematician would say that having secure technologies in place is a necessary but not sufficient condition to achieve security.
Many complementary things must be in place so that a technology can unfold its real power. This also applies to TLS security in general, and TLS 1.3 in particular. The most important example to mention here is a proper way to manage public key certificates on a global scale. This is still one of the Achilles heels in properly using TLS. You may stay tuned: The “cops and robbers” game is likely to continue and you may even participate in this challenging game.
Rolf Oppliger is also the author of SSL and TLS: Theory and Practice, Second Edition, which provides a comprehensive overview of the SSL/TLS and DTLS protocols.