SSL and TLS handshake
🔒 What are SSL and TLS?
SSL (Secure Sockets Layer) is the original protocol from the 1990s that encrypts data between your browser and a website. It established the basics of web privacy but has known weaknesses and is no longer considered secure.
TLS (Transport Layer Security) is the modern, improved replacement for SSL. It fixes earlier flaws, adds stronger algorithms, and is the standard behind HTTPS 🔐.
👉In short: people still say “SSL,” but what we actually use today is TLS.
📜 Versions at a Glance
Protocol Versions Status
SSL SSL 1.0 (never released), 2.0 (1995), 3.0 (1996) 🔴 Deprecated / insecure
TLS TLS 1.0 (1999), 1.1 (2006), 1.2 (2008), 1.3 (2018) ✅ Use TLS 1.2 or 1.3
Best practice today: disable SSL, TLS 1.0, and TLS 1.1 on servers and clients.
🤝 The TLS/SSL Handshake — Step‑by‑client
🖼️ Diagram: TLS Handshake
High-level TLS/SSL handshake diagram showing ClientHello, ServerHello, certificate, key exchange, finished
Alternative caption: the browser and server agree on how to talk securely, verify identity, then exchange keys and switch to encryption.
ClientHello: Your browser says hello, lists supported encryption options, and sends a random number.
ServerHello: The server picks an option, sends its own random number, and usually sends a digital certificate (its ID).
Certificate Check: Browser verifies the certificate is valid and trusted.
Key Exchange: Both sides create a shared secret (session key) using secure math.
Finished: Each side proves the setup worked; encrypted communication begins.
🔐 Authentication — you’re on the real site.
🧩 Encryption — messages are scrambled.
🧭 Integrity — messages aren’t altered.
⚠️ Common Vulnerabilities During the Handshake
🔎 These attacks target weak settings, old versions, or buggy software.
Man‑in‑the‑Middle (MITM): An attacker intercepts messages between browser and server.
Downgrade Attacks: A trick to force an old, weak protocol (e.g., SSL 3.0).
Heartbleed (OpenSSL bug): A memory‑leak flaw that could expose secrets.
Replay: Re‑sending old handshake messages to confuse a system.
🛡️ Defense Mechanisms & Best Practices
Disable SSL, TLS 1.0, TLS 1.1.
Use TLS 1.3 (or at least 1.2) and strong cipher suites.
Enable Perfect Forward Secrecy (PFS) (e.g., ECDHE key exchange).
Use strong certificates (2048‑bit RSA or ECDSA) and renew them regularly.
Implement HSTS and consider certificate pinning in apps.
Patch TLS libraries (OpenSSL, BoringSSL, etc.) promptly.
Turn on OCSP stapling to speed up and harden revocation checks.
✅ Secure by default: Prefer TLS 1.3 everywhere.
🚀 Why TLS 1.3 Is Better
Fewer steps → faster page loads.
Removes outdated, risky options.
Forward secrecy is mandatory.
Supports 0‑RTT resumption (with anti‑replay considerations).
🌍 Real‑World Examples
Banking websites: Protect login and transactions with TLS 1.3 and HSTS.
e‑Commerce checkouts: Encrypts card details; certificate shows the site is genuine.
APIs & microservices: Use Mutual TLS (mTLS) so both sides prove their identity.
Public Wi‑Fi browsing: HTTPS prevents snooping on open networks.
❓ FAQ
Q. Is SSL the same as TLS?
A. People use the word “SSL,” but what’s actually used today is TLS—the secure successor.
Q. What happens if the handshake fails?
A. The browser will show an error (e.g., certificate not valid, protocol mismatch). Update the server settings, certs, or try a modern browser.
Q. Do I need TLS on every page?
Use Strict‑Transport‑Security (HSTS).
📌 Key Takeaways
Use TLS 1.3 (or 1.2) only.
Keep certificates and TLS libraries updated.
Enable PFS, HSTS, OCSP stapling; consider pinning where appropriate.
The handshake authenticates, encrypts, and protects integrity in milliseconds.
Comments
Post a Comment