TLS & HTTPS

What TLS Provides

Transport Layer Security (TLS) is a cryptographic protocol that sits between the transport layer (TCP) and the application layer (HTTP). HTTPS is simply HTTP running over a TLS-secured connection. TLS delivers three fundamental guarantees:

The TLS 1.2 Handshake

TLS 1.2 requires two round-trips (2-RTT) before encrypted application data can flow. Here is the full message exchange:

Step by Step

ClientHello: The client sends supported TLS versions, a random nonce, a list of cipher suites, and extensions (including SNI -- the hostname it wants to reach).

ServerHello: The server selects a TLS version and cipher suite, sends its own random nonce, and attaches its certificate chain.

ServerKeyExchange: When using ECDHE, the server sends its ephemeral public key, signed with its private key for authentication.

ClientKeyExchange: The client sends its ephemeral public key. Both sides now independently compute the same pre-master secret via the Diffie-Hellman algorithm.

Finished: Both sides derive session keys from the pre-master secret and the two random nonces, then send a Finished message encrypted with the new keys to verify the handshake was not tampered with.

TLS 1.3 Improvements

TLS 1.3 (RFC 8446, finalized 2018) is a major overhaul that reduces latency, removes insecure options, and simplifies the protocol.

0-RTT Resumption

If a client has connected to a server before, TLS 1.3 allows it to send encrypted application data in the very first flight (0-RTT) using a pre-shared key (PSK) from the previous session. This eliminates the handshake latency entirely for repeat connections.

Certificate Chain & X.509

Trust on the web is bootstrapped through a hierarchy of Certificate Authorities (CAs). A server does not just send its own certificate -- it sends a chain that lets the client trace trust back to a pre-installed root.

X.509 Certificate Fields

Certificates follow the X.509 v3 standard. Key fields include:

Certificate Signing Request (CSR)

To get a certificate, the server operator generates a key pair, creates a CSR containing the public key and identity info, and sends it to a CA. The CA verifies domain ownership (for DV certs) or organization identity (for OV/EV certs), then signs the certificate with its private key.

Certificate Validation

When a TLS client receives a certificate, it performs several checks before trusting it:

Revocation Checking

Sometimes certificates need to be revoked before expiry (e.g., private key compromise). There are several mechanisms for this:

Certificate Transparency (CT)

CT logs are append-only public ledgers where CAs must log every certificate they issue. This allows domain owners and the community to detect mis-issued certificates. Browsers like Chrome require certificates to include Signed Certificate Timestamps (SCTs) proving they were logged.

Cipher Suites, PFS, SNI, and mTLS

Cipher Suite Anatomy

A cipher suite specifies four algorithms. In TLS 1.2 notation, a suite like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 breaks down as:

In TLS 1.3, key exchange is negotiated separately (always ECDHE), so suites are simpler: TLS_AES_128_GCM_SHA256 or TLS_CHACHA20_POLY1305_SHA256.

Perfect Forward Secrecy (PFS)

PFS means that session keys are not derived from the server's long-term private key. Instead, both sides generate ephemeral Diffie-Hellman keys for each session. Even if the server's private key is stolen later, past recorded traffic cannot be decrypted because the ephemeral keys were discarded after the session ended.

Server Name Indication (SNI)

SNI is a TLS extension where the client includes the requested hostname in the ClientHello (in plaintext). This allows a single IP address to host multiple HTTPS domains, each with its own certificate. Without SNI, the server would not know which certificate to present before the connection is encrypted.

Mutual TLS (mTLS)

In standard TLS, only the server authenticates. In mTLS, the server also requests a certificate from the client during the handshake (CertificateRequest message). The client sends its certificate and proves possession of the private key. This is commonly used in service-to-service communication, zero-trust networks, and API authentication.

Let's Encrypt & ACME

Let's Encrypt is a free, automated CA that has issued billions of certificates. It uses the ACME (Automatic Certificate Management Environment) protocol, where the client proves domain control via an HTTP-01 or DNS-01 challenge, and the CA automatically issues a 90-day DV certificate. Tools like certbot handle the entire lifecycle -- issuance, installation, and renewal.

# Obtain a certificate with certbot
sudo certbot certonly --webroot -w /var/www/html -d example.com

# Auto-renewal (typically via cron or systemd timer)
sudo certbot renew --quiet