Can SSL/TLS Be Used Interchangeably?

Man, it totally confused me! Let’s dig into this and check out the world of HTTPS communication.

SSL (Secure Sockets Layer) — an encryption-based internet security protocol. In simple terms, it defines a way to encrypt data at the source (client) and decrypt it at the destination (server). It’s the predecessor to modern TLS.

To provide high security, data is encrypted at the source before being sent through the network — to avoid “Man in the Middle” attacks. But then, how do the server and client agree on which algorithm to use and what the secret key should be? If those keys are passed in plain text, someone can use them to decrypt the content and tamper with the whole communication.

To achieve encryption at source without sharing secrets in plain text, it employs an authentication method called the handshake.

The TLS Handshake

Here’s how a TLS handshake takes place between a client and a server (assuming some familiarity with public/private key encryption):

1. Client Hello — the client initiates the handshake by sending a message to the server containing: the TLS version it supports, the cipher suites supported, and a string of random bytes (“client random”)

2. Server Hello — the server replies with: its SSL certificate, the chosen cipher suite, and a “server random” — another random string of bytes generated by the server

3. Authentication — the client verifies the server’s SSL certificate with the certificate authority that issued it, confirming the server is who it claims to be

4. Premaster Secret — the client sends one more random string of bytes, encrypted with the server’s public key (obtained from the SSL certificate) — only the server can decrypt this with its private key

5. Private Key Used — the server decrypts the premaster secret

6. Session Keys Created — both client and server independently generate session keys from the client random, server random, and premaster secret — they arrive at the same result

7. Client Ready — the client sends a “finished” message encrypted with the session key

8. Server Ready — the server sends a “finished” message encrypted with the session key

9. Secure symmetric encryption achieved — the handshake is complete, and all further communication uses the session keys

Note: the TLS handshake happens after a TCP connection is established.

Let’s See It in Action

Case 1: HTTP

A few things to note:

• The first step is DNS resolution
• The default protocol for curl is HTTP — so port 80 is used
• A HTTP GET is fired via HTTP 1.1
• The TCP connection that was established is kept alive for a while to be reused

Case 2: HTTPS

A few things to note:

• DNS resolution happens first, same as plain HTTP
• Since https is specified, the client reaches out to port 443 for the resolved IP
• Before any HTTP GET is fired, the TLS handshake takes place:
  • Client specifies the protocols it supports
  • Client sends a “Client Hello”
  • Server sends back “Server Hello” with certificate, protocol, and TLS version info
  • Both sides end with a “Finished” message signaling a secret session key has been established
• Only then does the actual HTTP GET happen over the secured channel

So, Can SSL and TLS Be Used Interchangeably?

No. They are different protocols. SSL is the older protocol and TLS is the modern successor, addressing several security issues found in SSL. While people often say “SSL” colloquially when they mean TLS, they are technically distinct — and all modern systems use TLS.