TLS (Transport Layer Security) is the cryptographic protocol that encrypts communication between clients and servers. It's the foundation of HTTPS, securing every browser connection, API call, and email transfer on the internet. Per RFC 8446, TLS 1.3 is the current standard, offering a faster handshake, stronger cipher suites, and mandatory forward secrecy compared to TLS 1.2.
Key takeaways
- TLS encrypts data in transit between clients and servers. It's the protocol behind HTTPS.
- TLS 1.3 (RFC 8446) is the current standard with a 1-RTT handshake and mandatory forward secrecy.
- Per NIST, disable SSL, TLS 1.0, and TLS 1.1 in all environments.
- TLS certificates bind a public key to a domain name and are issued by Certificate Authorities.
- Let's Encrypt provides free, automated TLS certificates via the ACME protocol.
Quick explanation
In simple terms
TLS is the protocol that encrypts your internet connection. When you see the padlock icon in your browser, TLS is protecting the data between your device and the server.
Technical definition
TLS is a cryptographic protocol (RFC 8446 for v1.3) that provides confidentiality, integrity, and authentication for network communication using X.509 certificates, asymmetric key exchange (ECDHE), symmetric bulk encryption (AES-GCM), and HMAC/AEAD for message authentication.
Analogy
TLS is like a secure phone line. Before you start talking (sending data), both parties agree on a secret code (handshake), verify each other's identity (certificates), and then all conversation is encrypted so no one listening on the wire can understand it.
Definition
TLS is the cryptographic protocol that encrypts communication between clients and servers over the internet. Per RFC 8446, TLS 1.3 is the current standard. It protects HTTPS, email, VPNs, and other network traffic from eavesdropping and tampering.
TLS (Transport Layer Security) is a cryptographic protocol that provides confidentiality, integrity, and authentication for network communication. Per RFC 8446, TLS 1.3 is the current version, replacing TLS 1.2 (RFC 5246) and all deprecated SSL versions.
TLS works by performing a handshake between client and server to negotiate encryption parameters, authenticate the server via X.509 certificates, and establish shared session keys. Once the handshake completes, all application data is encrypted with symmetric ciphers (AES-GCM). TLS protects HTTPS (web), SMTPS/STARTTLS (email), LDAPS (directory), and many other protocols.
Why it matters
Core concepts
TLS Handshake
The process where client and server negotiate encryption parameters and exchange keys before sending application data.
In TLS 1.2, the handshake takes 2 round trips: ClientHello/ServerHello, certificate exchange, key exchange, and Finished messages. TLS 1.3 reduces this to 1 round trip by combining key exchange with the ClientHello. The handshake establishes which cipher suite to use and generates session keys.
Example
When you visit https://example.com, your browser performs a TLS handshake with the server in about 50ms before any webpage content is transmitted.
Why it matters — The handshake is where security is established. A weak handshake (using deprecated ciphers or missing certificate validation) undermines the entire connection.
TLS Certificate
A digital document that binds a public key to a domain name, issued by a Certificate Authority (CA).
TLS certificates use X.509 format. A CA verifies domain ownership (DV), organization identity (OV), or extended validation (EV) before issuing the certificate. The client validates the certificate chain: server cert signed by intermediate CA signed by root CA trusted by the OS/browser.
Example
A Let's Encrypt certificate for example.com, valid for 90 days, containing the server's public key.
Why it matters — Certificates are the trust anchor. An expired, misconfigured, or compromised certificate breaks HTTPS and erodes user trust.
How it works
Client initiates the handshake
The client sends a ClientHello message containing supported TLS versions, cipher suites, and a random number. In TLS 1.3, the client also includes key share parameters.
Client → ClientHello
Server responds with certificate and parameters
The server responds with ServerHello (selected version, cipher suite, random number), its TLS certificate, and in TLS 1.3, the key share and encrypted extensions.
Server → ServerHello + Certificate
Certificate validation and key exchange
The client verifies the server's certificate chain against trusted root CAs. It then uses the server's public key and key exchange parameters to compute the shared session key.
Client verifies cert + computes keys
Encrypted communication begins
Both sides now have the same session keys. All subsequent application data (HTTP requests, API calls) is encrypted with symmetric encryption (AES-GCM) using these keys.
Encrypted application data
Benefits
Encrypts data in transit
TLS encrypts data in transit, preventing eavesdropping on passwords, credit cards, API keys, and other sensitive data sent over networks.
Authenticates server identity
TLS certificates prove server identity. The client verifies the certificate chain to confirm it's connecting to the legitimate server, not an impersonator.
Data integrity verification
TLS uses HMAC or AEAD ciphers to ensure data hasn't been modified in transit. Any tampering invalidates the MAC, causing the connection to fail.
Limitations
Performance overhead (mostly negligible on modern hardware)
LowTLS adds handshake latency (1 round trip for TLS 1.3, 2 for TLS 1.2) and CPU overhead for encryption/decryption, though modern hardware makes this negligible.
Workaround — Use TLS 1.3 for faster handshakes. Use session resumption (0-RTT) for repeat connections. Hardware TLS offloading on load balancers.
Certificate Authority trust model
MediumTLS relies on CAs to verify domain ownership. If a CA is compromised or issues fraudulent certificates, attackers can impersonate any domain.
Workaround — Monitor Certificate Transparency logs for unauthorized certificates. Deploy HPKP (deprecated) or expect-CT headers. Use CAA DNS records to restrict which CAs can issue certificates for your domains.
Examples
HTTPS with Let's Encrypt
A web server administrator enables HTTPS using a free TLS certificate from Let's Encrypt with Certbot.
Let's Encrypt uses the ACME protocol to automate domain validation and certificate issuance. Certbot runs on the server, proves domain ownership, and installs the certificate. Certificates are renewed automatically before expiration.
Comparisons
TLS vs. SSL
TLS 1.2 vs. TLS 1.3
Myths, corrected
Myth
SSL and TLS are the same thing
Correction
SSL is the deprecated predecessor. Per NIST, all SSL versions (2.0, 3.0) have known vulnerabilities and must be disabled. TLS 1.2 and 1.3 are the current standards. The term 'SSL certificate' persists in marketing but the certificate works with TLS.
Why it happens: The term 'SSL' was so widely used that it became synonymous with encrypted connections, even though the actual SSL protocol was deprecated over a decade ago.
Myth
HTTPS means the website is safe
Correction
HTTPS means the connection is encrypted, not that the website is trustworthy. A phishing site can have a valid TLS certificate from Let's Encrypt. HTTPS protects data in transit, not the intent of the server operator.
Why it happens: Browser padlock icons and 'secure' labels created a perception that HTTPS equals trust. Domain Validation certificates only verify domain ownership, not identity.
Practical implications
For admins
Disable TLS 1.0/1.1, configure TLS 1.3 as preferred, automate certificate renewal with ACME/Certbot, and test with SSL Labs.
For business
TLS certificate expiration causes outages and lost revenue. Automate renewal. Budget for certificate management across all services.
For security
Monitor Certificate Transparency logs. Enforce HSTS. Deploy TLS inspection on egress proxies for threat detection (with privacy considerations).
Decision guide
Use when
- Any network communication carrying sensitive data (which is effectively all modern traffic).
- HTTPS for web applications and APIs.
- Email encryption (SMTP STARTTLS, IMAPS, POP3S).
- VPN tunnels and remote access.
Related terms
HTTPS
HTTP encrypted with TLS. Uses port 443 by default.
X.509 Certificate
A digital document binding a public key to a domain, issued by a Certificate Authority.
Let's Encrypt
A free, automated Certificate Authority using the ACME protocol.
Frequently asked questions
What is the difference between TLS and SSL?
TLS is the current standard. SSL is deprecated. Per NIST, all SSL versions have known vulnerabilities. 'SSL certificate' is a marketing term; the actual protocol should always be TLS 1.2 or 1.3.
What is new in TLS 1.3?
TLS 1.3 uses a 1-RTT handshake (vs 2-RTT in 1.2), removes weak cipher suites (RC4, CBC mode, static RSA), mandates forward secrecy (ECDHE), and supports 0-RTT resumption.
Should I disable TLS 1.0 and 1.1?
Per NIST SP 800-52 Rev. 2, disable TLS 1.0 and 1.1 immediately. They contain known vulnerabilities (BEAST, POODLE, Lucky Thirteen) and are no longer supported by major browsers.
What is forward secrecy?
Forward secrecy ensures that compromising a server's private key doesn't decrypt past sessions. TLS 1.3 mandates ECDHE key exchange, which provides forward secrecy by default.
What is a cipher suite?
A cipher suite defines the algorithms used for key exchange, bulk encryption, and message authentication. Example: TLS_AES_256_GCM_SHA384 means AES-256 in GCM mode with SHA-384 for hashing.
Conclusion
TLS is the protocol that encrypts internet communication. Per RFC 8446, TLS 1.3 is the current standard with a faster handshake, mandatory forward secrecy, and removal of weak cipher suites.
Per NIST SP 800-52 Rev. 2, disable TLS 1.0, 1.1, and all SSL versions. Use TLS 1.2 with AEAD cipher suites as minimum, and TLS 1.3 wherever possible. Automate certificate management with ACME (Let's Encrypt) to prevent expiration-related outages.
Main takeaway
Explore certificate transparency logs, HSTS (HTTP Strict Transport Security), and mTLS (mutual TLS) for service-to-service authentication.
