What is TLS/SSL? How It Works

TLS (Transport Layer Security) is a cryptographic protocol that encrypts data sent over a network, so that information exchanged between a client and a server stays private and unaltered. SSL (Secure Sockets Layer) is its predecessor. TLS is what puts the ‘S’ in HTTPS.

TLS (Transport Layer Security) is the protocol that secures data in transit across the internet. It encrypts the connection between a client, such as a browser, and a server, so no one in between can read or tamper with the data. It also authenticates the server using a digital certificate. SSL is the older, now-deprecated predecessor, though the term is still used loosely. TLS is what makes HTTPS secure.

Key Takeaways

• TLS (Transport Layer Security) encrypts data in transit and authenticates the server, keeping information exchanged between a client and server private and tamper-proof.
• SSL (Secure Sockets Layer) is the deprecated predecessor of TLS. The two are often referred to together as ‘SSL/TLS’, and certificates are still commonly called ‘SSL certificates’, but modern systems use TLS.
• The current version is TLS 1.3 (2018), which is faster and more secure than earlier versions. TLS 1.0 and 1.1 are deprecated and should be disabled.
• A TLS session begins with a handshake that authenticates the server via its certificate and establishes a shared session key. Modern TLS uses ephemeral Diffie-Hellman key exchange for forward secrecy.
• Publicly trusted TLS certificate lifetimes are shrinking: the maximum validity drops to 200 days in 2026, 100 days in 2027, and 47 days by 2029, which makes certificate automation essential.

TLS and SSL: What Is the Difference?

SSL (Secure Sockets Layer) was the original protocol for encrypting web traffic, developed by Netscape in the 1990s. It went through versions up to SSL 3.0, which was found to have serious security flaws. When SSL was overhauled, the next version was renamed: instead of SSL 4.0, it became TLS 1.0. TLS is therefore the direct successor to SSL, and every version of SSL is now deprecated and considered insecure.

In everyday language, people still say ‘SSL’ when they mean TLS, and digital certificates are widely called ‘SSL certificates’ even though they are used for TLS. The accurate term for the protocol in use today is TLS. The versions matter: TLS 1.2 (2008) is still widely used, and TLS 1.3 (2018) is the current, most secure version, having removed outdated algorithms and streamlined the handshake. TLS 1.0 and 1.1 were formally deprecated in 2021 and should be disabled.

What TLS Actually Provides

A TLS connection delivers three security guarantees at once:

• Encryption: The data exchanged is scrambled so that anyone intercepting the traffic sees only ciphertext.
• Authentication: The server proves its identity with a digital certificate issued by a trusted certificate authority, so the client knows it is talking to the real site and not an impostor.
• Integrity: Each message carries a cryptographic check so any tampering in transit is detected.

When you see HTTPS and a padlock in your browser’s address bar, TLS is protecting that connection. Beyond web browsing, TLS also secures email, messaging, voice and video calls, APIs, and countless other services that need private, authenticated communication.

How the TLS Handshake Works

Every TLS connection begins with a handshake: a short negotiation in which the client and server agree on how to secure the session and establish a shared key. Modern TLS works roughly as follows, using a browser connecting to a website as the example.

• Client hello: The client contacts the server and sends the TLS versions and cipher suites it supports, along with some random data.
• Server hello and certificate: The server chooses a mutually supported TLS version and cipher suite, and sends its digital certificate, which contains its public key and is signed by a trusted certificate authority.
• Certificate verification: The client verifies the certificate against its list of trusted certificate authorities, confirming the server’s identity and that the certificate is valid and not expired or revoked.
• Key exchange: The client and server use ephemeral Diffie-Hellman key exchange to independently derive the same shared secret without ever transmitting it. This provides forward secrecy, meaning that even if the server’s private key is later compromised, past sessions cannot be decrypted.
• Session established: Both sides derive a symmetric session key from the shared secret and switch to fast symmetric encryption (such as AES) for the rest of the session. The session key is discarded when the connection closes.

This is the same hybrid pattern used elsewhere in cryptography: asymmetric techniques authenticate the server and establish the key, then fast symmetric encryption protects the bulk of the data. TLS 1.3 streamlined this handshake so it completes in a single round trip, making connections faster as well as more secure. (Older versions of TLS supported RSA key transport, where the client encrypted a secret with the server’s public key; TLS 1.3 removed this in favor of Diffie-Hellman for forward secrecy.)

TLS Certificates and the Certificate Authority

TLS authentication depends on digital certificates issued by a certificate authority (CA), a trusted third party that verifies an organization controls a domain before issuing a certificate for it. The certificate binds the server’s identity to its public key, and browsers trust it because they trust the CA that signed it. This chain of trust is part of public key infrastructure (PKI). When a certificate expires or is misconfigured, browsers show a security warning and may block access entirely, which is why certificate management matters operationally, not just cryptographically.

