What Is TLS? (Transport Layer Security)
TLS is the protocol that encrypts data in transit on the internet. It powers HTTPS, protects API calls, and authenticates servers. Here is what it actually does and how it works.
Quick Answer
TLS (Transport Layer Security) is a cryptographic protocol that encrypts communication between two parties over a network. It provides confidentiality (data cannot be read), integrity (data cannot be tampered with), and authentication (you are talking to the right server). HTTPS is HTTP running over TLS.
TL;DR
- →TLS encrypts data in transit — it protects traffic between client and server from eavesdropping and tampering.
- →"SSL" is the old name; TLS 1.2 and 1.3 are the current standards. SSL 2.0, 3.0, TLS 1.0, and 1.1 are all deprecated.
- →TLS provides three things: confidentiality, integrity, and server authentication.
- →The handshake negotiates algorithms and derives session keys using asymmetric cryptography, then switches to symmetric encryption for the session.
- →Certificates are signed by Certificate Authorities (CAs) that your OS/browser trusts — this is how servers prove their identity.
- →TLS does not protect data at rest, does not prevent server compromise, and does not authenticate the client by default.
- →TLS 1.3 is faster and more secure than 1.2 — use it if your stack supports it.
What TLS Is
TLS is a protocol that runs between the application layer (HTTP, SMTP, etc.) and the transport layer (TCP). It creates an encrypted channel over which application data flows securely. When you see https:// in a URL, the connection is using TLS.
TLS protects against three categories of attack:
- Eavesdropping — a passive attacker on the same network (coffee shop Wi-Fi, ISP, CDN) cannot read your traffic.
- Tampering — an active attacker cannot modify packets in transit without the receiver detecting it.
- Impersonation — the client can verify it is talking to the legitimate server and not an attacker's server.
TLS is about protecting data in transit. For protecting data at rest (in databases, backups, object storage), see the complete encryption guide.
TLS vs SSL
SSL (Secure Sockets Layer) was the original protocol developed by Netscape in the 1990s. It has been fully superseded by TLS, but the industry never stopped saying "SSL." When anyone says "SSL certificate," "SSL/TLS," or "enable SSL," they mean TLS.
| Version | Year | Status |
|---|---|---|
| SSL 2.0 | 1995 | Deprecated — never use |
| SSL 3.0 | 1996 | Deprecated — POODLE attack (2014) |
| TLS 1.0 | 1999 | Deprecated — RFC 8996 (2021) |
| TLS 1.1 | 2006 | Deprecated — RFC 8996 (2021) |
| TLS 1.2 | 2008 | Still widely used — acceptable with modern cipher suites |
| TLS 1.3 | 2018 | Current standard — prefer this |
What TLS Provides
Traffic is encrypted using a symmetric cipher (AES-GCM or ChaCha20-Poly1305 in TLS 1.3). Only the client and server with the session key can read the data.
Network observers see only ciphertext and connection metadata (IP addresses, timing, approximate payload sizes).
Each TLS record includes an authentication tag (via AEAD ciphers like AES-GCM). Any modification to a packet in transit causes the receiver to reject it immediately.
This is the same integrity guarantee provided by HMAC, built into the cipher itself.
The server presents a certificate signed by a trusted Certificate Authority. The client verifies the signature chain and the hostname matches the certificate's Subject Alternative Names.
Client authentication is optional — requires mutual TLS (mTLS) for service-to-service use cases.
How TLS Works: The Handshake
Before encrypted data flows, the client and server complete a handshake to negotiate parameters and establish shared session keys. TLS 1.3 reduced this to a single round trip.
The client sends the TLS version it supports, a list of cipher suites, and a random nonce. In TLS 1.3 it also sends key shares upfront.
The server selects a cipher suite and TLS version, sends its own random nonce and key share, and presents its certificate.
Both sides use an ephemeral Diffie-Hellman (ECDHE) exchange to derive a shared pre-master secret — neither side transmits the secret directly. This enables forward secrecy.
The asymmetric (RSA/ECDSA) keys in the certificate are used only for authentication, not for encrypting the session.
Both sides independently derive identical symmetric session keys from the shared secret and the random nonces. All subsequent data is encrypted with these keys using AES-GCM or ChaCha20-Poly1305.
Both sides send a "Finished" message authenticated with the session key, proving the handshake was not tampered with. Encrypted application data then flows.
TLS 1.3 uses only AEAD ciphers for the session. See Authenticated Encryption and Integrity for a deeper look at why AES-GCM and ChaCha20-Poly1305 provide both confidentiality and integrity simultaneously.
Certificates and Trust
A TLS certificate is an X.509 document containing the server's public key, the domain name(s) it is valid for (Subject Alternative Names), an expiry date, and a digital signature from a Certificate Authority.
The trust model works as a chain:
- Your OS and browser ship with a list of trusted root CAs (DigiCert, Let's Encrypt, GlobalSign, etc.).
- A root CA signs intermediate CA certificates. Intermediates sign leaf certificates (the ones on servers). This is the certificate chain.
- When you connect, the server presents its leaf certificate and any intermediates. Your client walks the chain up to a trusted root, verifying each signature.
- The client also verifies the hostname in the certificate matches the hostname you connected to. A certificate for
example.comis not valid forapi.other.com.
Free certificates from Let's Encrypt are trusted by all major browsers and expire every 90 days (automation via ACME protocol / Certbot handles renewal). There is no security difference between a free DV certificate and a paid one for the purpose of TLS encryption — the encryption strength is identical.
Common Mistakes
✗ Clicking through certificate warnings
Certificate warnings mean the chain of trust is broken. This could be an expired cert, wrong hostname, or an active MITM attack. Never ignore them in production or train users to ignore them.
✗ Disabling certificate verification in code
Setting verify=False (Python requests), rejectUnauthorized: false (Node.js), or similar in development and forgetting to re-enable it in production eliminates all authentication. The connection is still encrypted but you cannot know who you are talking to.
✗ Serving mixed content
Loading JavaScript, CSS, or API calls over HTTP from an HTTPS page exposes that sub-resource to attackers and triggers browser warnings. All resources on an HTTPS page must also be HTTPS.
✗ Relying on TLS alone for internal service-to-service calls
TLS authenticates the server but not the client by default. For internal microservices you want mutual TLS (mTLS) or a separate auth layer (bearer tokens, API keys) to confirm the calling service is authorized.
✗ Using outdated TLS configurations
Accepting TLS 1.0/1.1 or weak cipher suites (RC4, 3DES, CBC-mode without HMAC) for compatibility with old clients creates downgrade attack risk. Enforce TLS 1.2+ and use AEAD cipher suites.
✗ Thinking HTTPS means the site is safe
TLS only encrypts the connection. A phishing site, a site serving malware, or a compromised server can all use valid TLS certificates. The padlock means "encrypted connection to this domain," not "this site is trustworthy."
Try the Tool: JWT Decoder
JWTs are commonly used for authentication and are almost always transmitted over TLS-protected API calls. Use the JWT Decoder to inspect token claims, check algorithms, and verify expiry timestamps — all locally in your browser, without sending tokens to any server.
Open JWT Decoder →Frequently Asked Questions
Related Resources
Encryption Guides
Complete Guide to Encryption, Hashing & Encoding
Pillar reference — when to use encryption, hashing, encoding, and HMAC
Authenticated Encryption and Integrity
AES-GCM and ChaCha20-Poly1305 — the ciphers TLS 1.3 uses
Hashing and HMAC
Integrity, authentication, and when to use each
Encryption at Rest vs In Transit
Threat models, technologies, and what you need for each