TLS (Transport Layer Security) is the cryptographic protocol that gives an application connection confidentiality, integrity and server authentication over an untrusted network. Among Internet protocols it sits between the transport layer and the application, so HTTP, SMTP, IMAP and many other protocols can run unchanged on top of it.
TLS is the successor of SSL (Secure Sockets Layer), and the two names are still used interchangeably in everyday speech even though every SSL version is obsolete and insecure. The current versions are TLS 1.2 and TLS 1.3; HTTPS is simply HTTP carried inside a TLS session, and QUIC embeds the TLS 1.3 handshake directly into its own transport.
How the TLS handshake establishes a secure session
The handshake is the opening exchange in which client and server agree on parameters, authenticate the server and derive shared session keys. After it completes, all application data flows through the record layer, which encrypts and authenticates every record with those keys.
In TLS 1.3 the client sends a ClientHello with supported cipher suites, a random value and an ephemeral key share, usually for X25519 or P-256. The server answers with a ServerHello and its own key share, and both sides compute the same secret through Diffie-Hellman key exchange. The server then proves its identity by sending an X.509 certificate and a signature over the handshake transcript, and both sides confirm the result with Finished messages.
The following table summarizes the main handshake steps in TLS 1.3 and what each one achieves.
| Step | Sent by | Purpose |
|---|---|---|
| ClientHello | Client | Offers versions, cipher suites, key shares and the server name (SNI) |
| ServerHello | Server | Selects parameters and returns its key share |
| EncryptedExtensions | Server | Sends further settings such as ALPN, already encrypted |
| Certificate and CertificateVerify | Server | Proves possession of the private key for the certificate |
| Finished | Both | Confirms that both sides saw the same handshake |
Because the key share travels in the first message, a fresh TLS 1.3 connection needs one round trip before data can flow, compared with two round trips in TLS 1.2. Resumed sessions can use 0-RTT early data, which saves another round trip but is open to replay attacks and should carry only idempotent requests.
TLS versions and their security status
Each TLS version changed the protocol in ways that matter for security, so version support is a configuration decision, not a detail. Modern guidance permits only TLS 1.2 and TLS 1.3, and browsers have removed TLS 1.0 and 1.1 entirely.
| Version | Specification | Status | Main weakness or strength |
|---|---|---|---|
| SSL 3.0 | RFC 6101 | Prohibited | Vulnerable to the POODLE padding attack |
| TLS 1.0 | RFC 2246 | Deprecated | CBC weaknesses exploited by BEAST |
| TLS 1.1 | RFC 4346 | Deprecated | No modern AEAD ciphers |
| TLS 1.2 | RFC 5246 | Acceptable | Secure only with AEAD suites and forward secrecy |
| TLS 1.3 | RFC 8446 | Recommended | Smaller, safer design with mandatory forward secrecy |
TLS 1.3 removed static RSA key exchange, CBC-mode ciphers, compression and renegotiation. As a result, every TLS 1.3 connection has forward secrecy: a stolen server private key cannot decrypt traffic that was recorded earlier.
Cipher suites, certificates and key parameters
A cipher suite names the algorithms that protect the session. In TLS 1.3 it lists only the AEAD cipher and the hash function, for example TLS_AES_128_GCM_SHA256, while key exchange and signature algorithms are negotiated separately. TLS 1.2 suites bundle all four choices into one long name.
The table below lists the parameters that administrators most often configure and the values that are considered sound today.
| Parameter | Typical choice | What it affects |
|---|---|---|
| Key exchange group | X25519, P-256, hybrid post-quantum | Forward secrecy and handshake cost |
| Bulk cipher | AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305 | Speed and confidentiality of records |
| Certificate key | ECDSA P-256 or RSA 2048-3072 bits | Signature speed and compatibility |
| Certificate lifetime | 90 days to 398 days, trending shorter | Exposure window if a key leaks |
| Session resumption | Tickets or pre-shared keys | Latency of repeat connections |
Server authentication depends on the public key infrastructure. The client checks that the certificate chain leads to a trusted certificate authority, that the host name matches, and that the certificate is valid and not revoked. Mutual TLS (mTLS) adds a client certificate, which is common in service-to-service traffic and APIs.
How TLS relates to HTTPS, QUIC and other protocols
TLS is a general-purpose security layer, so its neighbors in the protocol stack use it in different ways. The comparison below shows how closely related protocols depend on it.
| Protocol | Relationship to TLS | Default port or transport |
|---|---|---|
| HTTPS | HTTP/1.1 or HTTP/2 inside a TLS session over TCP | TCP 443 |
| QUIC | Uses the TLS 1.3 handshake but its own packet protection | UDP 443 |
| DTLS | TLS adapted for datagrams, tolerant of loss and reordering | UDP, varies |
| STARTTLS | Upgrades a plaintext SMTP or IMAP session to TLS | TCP 25, 587, 143 |
| SSH | Separate secure protocol with its own handshake | TCP 22 |
Application-Layer Protocol Negotiation (ALPN) lets the client and server agree inside the handshake whether they will speak HTTP/1.1 or HTTP/2, and HTTP/3 always runs over QUIC. Server Name Indication (SNI) tells the server which host name the client wants, which allows many sites to share one IP address.
Common TLS misconfigurations and pitfalls
Most real TLS failures come from configuration and certificate management, not from broken cryptography. The following problems appear repeatedly in audits and incident reports.
- Expired certificates cause hard browser errors; automated renewal through the ACME protocol prevents most outages.
- Incomplete certificate chains work in some browsers and fail in others, because not every client fetches missing intermediates.
- Legacy protocol versions left enabled for old clients keep downgrade and padding attacks possible.
- Disabled certificate validation in application code, often added during testing, silently removes all authentication.
- Assuming TLS hides everything is wrong: IP addresses, traffic volume and timing remain visible, and SNI is visible unless Encrypted Client Hello is used.
TLS also protects data only in transit between two endpoints. A proxy or load balancer that terminates TLS sees plaintext, so traffic behind it needs its own protection when the internal network is not trusted.
In plain words
TLS is the sealed envelope of the Internet. When your browser talks to a website, TLS wraps every message so that nobody on the way can read it or change it without being noticed.
Before the conversation starts, the website shows an ID card, called a certificate, that a trusted authority has signed. Your browser checks the card, and the two sides secretly agree on a fresh key that only they know. The padlock in the address bar means this check succeeded and the connection is private and genuine.
A real-world example
An online retailer moves its checkout service behind a new load balancer. The operations team enables only TLS 1.2 and TLS 1.3, selects ECDSA P-256 certificates with RSA fallback for older devices, and turns on automatic renewal with a 60-day renewal trigger for its 90-day certificates.
During testing, an older Android payment terminal fails to connect because the server sends an incomplete chain without the intermediate certificate. After the chain is fixed, every client connects, the median handshake time drops because most browsers negotiate TLS 1.3 with one round trip, and the external scan reports no legacy protocols. The result is a checkout path that is faster and harder to attack without any change to the application code.