TLS and SSL Explained: How Secure Connections Actually Work

The padlock in your browser relies on a protocol called TLS. Despite the industry habit of calling certificates "SSL certificates," SSL itself has been dead for a decade. Here is what actually happens when a secure connection is established, and how to inspect it yourself.

Why SSL Is Dead and TLS Took Over

SSL (Secure Sockets Layer) was Netscape's 1990s protocol for encrypted web connections. SSL 2.0 was banned by RFC 6176 (2011) due to cryptographic flaws. SSL 3.0 fell to the POODLE attack and was deprecated in 2015. No modern browser or server accepts SSL. What we call an "SSL certificate" today is actually an X.509 certificate used with TLS (Transport Layer Security), the protocol that replaced SSL. TLS 1.3 (RFC 8446, 2018) is the current standard: it cuts the handshake to one round trip, strips out every legacy cipher, and makes forward secrecy mandatory. TLS 1.2 is still encountered in the wild but should be phased out of new deployments.

The TLS Handshake, Step by Step

Before any application data flows, client and server run a handshake to agree on parameters and derive shared session keys. TLS 1.3 completes this in a single round trip:

1. ClientHello. The client sends its supported TLS versions, accepted cipher suites, a random nonce, and a key_share containing its half of an ephemeral Diffie-Hellman exchange. The SNI extension names the target hostname so one server can host multiple certificates.
2. ServerHello. The server picks a cipher suite, sends its own nonce and key_share. Both sides can now derive handshake traffic keys from the combined DH output. All subsequent messages are encrypted.
3. EncryptedExtensions. Additional negotiated parameters (ALPN protocol, etc.) sent under encryption.
4. Certificate. The server's X.509 certificate chain, encrypted. The client checks the digital signature, expiry, and CA trust.
5. CertificateVerify. The server signs a hash of the whole handshake transcript with its private key, proving it actually owns the certificate.
6. Finished (server then client). Both sides exchange a MAC over the full handshake. On completion, application traffic keys are derived and encrypted data can flow.

Certificates and the Chain of Trust

An X.509 certificate binds a public key to an identity (domain or organisation), with a validity period and a digital signature from the issuing Certificate Authority (CA). Real deployments use a three-level chain: your server's end-entity certificate is signed by an intermediate CA, which is signed by a root CA. Root CA certificates ship pre-installed in operating systems and browsers as trusted anchors. This design keeps root CAs offline and insulated; if an intermediate CA is compromised, it can be revoked without touching the root trust relationships.

Cipher Suites

A cipher suite names the algorithms for each role in the connection. A TLS 1.3 suite like TLS_AES_256_GCM_SHA384 encodes the bulk cipher (AES-256-GCM) and the hash used in key derivation (SHA-384). Key exchange is omitted from the name because ECDHE is the only option in TLS 1.3. TLS 1.2 suites are more verbose: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 spells out key exchange, authentication, cipher, and MAC separately. The hash functions involved are the same primitives covered in our hashing explained article.

Forward Secrecy

Forward secrecy guarantees that recording today's ciphertext and stealing the server's private key later cannot decrypt those past sessions. It works because TLS uses ephemeral Diffie-Hellman keys (ECDHE): a fresh key pair is generated for each handshake and discarded immediately after. The long-term private key only proves identity via the certificate signature; it never touches the session traffic keys. TLS 1.3 mandates ECDHE, so forward secrecy is automatic. On TLS 1.2 you must explicitly disable RSA key exchange cipher suites to achieve it.

HSTS: Locking Browsers to HTTPS

The Strict-Transport-Security header tells browsers to refuse any HTTP connection to a domain for the stated duration:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Once received, the browser will upgrade all requests to HTTPS internally for one year, preventing SSL-stripping attacks. The preload directive lets you submit the domain to the browser-bundled HSTS preload list, enforcing HTTPS even before the header has ever been seen.

Inspecting a Live Connection with openssl

Use openssl s_client to see exactly what a server negotiates: protocol version, cipher suite, and full certificate chain.

# Full handshake dump
openssl s_client -connect example.com:443 -servername example.com

# Certificate details only (validity, issuer, Subject Alt Names)
openssl s_client -connect example.com:443 -servername example.com \
  < /dev/null 2>/dev/null | openssl x509 -noout -text

# Force TLS 1.3 to confirm server support
openssl s_client -connect example.com:443 -tls1_3

Look for Protocol : TLSv1.3 and a cipher from the approved list. A mismatch or a downgrade to TLS 1.2 tells you the server still offers legacy options. For the transport layer that TLS rides on top of, see our guide to TCP/IP basics for developers.