Transport Level Security, formally called Transport Layer Security (TLS), addresses three core security problems: keeping data private during transmission, verifying that you’re communicating with the right server, and ensuring that data isn’t altered in transit. These three pillars, encryption, authentication, and integrity, protect virtually every secure connection you make online, from web browsing to email to banking.
The Three Problems TLS Solves
Encryption hides the data being transferred so that third parties can’t read it. When you submit a password, credit card number, or any other information over a TLS connection, that data is scrambled using symmetric cryptography. The encryption keys are unique to each connection and are negotiated at the start of the session, meaning no two connections share the same key.
Authentication ensures the parties exchanging information are who they claim to be. Without it, you could type in your bank’s URL and unknowingly connect to an imposter server. TLS uses digital certificates issued by trusted Certificate Authorities to prove a server’s identity before any sensitive data is exchanged.
Integrity verifies that data has not been forged or tampered with during transit. TLS attaches a message authentication code (MAC) to each chunk of data, calculated using a secret key. The MAC also includes a sequence number, so missing, extra, or replayed messages are detectable. If even a single byte changes between sender and receiver, the check fails and the data is rejected.
How Encryption Works in Practice
TLS breaks your data into chunks of up to 16,384 bytes. Each chunk is authenticated with a MAC, then encrypted before being sent. The original message boundaries aren’t preserved, meaning multiple small messages can be combined into one encrypted record, or a single large message can be split across several records. This is all invisible to you as a user.
The MAC is always computed before encryption takes place. This layered approach means an attacker would need to break the encryption first just to attempt tampering with the integrity check. Modern TLS also supports a method called AEAD (authenticated encryption with associated data), which handles encryption and integrity protection in a single step, reducing the chance of implementation errors.
How TLS Verifies Identity
Before your browser exchanges any real data with a website, it checks the server’s digital certificate. This certificate is issued by a Certificate Authority (CA) that has verified the server operator controls the domain name in question. Verification typically happens through one of a few methods: placing a specific value in a DNS record, responding to a challenge on the website, or negotiating a special TLS connection that proves domain control.
Some CAs go further with multi-perspective issuance corroboration, which validates domain control from multiple network locations around the world before issuing a certificate. This makes it harder for an attacker to fool the validation process by intercepting traffic on just one network path. The padlock icon in your browser means this certificate check passed and the connection is encrypted.
Forward Secrecy
One of the more important protections TLS provides is called Perfect Forward Secrecy (PFS). Without it, an attacker could record your encrypted traffic today, then decrypt all of it later if they ever obtained the server’s private key. PFS eliminates this risk by generating unique session keys automatically each time a connection is made. Even if an attacker compromises a server’s long-term private key, they can only access data from sessions where they also recovered that session’s specific key. Past and future sessions remain protected.
TLS 1.3 requires forward secrecy for all connections. Earlier versions supported it but didn’t mandate it, which meant some servers were configured without this protection.
The TLS Handshake
Every TLS connection begins with a handshake, a brief exchange where your device and the server agree on encryption settings, verify identity, and generate session keys. In TLS 1.2, this handshake requires two full round trips between client and server before any application data can flow. TLS 1.3 combines the initial handshake and cryptographic negotiation into a single round trip, cutting the setup time roughly in half.
TLS 1.3 also supports a zero round-trip (0-RTT) mode when reconnecting to a server you’ve visited before. This lets encrypted data flow immediately with the very first message, which noticeably speeds up page loads for returning visitors. The handshake itself consists of three phases: key exchange, server parameters, and authentication.
Where TLS Is Used
TLS isn’t limited to web browsing. It secures a wide range of network protocols, each typically assigned a dedicated port number for its TLS-protected version:
- HTTPS (port 443): encrypted web traffic
- IMAPS (port 993): encrypted email retrieval via IMAP
- POP3S (port 995): encrypted email retrieval via POP3
- Submissions (port 465): encrypted email sending
- LDAPS (port 636): encrypted directory lookups
- FTPS (port 990): encrypted file transfers
- DNS over TLS (port 853): encrypted DNS queries
- SIPS (port 5061): encrypted voice and video calls over SIP
- Syslog-TLS (port 6514): encrypted system logging
In total, dozens of protocols rely on TLS. Any time data needs to move securely between two systems over a network, TLS is the standard mechanism for protecting that channel.
Current TLS Versions
TLS 1.0 and 1.1 are considered insecure and are being phased out across the industry. Major cloud providers like Microsoft Azure are requiring TLS 1.2 or later for all connections, with a final deadline of August 31, 2025 for remaining services still accepting older versions. Most modern browsers have already disabled TLS 1.0 and 1.1 entirely.
TLS 1.2 remains widely supported and secure when properly configured. TLS 1.3, released in 2018, is the current recommended version. It removed support for older, weaker encryption methods, mandated forward secrecy, and simplified the handshake process. If your server or application still accepts TLS 1.0 or 1.1 connections, updating is not optional at this point; it’s overdue.