Building on the legacy of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encryption protocols, the recently ratified TLS 1. 3 looks to set a new standard for secure web communications and online application deployment.
As we’ll see, improvements in security aren’t all that TLS 1. 3 has to offer. But there are technical considerations which are likely to affect the speed of its adoption – particularly for enterprise network security.
Transport Layer Security (TLS)
Once the communications and business potential of the internet became apparent, it also became clear that some method was required to provide secure data transfers, and allow the growing electronic commerce or eCommerce sector to flourish. In the mid-1990s, this came in the form of the Secure Sockets Layer (SSL) protocol – an encryption standard initially developed by Netscape (the producer of the market-leading web browser of that time).
SSL 1.0 was never publicly released, and its successor SSL 2.0 had serious weaknesses. Released in 1996, SSL 3.0 addressed many of these issues, but was still felt to be not quite all that it should be.
By the time the next version of the SSL protocol was developed in 1999, the Internet Engineering Task Force (IETF) re-badged it under a new name as Transport Layer Security or TLS. The new standard made minor but significant alterations to what had come before, and web communications encryption is still often referred to under the blanket term of SSL/TLS.
Transport Layer Security is designed to encrypt internet data traffic of all kinds, but it finds its most common application in the protection of web data transfer. It’s the foundation of the secure HTTP or HTTPS standard for web pages, which users can readily identify by the locked padlock icon that appears whenever a browser or internet-enabled application reaches a secured website.
Requirements for Secure Web Communications
Online data transfers require that communications be secured specifically between web-enabled applications and browsers, and more generally between servers, clients, and applications that interact on a reliable medium. Transport Layer Security allows for this through the provision of three key services:
- Confidentiality: Strong encryption is used to scramble the data passing between two communicating parties (e.g., client and server), so that even if it’s intercepted, the eavesdropper would have a very hard time trying to make sense of it.
- Authentication: Procedures to enable each party in a communication to determine that the other parties are actually who they claim to be.
- Integrity: Mechanisms to ensure that the data being transmitted and received has not been tampered with.
Much of this activity occurs during the first stage of contact between the communicating parties – an exchange of information known as a handshake. In Transport Layer Security the initial handshake period is when the connecting parties decide on which web communications protocols they’re going to use, establish the type of encryption and how its keys will be handled, and take the necessary steps to authenticate each other.
The reliability of encrypted web communications greatly depends on the security of a server’s private encryption key. If this value is discovered by a hacker, it may be possible for them to use the key to decipher previous encrypted communications in which that server was involved.
In Transport Layer Security, a mechanism known as forward secrecy is used to protect the confidentiality of past sessions so that they can remain secret going forward. However, for previous versions of the TLS protocol, this has only been an optional feature.
TLS 1.3 enforces forward secrecy by default, for all Transport Layer Security sessions. Unlike previous versions of the protocol, a single secret value is no longer used to decrypt multiple sessions. Rather, the Ephemeral Diffie-Hellman key exchange protocol is employed under TLS 1.3 to generate a one-time key that’s used only for the current network session. This key is discarded at the end of each session.
Each session key is unable to decode data sent during an earlier session – and it can’t be used to help an attacker discover future session keys. Since the unique key generated for each session is required to decrypt that specific communication and that one alone, even if hackers or spies are able to record and store previously encrypted network traffic, under TLS 1.3 they’ll be unable to decipher it.
The previous version of the protocol, TLS 1.2, was defined in RFC 5246 and has been in use for the past eight years, supported by the majority of web browsers. Like earlier iterations, TLS 1.2 allows older cryptographic techniques to be used, in order to support older computer systems. This approach exposes the protocol to several vulnerabilities, most notably “man-in-the-middle” or MitM attacks, where a hacker intercepts data packets in mid-stream of a communication and sends them on after reading them or making alterations. The past two years have also revealed vulnerabilities to POODLE, SLOTH, and DROWN attacks.
Support for legacy encryption systems has been dropped in TLS 1.3, which was officially published on August 10th, 2018 by the Internet Engineering Task Force (IETF). Some backwards compatibility has been retained so that connections can fall back to TLS 1.2 if one end isn’t capable of using the newer encryption systems specified by the TLS 1.3 approved list. But there are mechanisms in place to terminate a connection if (for example) a hacker tries to force a roll-back to TLS 1.2 so that they can stage an attack.
Performance Improvements with TLS 1.3
TLS 1.3 brings significant speed gains in the handshake negotiation of protocol versions and cipher systems, and the authentication of servers. Under TLS 1.2, the time taken for a client to send a message to a server and for the server to respond (known as the Round Trip Time or RTT) would have to be effectively doubled (to 2-RTT), with multiple messages being exchanged between the client and server during a handshake.
TLS 1.3 cuts this initial handshake down to a single round trip (1-RTT) for most purposes. In many cases, the protocol may even be configured for a “zero” round trip or 0-RTT, where a web client remembers its previous session and automatically resumes. These 0-RTT exchanges should result in quicker loading and connection to web pages, faster web communications, and a generally more responsive internet experience.
In addition to its use of Ephemeral mode Diffie-Hellman key exchange to provide forward secrecy, TLS 1.3 also encrypts all handshake exchanges between the client and server, after the initial client “hello.” This includes all the digital certificate data used in the handshake.
Implications for Enterprise Network Security
It’s been observed that organizations which rely on passive or in-line methods for network security (where monitoring tools or intrusion prevention devices are located within network data streams and can observe or affect them directly) may have problems with the new protocol. That’s because TLS 1.3 removes the RSA key exchange mechanism that usually makes it possible for network monitoring tools to share a server or application’s private keys with a decryption device, so that network data may be deciphered and analyzed.
And with all data packets in the TLS 1.3 handshake being encrypted after the initial client hello, network security systems that rely on examining server certificates are likely to be affected as well.
Possible Effects on TLS 1.3 Adoption
These complications may affect the ability of many enterprise users to quickly adopt the TLS 1.3 protocol. However, there are some workarounds (which we’ll highlight in the recommendations that follow) that may help speed up the process.
To date, none of the major browsers such as Chrome or Firefox have enabled TLS 1.3 by default, though Mozilla has confirmed that TLS 1.3 draft 28 is currently shipping with Firefox 61. Firefox 63 (due for release in October) is promised to include the final version of TLS 1.3. Google have incorporated TLS 1.3 support in their Chrome 65 web browser and subsequent versions.
Elsewhere, Facebook has enabled TLS 1.3 for use on its social media platform, and there’s support for the protocol on the Gmail system. Facebook claims that over 50% of its internet traffic is currently secured under TLS 1.3. Online services like Cloudflare are already making TLS 1.3 available to their customers. Future updates to the leading browsers and web communications platforms are expected to include support for the new protocol.
- You can use the SSL Server Test tool to scan your domain and determine whether or not your server or host supports TLS 1.3.
- When configuring servers, it’s best to limit encryption cipher support to the newest systems compatible with the browsers you want to be able to connect to your website.
- Mozilla provides a TLS configuration generator to produce configuration files for web servers including Apache, Nginx, Lighttpd, HAProxy, and Amazon Web Services Cloud.
- Web browsers now include configuration options to set limits for handshake timeouts. These can be adjusted if TLS handshakes become slow or unresponsive.
- Enterprise network administrators may use a selection of alternative tools to avoid the complications raised by passive or in-line analysis. These include using network analytics and machine learning to study information from switches and routers, observing the behavior of endpoints based on metadata, and using cloud-based malware protection services.
- Finally, it should be noted that cyber-criminals may also use TLS 1.3 to encrypt command-and-control (C & C) traffic between their servers and malware installed on their victim’s computers. Analyzing network metadata about encrypted traffic may give administrators clues as to how to better secure their in-house and web communications.
Share this Post