Certificate Lifetimes Are Shrinking Fast
In April 2025 the CA/Browser Forum approved a phased reduction in the maximum validity of publicly trusted TLS certificates, from 398 days today down to 47 days. The schedule:
– From March 15, 2026: maximum 200 days
– From March 15, 2027: maximum 100 days
– From March 15, 2029: maximum 47 days
This applies to publicly trusted certificates, not internal PKI. The goal is to limit the damage from compromised keys and to push the industry toward automation and crypto-agility. At 47 days, manual certificate renewal becomes impractical, so automated certificate lifecycle management is quickly becoming essential.

Why TLS Is Necessary

Without TLS, data travels across the network in plaintext, where anyone positioned between the client and server can read or alter it. A login form submitted over an unencrypted connection exposes the user’s credentials to any eavesdropper on the path. TLS closes that exposure by encrypting the channel end to end, so only the intended parties can read the data.

Today TLS is effectively mandatory. Major browsers mark plain HTTP sites as ‘Not Secure’ and increasingly refuse to load them, search engines favor HTTPS, and virtually every online service, from banking to email to APIs, depends on TLS. It has moved from a best practice to a baseline requirement of being on the internet at all.

TLS and the Post-Quantum Transition

TLS relies on asymmetric cryptography for its key exchange, and that is exactly what a future quantum computer could break using Shor’s algorithm. Because encrypted traffic captured today could be decrypted later (a harvest-now-decrypt-later attack), the TLS ecosystem is already adopting post-quantum key exchange.

Major browsers and servers now support hybrid key exchange that combines a classical algorithm with the post-quantum ML-KEM (FIPS 203), protecting sessions without waiting for a full migration. The symmetric encryption that protects the session data, such as AES-256, remains secure. Shorter certificate lifetimes are partly intended to make the eventual algorithm transition smoother.

How Encryption Consulting Helps

TLS is only as reliable as the certificates and cryptography behind it, and with certificate lifetimes shrinking and post-quantum algorithms arriving, that is getting harder to manage by hand. Encryption Consulting’s Encryption Advisory Services help organizations assess their TLS and certificate posture, enforce strong protocol versions and cipher suites, plan for the move to shorter certificate lifetimes and automated certificate lifecycle management, and prepare their encryption for the post-quantum transition, all aligned to NIST and industry guidance. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

What is TLS/SSL in simple terms?

TLS (Transport Layer Security) is a protocol that encrypts information sent between your device and a website or service, so no one in between can read or change it. SSL (Secure Sockets Layer) is its older predecessor, now deprecated, though people still say ‘SSL’ out of habit. TLS is what makes a website’s connection secure, shown by HTTPS and the padlock in your browser. It protects logins, payments, emails, and more.

What is the difference between TLS and SSL?

SSL is the original protocol for encrypting web traffic, and TLS is its successor. When SSL 3.0 was overhauled, the next version was renamed TLS 1.0 rather than SSL 4.0. All SSL versions are now deprecated and insecure, while TLS is actively used, with TLS 1.3 being the current version. The terms are often used interchangeably, and certificates are still called ‘SSL certificates’, but the protocol in use today is TLS.

What is the latest version of TLS?

The latest version is TLS 1.3, published in 2018. It is faster and more secure than earlier versions: it removed outdated and weak cryptographic options, and it streamlined the handshake so a secure connection can be established in a single round trip. TLS 1.2, from 2008, is still widely used and considered secure when properly configured. TLS 1.0 and 1.1 were deprecated in 2021 and should be disabled.

How does the TLS handshake work?

The TLS handshake is a short negotiation at the start of a connection. The client sends its supported TLS versions and cipher suites. The server responds with its choice and its digital certificate. The client verifies the certificate against trusted certificate authorities to confirm the server’s identity. The two then use Diffie-Hellman key exchange to derive a shared secret without transmitting it, and switch to fast symmetric encryption for the session.

Why are TLS certificate lifetimes being shortened to 47 days?

In April 2025, the CA/Browser Forum approved a phased reduction in the maximum validity of publicly trusted TLS certificates, reaching 47 days by March 2029, with intermediate limits of 200 days in 2026 and 100 days in 2027. The goal is to limit how long a compromised or outdated certificate stays valid, and to push the industry toward automation and crypto-agility. It makes automated certificate lifecycle management essential, since manual renewal is impractical at that frequency.

Is TLS safe against quantum computers?

The symmetric encryption TLS uses to protect session data, such as AES-256, is considered quantum-safe. However, the asymmetric key exchange that sets up a TLS session relies on algorithms a quantum computer could break. To address this, major browsers and servers have begun deploying hybrid post-quantum key exchange, combining a classical algorithm with the post-quantum standard ML-KEM (FIPS 203), which protects against harvest-now-decrypt-later attacks where captured traffic is decrypted in the future.

Get Ahead of Shorter Certificates and Post-Quantum TLS

Between 47-day certificates and the post-quantum transition, TLS management is becoming a moving target. Explore Encryption Consulting’s Encryption Advisory Services to assess your TLS and certificate posture and prepare for what is coming.