SSL/TLS works by establishing an encrypted channel between the visitor's browser and the web server through a negotiation process called the handshake. During this process, both sides verify identities and agree on the keys they'll use to encrypt the conversation — all in a fraction of a second, before any user data is transmitted.
If you've ever wondered what actually happens behind the HTTPS padlock, this guide walks you through it from first principles to practical details.
SSL and TLS: Are They the Same?
Technically, no. SSL (Secure Sockets Layer) was the original protocol, developed by Netscape in the 1990s. TLS (Transport Layer Security) is its more secure, more efficient successor. SSL 2.0 and 3.0 are now deprecated and disabled on all modern servers.
Today, we use TLS 1.2 or TLS 1.3 — but the term "SSL" lives on in everyday language because that's what people learned first. When someone says "install an SSL certificate," they actually mean modern TLS.
| Version | Year | Current Status |
|---|---|---|
| SSL 2.0 / 3.0 | 1995–1996 | Obsolete, insecure, blocked |
| TLS 1.0 / 1.1 | 1999–2006 | Deprecated (disabled in modern browsers) |
| TLS 1.2 | 2008 | Current, widely supported |
| TLS 1.3 | 2018 | Recommended modern standard |
The Two Types of Encryption TLS Uses
To understand how SSL/TLS works, you need to distinguish two types of cryptography that operate in tandem:
Asymmetric Encryption (Public / Private Key)
This uses a mathematically linked key pair: a public key (visible to everyone) and a private key (known only to the server). What is encrypted with the public key can only be decrypted by the private key, and vice versa.
It's secure but computationally expensive. That's why TLS uses it only during the initial handshake — to exchange credentials and agree on a session key.
Symmetric Encryption (Session Key)
This uses a single shared key to both encrypt and decrypt. It's far faster than asymmetric encryption. Once the handshake completes, all communication uses symmetric encryption with the agreed session key.
The combination is elegant: asymmetric security for establishing the key, symmetric speed for transmitting the data.
The TLS Handshake, Step by Step
The handshake is the negotiation that occurs every time a browser connects to an HTTPS site. In TLS 1.3 it happens in a single round trip (1-RTT); TLS 1.2 required two. Here's the complete flow:
- ClientHello: the browser sends the server the TLS versions it supports, available cipher suites, and a random number.
- ServerHello: the server selects a TLS version and cipher suite, sends its own random number, and presents its digital certificate (which contains its public key).
- Certificate verification: the browser checks that the certificate was signed by a trusted Certificate Authority (CA), that the domain matches, and that it hasn't expired or been revoked.
- Key exchange: using the server's public key and both random numbers, both sides independently derive the same symmetric session key. No one else can compute it.
- Finished: each party sends a message encrypted with the session key to confirm the handshake succeeded. From this point on, all HTTP traffic travels encrypted with that key.
A complete handshake typically takes between 50 and 200 ms depending on network latency. TLS 1.3 optimized this significantly and also supports 0-RTT resumption for connections that were previously established.
What Exactly Does TLS Protect?
Once the connection is established, TLS protects the entire content of HTTP requests:
- Full URLs (including
?query=parameters). - HTTP headers (cookies, authentication tokens).
- POST request bodies (usernames, passwords, card data).
- Server responses (HTML content, API JSON, files).
What TLS does not hide is the domain you're connecting to (visible in the handshake's SNI field and in DNS queries), nor the server's IP address. Hiding those requires additional layers like DNS over HTTPS (DoH) or a VPN.
Why TLS 1.3 Is the Standard You Should Use Today
TLS 1.3, published in 2018, removed a collection of outdated and insecure algorithms that TLS 1.2 carried as legacy baggage (RC4, MD5, SHA-1, static RSA key exchanges). The key improvements are:
- Faster handshake: 1 round trip instead of 2, reducing latency by roughly 100 ms on typical connections.
- Mandatory Perfect Forward Secrecy: even if someone records your traffic today and obtains the server's private key tomorrow, they cannot decrypt past sessions.
- Reduced attack surface: by eliminating weak cipher suites, known attack vectors like BEAST, POODLE, and SWEET32 are gone.
If your server still accepts TLS 1.0 or 1.1, it's time to disable them. You can find step-by-step configuration guides in our SSL security resource center.
Key Takeaways
- SSL is the legacy name; the current protocol is TLS. Use TLS 1.2 at minimum, TLS 1.3 whenever possible.
- TLS combines asymmetric encryption (for the handshake) and symmetric encryption (for the data), achieving both security and speed.
- The handshake verifies the server's identity, exchanges keys, and establishes the encrypted channel before transmitting a single byte of user data.
- TLS 1.3 is faster, eliminates weak algorithms, and enforces Perfect Forward Secrecy — making it the current security standard.
- TLS protects URLs, headers, and request bodies, but does not hide the domain name or server IP from a network observer.
Want to verify your site is running TLS 1.3 with an optimal configuration? The team at elenlace.com conducts SSL security audits and delivers a precise report with the exact settings your server needs — reach out and we'll take a look.
FAQ
Why does my browser show "secure connection" if someone can still see which domain I'm visiting?
"Secure" refers to content encryption and server authentication, not anonymity. TLS guarantees that no one can read or modify the data you exchange with the site. What remains visible to a network observer is the domain (via SNI and DNS), but not the content of your pages, forms, or sessions.
What is Perfect Forward Secrecy and why does it matter?
Perfect Forward Secrecy (PFS) means each TLS session uses ephemeral keys that are discarded when the session ends. If an attacker captures encrypted traffic today and later obtains the server's private key, they still cannot decrypt past sessions because those session keys no longer exist. TLS 1.3 makes PFS mandatory.
Is the TLS handshake always slow?
No. TLS 1.3 reduced it to a single round trip (1-RTT), and with session resumption it can be 0-RTT for repeat connections to the same server. In practice, the impact on page load time is measured in milliseconds — completely imperceptible to the user.
How do I check which TLS version my server is using?
Use an online tool like SSL Labs (ssllabs.com/ssltest) or run openssl s_client -connect yourdomain.com:443 from a terminal. You want to see "TLSv1.3" on the protocol line and a cipher suite beginning with ECDHE to confirm Perfect Forward Secrecy is active.
Prefer it done for you? El Enlace handles hosting and professional web development.
Further reading
Other providers and guides worth comparing:
