Transport Layer Security, or TLS, is a cryptographic protocol that provides secure communication by ensuring confidentiality, integrity, and authentication between two systems. It succeeds the older SSL encryption protocol, though you may still see TLS referred to as SSL in certain circles.
It uses what's known as a "TLS handshake" to establish secure keys and authenticity, allowing for a private, encrypted channel in applications like web browsers, email clients, VPNs, messaging, and more. While there are many encryption standards to choose from, TLS is designed to be highly secure and efficient while being flexible to implement.
What Is TLS Encryption?
- Introduced: 1999
- Current version: TLS 1.3 (released 2018, RFC 8446)
- Key sizes: Vary by algorithm (e.g., RSA up to 4096 bits, typical modern usage is 256-bit ECC or ephemeral Diffie-Hellman)
- Usages: Encrypting web browsers (HTTPS), messaging applications, VPNs, emails, and API communications
How TLS Evolved From SSL
To understand TLS, one needs to go back a few more years to 1995, when Netscape first released the TLS predecessor, Secure Sockets Layer, or SSL. The first official release was SSL 2.0, as previous drafts had serious security flaws. The Netscape Navigator team developed SSL 2.0 as a fast, efficient security protocol to quickly connect users to web pages, email clients, instant messaging applications, and more... as quickly as a 56k modem would go, anyway.
Unfortunately, SSL has been prone to flaws throughout its history. SSL 3.0 (1996) improved upon previous security flaws but still suffered from vulnerabilities. Due to the consistent security issues associated with SSL throughout most of its history, the Internet Engineering Task Force (IETF) developed TLS 1.0 based on the infrastructure of SSL 3.0 in 1999, taking over for the team at Netscape.
The current version, TLS 1.3, is considered to be both the most efficient and secure handshake protocol for most software and hardware communications globally.
What Is A TLS Handshake?
A TLS handshake occurs when two devices need to connect to one another over the open internet, through an FTPS connection, or on your internal network. The handshake is used to confirm the authenticity of the server (and optionally the client), agree on cryptographic parameters, and establish shared keys to encrypt the connection.
The handshake process for SSL/TLS has been refined over the years through different versions, with TLS 1.3 representing the most streamlined.
When a device requests a TLS 1.3 connection from a server, the checklist runs as follows:
- The client device sends what's known as a "ClientHello" to the receiver, containing both its supported versions and cipher suites. TLS 1.3 improves upon earlier versions by sending its key share instantly, reducing latency.
- The server responds with the chosen key agreement protocol, and then sends its digital certificate with its key share.
- Both the client and server use the exchanged key shares to independently create a shared secret key. From this, they each derive an identical set of symmetric session keys. The server then sends a "Finished" message encrypted with its session key, and the client does the same to confirm the handshake was successful.
In many instances, TLS 1.3 will only set up the initial connection using asymmetric encryption and then hand it off to a symmetric key encryption standard like AES-256 or ChaCha20. This hybrid approach of combining both symmetric and asymmetric key exchanges protects initial connections from man-in-the-middle attacks, improves performance for high-bandwidth activities, and provides PFS protection.
How Does TLS Secure Your Connection?
TLS uses both asymmetric and symmetric encryption to make your data and communications unreadable to anyone besides the sender and intended receiver. Asymmetric algorithms handle authentication and key exchange during the handshake, while symmetric algorithms encrypt the actual data exchange.
Three components are essential to how TLS guarantees your security: Encryption, Data Integrity, and Authentication.
Encryption
In the handshake, the server presents its digital certificate, which includes its public key. The client uses this to authenticate the server and perform a key exchange. After the key exchange, both the client and the server possess the same secret session keys and can encrypt or decrypt each other's communications.
RSA and ECC are common in certificates and key exchange. However, RSA key exchange was removed in TLS 1.3 because it doesn't support Perfect Forward Secrecy (PFS). RSA still appears in digital signatures, while ECC is preferred for modern key exchange due to efficiency and security. Perfect Forward Secrecy is a critical feature in the modern security environment. It's already a standard requirement in TLS 1.3 to protect against current and future threats.
Perfect Forward Secrecy
While available as an option in previous versions before TLS 1.3 , Perfect Forward Secrecy (PFS) was made mandatory as a part of TLS 1.3 when it released. This is because PFS guarantees that even if the current session key is somehow compromised, encrypted information from past or future unique session keys can't be cracked as well.
It also protects against what are known as "Harvest Now, Decrypt Later" tactics. These attacks aim to compromise a server's private key, and if successful, can take the encrypted communications to decrypt at a later date.
Data Integrity & Authentication
In encrypted communications, TLS acts as a sort of "referee" that determines that none of the data sent or received between both ends of the transaction has been tampered with. In TLS 1.3, this is done using ciphers that combine encryption and authentication in one step. If tampering is detected, the session is immediately terminated.
All of the security measures above are applied to any connection you make between multiple devices that use TLS to initiate the handshake.
Where Is TLS Still Vulnerable?
Though most modern devices, web browsers, and operating systems all use TLS 1.3 to establish and encrypt their connections, there are still legacy edge cases where TLS 1.2 or even TLS 1.1 may still be in use. TLS 1.1 is obsolete and insecure. TLS 1.2 remains widely supported, but some of its older cipher suites and configurations (such as those vulnerable to attacks like Lucky 13 and Logjam) are now considered weak.
Devices that may still use older versions of TLS than 1.3 to encrypt connections include (but aren't limited to):
- Legacy Windows, iOS, macOS, and Android builds: Connecting from a device running Windows Vista, Server 2003, and Server 2008 R1 will attempt to use TLS 1.2. Meanwhile, any devices running under macOS 10.9 or Android 4 will experience the same issues.
- Network printers and scanners: Many network-connected printers and scanners are configured with outdated TLS protocols and might fail when trying to connect to modernized email servers to retrieve and print documents wirelessly.
- Industrial control systems: A host of older ICS modules are out of date on TLS upgrades, and getting them current is an ongoing process across many critical infrastructure networks globally.
As scary as some of that may sound, though, as long as you are running a recently updated operating system, keep your browser version current, and only download authenticated applications from the web or app stores, your devices will automatically default to TLS 1.3 for most of their connections.
Conclusion
TLS is one of many protocols running quietly in the background of our online lives, making connecting worldwide a safe, secure, and encrypted experience. While you may not see its intricate handshake process or complex cryptographic exchanges, everything from online shopping to banking to daily browsing is made safer by the invisible hand of TLS operating silently in the background. Even with potential threats from "Harvest now, decrypt later" attacks and quantum computing on the horizon, TLS continues to evolve to address emerging threats.