TLS (Transport Layer Security)
A cryptographic protocol for secure data transmission over the Internet—it encrypts the connection between the client and the server, authenticates the server using a certificate, and protects against eavesdropping and tampering. The successor to SSL.
TLS (Transport Layer Security) is the most widely used cryptographic protocol in the world. Every HTTPS connection, every email transmission (STARTTLS), every VPN connection (OpenVPN, SSL-VPN), and many other protocols use TLS as a security layer.
TLS vs. SSL: The Differences
SSL (Secure Sockets Layer) was the predecessor to TLS, developed by Netscape in the 1990s. All SSL versions (1.0, 2.0, 3.0) and TLS 1.0 and 1.1 are now classified as insecure and have been disabled.
SSL 2.0 (1995) → insecure, obsolete
SSL 3.0 (1996) → POODLE attack, obsolete
TLS 1.0 (1999) → BEAST/POODLE, RFC 8996 deprecated
TLS 1.1 (2006) → RFC 8996 deprecated
TLS 1.2 (2008) → current, widely used
TLS 1.3 (2018) → recommended, faster and more secure
In common parlance, people often still say "SSL"—but they almost always mean TLS.
The TLS Handshake (Simplified)
TLS 1.2 (Simplified):
Client Server
| |
|── ClientHello ──────────────→ | (TLS version, cipher suites, random)
|← ServerHello ────────────────| (selected cipher suite, random)
|← Certificate ────────────────| (server certificate)
|← ServerHelloDone ────────────|
|── ClientKeyExchange ────────→ | (Pre-Master Secret, encrypted)
|── ChangeCipherSpec ─────────→ |
|── Finished ──────────────── → | (MAC over the entire handshake)
|← ChangeCipherSpec ───────────|
|← Finished ───────────────────|
| |
|═══ Encrypted app data ══|
TLS 1.3 (improved):
- 1-RTT handshake (instead of 2-RTT in TLS 1.2) → faster connections
- 0-RTT for connection recovery (with security trade-offs)
- No more RSA key exchange - only (EC)DHE for forward secrecy
- All weak cipher suites removed
- Simplified protocol (less attack surface)
TLS Security Features
Encryption: All transmitted data is encrypted—no eavesdropping (not even by ISPs or network operators).
Server Authentication: The server certificate verifies identity (via a PKI chain to a trusted CA). Protects against man-in-the-middle attacks when properly validated.
Forward Secrecy (PFS): Ephemeral Diffie-Hellman keys (DHE/ECDHE) ensure: Even if the long-term server private key is compromised, past sessions cannot be decrypted retroactively. Mandatory for TLS 1.3.
Integrity: HMAC (or AEAD algorithms) ensure that data cannot be manipulated without detection.
Cipher Suites
A cipher suite describes the algorithms used. Example:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ → Protocol
ECDHE_ → Key exchange (Elliptic Curve DHE → Forward Secrecy)
RSA_ → Authentication (Server certificate type)
WITH_ → Separator
AES_256_GCM_ → Encryption + Mode
SHA384 → Hashing for HMAC
Recommended Cipher Suites (BSI TR-02102-2):
TLS 1.3:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS 1.2 (backward compatibility):
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Insecure cipher suites (disable immediately):
- NULL cipher (no encryption)
- RC4 (BEAST attack)
- 3DES (SWEET32 attack)
- DES, export ciphers (40-bit keys)
- MD5 as a hash algorithm
Common TLS Vulnerabilities
Outdated protocol versions: Servers that still support TLS 1.0 or SSL 3.0 are vulnerable (BEAST, POODLE).
Weak cipher suites: Configuration errors allow downgrading to weak algorithms (FREAK, LOGJAM).
Certificate validation errors:
- Expired certificates → browser warning, users click through ("click-through")
- Self-signed certificates → no CA verification
- Missing hostname validation in apps → MITM possible
HSTS not set: Without HTTP Strict Transport Security (HSTS), an attacker can perform SSL stripping (downgrade to HTTP).
Certificate pinning missing (mobile apps): Without pinning, an attacker can perform MITM using their own CA certificate.
Testing TLS in practice
# Test TLS configuration (nmap)
nmap --script ssl-enum-ciphers -p 443 example.com
# SSL Labs API (A+ to F rating)
# Access via browser: ssllabs.com/ssltest/
# testssl.sh - local test
./testssl.sh --severity HIGH example.com
# OpenSSL - Check version and certificate
openssl s_client -connect example.com:443 -tls1_3
openssl s_client -connect example.com:443 | openssl x509 -noout -dates
TLS Configuration Recommendation
# nginx - BSI TR-02102-2 Recommendation
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# HSTS (min. 1 year, includeSubDomains)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
Mutual TLS (mTLS)
With standard TLS, only the server authenticates via a certificate. With mTLS, both sides authenticate:
Client → presents client certificate → Server
Server → presents server certificate → Client
Use cases:
- Microservices communication (zero-trust principle: no implicit network trust)
- API authentication (instead of API keys)
- VPN client authentication
- Zero-trust networks
mTLS is the technical foundation of many zero-trust architectures (SPIFFE/SPIRE, Istio Service Mesh).