TLS Handshake and Versions

TLS and SSL solve the same problem: securing data sent between two systems over a network. TLS is simply the modern, renamed continuation of SSL.

SSL 2.0 -> SSL 3.0 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3
(all SSL versions and TLS 1.0/1.1 are now considered insecure and disabled by modern browsers)

SSL was renamed to TLS in 1999, when the protocol moved under the standards body IETF. Since then, every new version has been released as "TLS," not "SSL."

Why the SSL name still shows up everywhere:

• The term "SSL certificate" stuck around as a common phrase, even though the certificate is really used for TLS connections today.
• Tools and settings, like ssl_certificate in nginx config files, kept their old SSL-era naming for backward compatibility.

In practice, no modern browser or server actually uses real SSL anymore — it is disabled everywhere because of known security flaws. When someone says "SSL" today, they almost always mean TLS.

Visiting https://example.com involves several layers working together, in order:

1. DNS lookup        Browser asks: "what is the IP address for example.com?"
                      |
                      v
2. TCP connection     Browser opens a TCP connection to that IP, usually on port 443
                      |
                      v
3. TLS handshake      Browser and server agree on TLS version, cipher suite,
                      verify the server's certificate, and derive a shared key
                      |
                      v
4. HTTP over TLS      Browser sends the HTTP request, encrypted
                      Server sends the HTTP response, encrypted
                      |
                      v
5. Page rendering     Browser decrypts the response and renders the page

Step by step:

1. DNS resolution — the domain name is turned into a server IP address.
2. TCP handshake — a reliable connection is set up between browser and server (the standard TCP SYN / SYN-ACK / ACK exchange).
3. TLS handshake — covered in detail in the next question. This is where encryption gets set up and the server's certificate gets checked.
4. Encrypted HTTP exchange — once the handshake finishes, every request and response is encrypted using the shared key from the handshake.
5. Rendering — the browser decrypts the response and displays the page.

All of this typically happens in well under a second. Modern TLS (version 1.3) is designed specifically to keep step 3 as fast as possible, since it adds a full round trip of network latency before any real data can be sent.

TLS 1.3's biggest design goal was cutting the handshake down to one round trip (1-RTT). It does this by having the client guess which key-exchange method the server will pick, and sending its part of the key exchange immediately, instead of waiting to be told what to use.

Client                                                    Server

ClientHello
+ key_share (client's guessed ECDHE public value)
+ supported cipher suites, TLS version
   ------------------------------------------------->

                                          ServerHello
                                          + key_share (server's ECDHE public value)
                                          {EncryptedExtensions}
                                          {Certificate}
                                          {CertificateVerify}   <- signature proving
                                                                    server owns the
                                                                    certificate's key
                                          {Finished}
   <-------------------------------------------------

{Finished}
Application Data (encrypted)
   ------------------------------------------------->
                                          Application Data (encrypted)
   <-------------------------------------------------

Step by step:

1. ClientHello — the client sends its supported TLS versions, cipher suites, and, critically, an ECDHE key share for the group it expects the server to pick.
2. ServerHello — the server picks a cipher suite and TLS version, and sends back its own ECDHE key share.
3. At this point, both sides can independently compute the same shared secret from the two ECDHE key shares. Everything from here on is encrypted.
4. Certificate + CertificateVerify — the server sends its certificate, plus a signature proving it holds the certificate's private key.
5. Finished — both sides send a Finished message, a hash over the whole handshake, to confirm nothing was tampered with.
6. Application data — the client can start sending encrypted HTTP requests right after step 1-2, without waiting for the server's certificate to be verified, because it already has a shared secret.

The result: encrypted application data can begin after just one round trip, instead of the two round trips TLS 1.2 needed. The next question compares this directly against the older TLS 1.2 flow.

The core difference is timing: in TLS 1.2, the client had to wait to hear from the server before it could send its half of the key exchange.

Client                                                    Server

ClientHello
+ supported cipher suites, TLS version
   ------------------------------------------------->

                                          ServerHello (picks cipher suite)
                                          Certificate
                                          ServerKeyExchange (server's key share)
                                          ServerHelloDone
   <-------------------------------------------------

ClientKeyExchange (client's key share)
ChangeCipherSpec
Finished
   ------------------------------------------------->

                                          ChangeCipherSpec
                                          Finished
   <-------------------------------------------------

Application Data (encrypted)
   ------------------------------------------------->

Why TLS 1.2 needed the extra round trip: the client's ClientHello only listed cipher suites it supported. It did not commit to one yet. The client had to wait for the server's ServerHello to find out which cipher suite the server actually chose, before it could generate and send a matching key share. That "wait, then respond" pattern costs a full extra round trip.

TLS 1.3 removes this wait: the client sends a guessed key share immediately, in the very first message, based on the key-exchange groups it expects most servers to support. If the guess is right (which it almost always is), no extra round trip is needed.

Besides the extra round trip, TLS 1.2 also permitted several things TLS 1.3 dropped entirely: RSA key exchange without forward secrecy, older weak ciphers, and compression (linked to security issues like the CRIME attack). The next question lists these improvements directly.

The two headline wins are speed and security:

• Speed — fewer round trips means a faster "time to first encrypted byte," which matters a lot on slow or high-latency mobile connections.
• Security — TLS 1.3 removed an entire category of weak, legacy options. Instead of letting a server choose a secure cipher suite from a long list that also includes insecure ones, TLS 1.3 only offers secure choices in the first place.
• One trade-off — TLS 1.3's certificate is encrypted, which is good for privacy, but it meant some older network security appliances needed updates to keep inspecting traffic.