SSL works in two phases: a "handshake" where client and server authenticate each other and agree on a shared encryption key, followed by encrypted data exchange using that key. The entire process happens in milliseconds, before a single byte of page content is loaded.
Understanding how SSL works goes beyond satisfying technical curiosity — it helps you make better decisions about server configuration, algorithm selection, and diagnosing connection errors.
The Two Building Blocks: Asymmetric and Symmetric Encryption
Before looking at the handshake, it helps to understand the two types of encryption SSL combines:
Asymmetric Encryption (Public/Private Key)
Uses a mathematically linked key pair: a public key (anyone can know it) and a private key (only the server keeps it secret). What one key encrypts, only the other can decrypt. It is very secure but computationally slow.
Symmetric Encryption (Session Key)
Uses the same key to both encrypt and decrypt. Much faster than asymmetric encryption, but requires both parties to securely share the key before use.
SSL combines both: it uses asymmetric encryption (slow but secure) to exchange a symmetric key (fast), then uses that symmetric key to encrypt all session data.
The TLS Handshake Step by Step
When your browser connects to any https:// address, the following happens in fractions of a second:
Step 1: ClientHello
The browser sends a ClientHello message containing:
- The highest TLS version it supports (e.g., TLS 1.3).
- A list of supported cipher suites (algorithm combinations).
- A random number called the client random.
Step 2: ServerHello + Certificate
The server responds with:
- The chosen TLS version and cipher suite.
- A random number called the server random.
- Its SSL certificate, containing its public key and signed by a trusted Certificate Authority (CA).
Step 3: Certificate Verification
The browser verifies that the certificate:
- Was issued by a trusted CA (in its built-in root list).
- Has not expired or been revoked.
- Matches exactly the domain being connected to.
If any check fails, the browser shows a security warning and stops the connection.
Step 4: Key Exchange
This is where the cryptographic magic happens. Depending on the agreed cipher suite:
- In TLS 1.2: the browser generates a pre-master secret, encrypts it with the server's public key, and sends it. Only the server can decrypt it with its private key.
- In TLS 1.3: the ephemeral Diffie-Hellman (ECDHE) algorithm is used, allowing both parties to derive a shared secret without ever transmitting it directly. This provides forward secrecy: even if someone steals the server's private key in the future, they cannot decrypt past sessions.
Step 5: Session Key Generation
Using the client random, the server random, and the shared secret from the previous step, both parties independently derive the same symmetric session keys. The process is deterministic: given the same inputs, they arrive at the same output — no need to send the keys to each other.
Step 6: Finished — Secure Channel Established
Both parties send a Finished message encrypted with the new session keys, confirming everything went as expected. From this point on, all communication uses symmetric encryption (AES-GCM in modern configurations).
If you want to go deeper on certificate configuration or need help enabling TLS 1.3 on your server, the specialists at elenlace.com can handle it for you.
Modern Algorithms: What to Look for in Your Configuration
Not all algorithms are equally secure. This table summarizes current best practices:
| Function | Recommended | Avoid |
|---|---|---|
| Protocol | TLS 1.3, TLS 1.2 | SSL 3.0, TLS 1.0, TLS 1.1 |
| Key exchange | ECDHE (X25519, P-256) | Static RSA (no forward secrecy) |
| Symmetric cipher | AES-256-GCM, ChaCha20-Poly1305 | RC4, DES, 3DES |
| Hash / signature | SHA-256, SHA-384 | MD5, SHA-1 |
TLS 1.0 and 1.1 were officially deprecated by the IETF in 2021 and are blocked in modern browsers. If your server still supports them, it's time to update.
What Is Forward Secrecy and Why Does It Matter?
Forward secrecy guarantees that even if someone steals the server's private key tomorrow, they cannot decrypt today's sessions. It achieves this by generating ephemeral session keys (discarded when the connection ends) using algorithms like ECDHE.
Without forward secrecy, an attacker who records encrypted traffic today could decrypt it later if they obtain the private key. With forward secrecy, each session is independent — compromising one does not affect the others.
TLS 1.3 mandates cipher suites with forward secrecy, eliminating methods that do not provide it. This is another compelling reason to disable TLS 1.2 or, at minimum, configure it with only ECDHE cipher suites.
Browse more resources on protocols and encryption in our security SSL section.
Key Takeaways
- SSL/TLS uses asymmetric encryption for the handshake and symmetric encryption for session data, combining security with speed.
- The TLS handshake has six steps: ClientHello, ServerHello + certificate, verification, key exchange, session key generation, and Finished.
- TLS 1.3 is today's standard: faster (one round trip instead of two) and more secure (forward secrecy is mandatory).
- Look for ECDHE for key exchange, AES-GCM or ChaCha20 for symmetric encryption, and SHA-256+ for hashing.
- Forward secrecy ensures that future key compromise does not expose past sessions.
Want to make sure your server is configured with the right modern algorithms? Contact us at elenlace.com and we'll audit your TLS configuration at no initial cost.
FAQ
Does the TLS handshake slow down my website?
In TLS 1.3, the full handshake requires only one round trip (1-RTT) and can even complete in zero round trips if the browser recognizes the server (0-RTT). The latency impact is in the range of tens of milliseconds — imperceptible to users. HTTP/2 and HTTP/3 over TLS actually speed up total page load through multiplexing.
Where is the server's private key stored?
On the web server, typically in a protected directory that only the web process user can read (e.g., /etc/ssl/private/ on Linux). The private key must never be transmitted or exposed. If it is compromised, you must revoke the certificate and generate a new one.
What is a Certificate Authority (CA)?
A CA is a trusted entity that verifies a domain owner's (or company's) identity and issues a digitally signed SSL certificate. Browsers include a built-in list of trusted root CAs; if a site's certificate was signed by one of them, the browser accepts it automatically. Examples include Let's Encrypt, DigiCert, and Sectigo.
Can I see the TLS handshake in action?
Yes. In Chrome or Firefox DevTools, open the Security tab to see certificate details and the cipher suite in use. For a full analysis, run openssl s_client -connect yourdomain.com:443 -tls1_3 from the terminal — it prints each phase of the handshake in plain text.
Compare providers
Other providers and guides worth comparing:
