The world is moving to TLS 1.3, which is a very good thing! This article offers a high-level overview of TLS 1.3, and a discussion on the effectiveness of its new features.
Transport Layer Security
Transport Layer Security, or TLS, is a cryptographic protocol that protects data exchanged over a computer network. TLS has become famous as the S in HTTPS. More specifically, TLS is used to protect web user data from network attacks.
TLS was designed as a more secure alternative to its predecessor Secure Sockets Layer (SSL). Over the years, security researchers have discovered heaps of vulnerabilities affecting SSL, which motivated IETF to design TLS in an effort to mitigate them.
Ironically, earlier versions of TLS were also affected by dangerous vulnerabilities, which led ultimately to TLS 1.2 (i.e. the default version recommended by industry professionals).
The majority of known protocol vulnerabilities were mitigated in TLS 1.2, but this level of security still was the result of a series of patches on top of a flawed design.
As a response, TLS 1.3 was drafted from scratch in an effort to cleanly design a modern and secure TLS protocol. Five years of testing later, it has finally been approved and is now close to being the default Internet security standard.
TLS versions and their respective RFC documents can be found in the list below:
- TLS 1.0 was published as RFC 2246 in 1996
- TLS 1.1 was published as RFC 4346 in 2006
- TLS 1.2 was published as RFC 5246 in 2008
- TLS 1.3 was published as proposed standard in RFC 8446 in 2018.
How do older TLS versions work?
To effectively discuss the benefits of TLS 1.3, we must first talk about how older TLS versions work (and how they don’t).
TLS is a hybrid cryptosystem, meaning that it uses both asymmetric (public key) and symmetric (password/phrase based) encryption. This is due to asymmetric cryptography being orders of magnitude slower than its symmetric equivalents.
Consequently, TLS only employs public keys so that clients and servers can securely exchange a symmetric key. This key can then used to encrypt all subsequent communications, avoiding the performance overhead imposed by asymmetric encryption.
TLS 1.2 supports multiple key exchange algorithms (e.g. RSA, DH, etc.), along with several algorithms (also known as ciphers) used to encrypt and decrypt messages. This large amount of alternative options requires clients and servers to negotiate, so that all parties use the same TLS parameters.
This negotiation is standardized in a protocol called handshake. If you are not familiar with it, please refer to this article for more information.
So what’s wrong with TLS 1.2?
Although TLS 1.2 has been proven to work just fine in most cases, there are concerns about the overall level of security and privacy it provides after years of patching and revisions.
Apart from security considerations, though, TLS 1.2 also imposes unnecessary performance and network overhead.
TLS 1.2 security issues
Over the years, researchers (and attackers) have discovered a slew of vulnerabilities in many TLS 1.2 components, including key exchange algorithms, ciphers and digital signatures. Some of these were implementation bugs which you might have heard of, such as Heartbleed or BERserk. However, some were protocol vulnerabilities – that is, they exploit bad design decisions in earlier TLS versions (i.e. before TLS 1.2).
Although the majority of implementation and other bugs were fixed in TLS 1.2, unfortunately the vulnerabilities in the protocol design cannot be remediated using just a software patch. As it turns out, to do that IETF had to completely redesign the handshake protocol in TLS 1.3.
There have been many concerns about TLS security, but one of the most impactful was the realization that TLS 1.2 (and all earlier versions, including SSL) is vulnerable to downgrade attacks due to a flaw in its handshake protocol design. More specifically, TLS 1.2 does not use digital signatures to protect the integrity of the handshake. Signatures protect part of the handshake, only after the cipher-suite negotiation.
As a consequence, attackers can manipulate any third-party cipher-suite negotiation that occurs in the same computer network (e.g. airport wifi), and force the use of an insecure cipher. They can then break that vulnerable cipher and gain unwarranted access to the entire conversation.
TLS 1.2 performance issues
Besides these security considerations, TLS 1.2’s need to negotiate numerous TLS parameters can impose a performance overhead on HTTPS (or other TLS protected) communications.
TLS 1.2’s 4-step handshake requires two round-trip exchanges, first to select the cipher-suite, and then to exchange the certificates and symmetric keys (or key shares).
This means that for every TLS connection to be established, two additional transactions with the server are required. As a result, TLS connections require more bandwidth and power than (unencrypted) HTTP, which can be particularly costly to Internet-of-Things (IoT) applications, where low power and bandwidth consumption are hard constraints.
TLS 1.2 privacy issues
Lastly, TLS 1.2 has been criticised for compromising web user privacy.
More specifically, TLS offers an extension known as Server Name Indication or SNI. SNI allows the hostname of a server to be included in the initial SSL handshake. This extension is used for virtual hosting, where servers may serve multiple domains on the same IP address and port, while presenting a different certificate for each domain.
In TLS 1.2, SNIs are sent unencrypted, so despite the use of HTTPS, a network attacker can leak this information and track the web pages a user visits.
How does TLS 1.3 fix all that?
TLS 1.2 (and earlier versions) were focused on maintaining backwards compatibility. Each version built upon the previous ones with minor revisions attempting to eliminate vulnerabilities published between TLS versions.
Regrettably, this also meant that bad protocol design decisions (e.g. the unprotected handshake) were also inherited in the newer versions.
TLS 1.3 abandons backwards compatibility in favor of a proper security design. It has been designed from scratch to provide functionality similar (yet not compatible) to TLS 1.2, but with significantly improved performance, privacy and security.
TLS 1.3 security
A core tenet of TLS 1.3 is simplicity. In the new version, all key exchange algorithms, except the Diffie-Hellman (DH) key exchange, were removed. TLS 1.3 has also defined a set of tried and tested DH parameters, eliminating the need to negotiate parameters with the server.
What’s more, TLS 1.3 no longer supports unnecessary or vulnerable ciphers, such as CBC-mode and the RC4 cipher. These ciphers are known to be susceptible to attacks, but were still supported in most TLS implementations for legacy compatibility. Fortunately, the recent rush of downgrade attacks affecting early TLS versions motivated IETF to entirely remove such ciphers from TLS 1.3.
In addition, TLS 1.3 requires servers to cryptographically sign the entire handshake, including the cipher negotiation, which prevents attackers from modifying any handshake parameters. This means that TLS 1.3 is architecturally impervious to the downgrade attacks that affected earlier TLS versions.
Finally, the signatures themselves were also improved by implementing a new standard, called RSA-PSS. RSA-PSS signatures are immune to cryptographic attacks affecting the signature schemes employed in earlier TLS versions.
TLS 1.3 performance
Besides improved security, the reduced set of parameters and the simplified handshake in TLS 1.3 also contributes to improving overall performance. Since there is only one key exchange algorithm (with baked-in parameters) and just a handful of supported ciphers, the absolute bandwidth required to set up a TLS 1.3 channel is considerably less than earlier versions.
Furthermore, TLS 1.3 now supports a new handshake protocol, called 1-RTT mode. In 1-RTT, the client can send DH key shares in the first handshake message, because it can be fairly certain of the parameters the server will use. In the rare case that the server does not support them, it can produce an error so that the client will send a different configuration.
Instead of negotiating the parameters first and then exchanging keys or key shares, TLS 1.3 allows a client to set up a TLS channel with only one round-trip transaction (instead of two, as it was previously done). This can have a great cumulative effect in the processing, power, and network resources that are required for a client to communicate with a server over TLS 1.3.
Performance optimizations don’t stop here though, with another TLS 1.3 feature, called the 0-RTT Resumption mode. When a browser visits a server for the first time and successfully completes a TLS handshake, both the client and the server can store a pre-shared encryption key locally.
If the browser visits the server again, it can use this resumption key to send encrypted application data in its first message to the server. This has the same latency as unencrypted HTTP, because initial handshakes are not required.
It should be noted that there have been some security concerns about 0-RTT mode in the past.
TLS 1.3 privacy
Learning from past mistakes, TLS 1.3 now offers an extension that encrypts SNI information. When used correctly, this extension prevents attackers from leaking the remote server’s domain name, so they have no method of tracking HTTPS user history. This feature provides greater privacy to Internet users than previous versions of TLS.
Conclusion
While TLS 1.2 has served honorably all these years, TLS 1.3 is provably more secure and efficient. TLS 1.3 has been extensively tested in experimental browser implementations, and it is now ready to replace TLS 1.2 as the network security protocol of choice. Publishing TLS 1.3 is a big step closer towards a faster and safer Internet for all.
Thanks for choosing SSL.com, where we believe a safer Internet is a better Internet.