SSL/TLS: The Protocol Behind Secure Connections

From SSL to TLS

SSL was created by Netscape in the mid-1990s to address a specific problem: HTTP traffic crossed the network as plain text. Anyone positioned between a browser and a server could read every request without any special equipment. SSL wrapped that traffic in encryption. The first public version shipped in 1995.

The Internet Engineering Task Force took over development and released TLS 1.0 in 1999. The name changed but the protocol was close enough to SSL 3.0 that the two names are still used interchangeably in casual conversation. The underlying differences between SSL and modern TLS are substantial. Two decades of cryptographic research produced a completely different algorithm set, a redesigned handshake and a much smaller attack surface. SSL 2.0 is now banned by RFC. SSL 3.0 is prohibited. TLS 1.0 and 1.1 were retired by every major browser in 2020.

What TLS actually guarantees

TLS provides three distinct security properties at once. Each one addresses a separate category of threat. Understanding which threat each property counters makes it easier to reason about what TLS protects against and what falls outside its scope entirely.

Two kinds of encryption

TLS uses asymmetric cryptography during the handshake and symmetric cryptography for the actual data. Each serves a different purpose. The distinction explains why the handshake exists at all rather than just encrypting everything with a single key from the start.

Asymmetric cryptography is computationally expensive. Using it to encrypt every byte of a file download would be painfully slow. TLS uses it for a narrow purpose: establishing a shared secret that neither side ever sends across the wire. Both sides independently derive the same symmetric session key from that shared secret. All subsequent data travels under AES with that key.

Modern TLS uses Elliptic Curve Diffie-Hellman for the key exchange rather than RSA directly. ECDH achieves the same result with much shorter keys. The ephemeral variant, ECDHE, generates a fresh key pair for every session. A future compromise of the server's long-term private key cannot be used to decrypt past traffic. This property is called forward secrecy.

The TLS 1.3 handshake

TLS 1.3 reduced the handshake to a single round trip. In TLS 1.2, the client had to wait for the server to announce its supported algorithms before it could send key material. TLS 1.3 collapses that exchange by having the client include key shares upfront for the algorithms it expects the server to pick.

The full handshake completes in one round trip. Compared to TLS 1.2 which required two, this is a measurable improvement on any connection with noticeable latency. TLS 1.3 also supports 0-RTT resumption for returning connections, where the client can send application data before the handshake completes. This comes with replay attack trade-offs that make it unsuitable for requests with side effects.

Reading a cipher suite

A cipher suite is a named combination of algorithms that TLS uses for a session. The name reads like a formula. Each field identifies one component of the cryptographic system. Most developers never need to configure cipher suites directly, but knowing what each part means is useful when reading server configuration documentation.

TLS 1.3 cipher suites are shorter because authentication was separated from the cipher suite definition entirely. A TLS 1.3 suite looks like TLS_AES_256_GCM_SHA384. There is no key exchange field and no authentication field. Both are determined by other parts of the handshake. The suite only describes the bulk cipher and the hash function.

The certificate chain

TLS authentication depends on certificates. A certificate binds a public key to a domain name and carries a digital signature from a Certificate Authority. The client verifies that signature using the CA's public key, which comes pre-installed in its trust store.

Most production certificates are not signed directly by a root CA. They are signed by an intermediate CA, which is itself signed by the root. This creates a chain. The server presents its certificate along with any intermediates needed to build the path back to a trusted root. If any link is missing the validation fails.

Root CA certificates are distributed with operating systems and browsers. They are rotated rarely because replacing a trusted root across all devices takes years. Intermediate CAs carry the operational load instead. If an intermediate is compromised, it can be revoked without touching the root. The intermediate takes the hit.

Inspecting TLS from the command line

The openssl command line tool can open a TLS connection to any server and print the certificate it presents along with which protocol version and cipher suite were negotiated. It is useful when debugging certificate issues in environments where you cannot open a browser.

The depth numbers show the chain. Depth 2 is the root CA. Depth 1 is an intermediate. Depth 0 is the server's own certificate. The SSL-Session block shows what was actually negotiated. If the server is presenting the wrong certificate, refusing connections on a particular TLS version or returning an incomplete chain, this output will show it.

This is faster than opening a browser and clicking through the certificate details. It works on any host you can reach over TCP, including internal services behind a VPN where no browser is in the path.

Common failure points

TLS errors tend to surface as a browser warning without much explanation of what actually went wrong. Most of them trace back to one of a small set of causes, each of which points to a specific part of the certificate lifecycle.