How HTTPS Works: Step by Step for Beginners

When you visit a website over HTTPS, your browser and the web server perform an elaborate sequence of steps to establish a secure connection before any page content is transferred. This process happens in milliseconds and is completely invisible to you, but it involves cryptographic key exchanges, certificate verification, and the negotiation of encryption algorithms.

This guide walks through every step of the HTTPS process, from the moment you type a URL to the point where encrypted data flows between your browser and the server. No cryptography background is needed. For the protocol details and version history, see SSL vs TLS.

The Big Picture

HTTPS is just HTTP (the standard web protocol) wrapped in TLS (Transport Layer Security) encryption. Every HTTP request and response is encrypted before it leaves your device and decrypted when it arrives at the other end. The encryption happens at a layer below HTTP, so HTTP itself does not need to change.

The process has three phases:

1. TCP connection: Your browser establishes a basic network connection to the server.
2. TLS handshake: Your browser and the server negotiate encryption and verify each other's identity.
3. Encrypted data transfer: HTTP requests and responses flow through the encrypted channel.

Step 1: DNS Lookup

Before anything else, your browser needs the server's IP address. When you type https://example.com, the browser asks a DNS resolver to look up the IP address for example.com. The resolver returns something like 93.184.216.34.

This DNS lookup happens over plain, unencrypted DNS by default (though DNS over HTTPS is becoming more common). The DNS lookup itself is not part of HTTPS, but it is the first step in reaching the server.

Step 2: TCP Connection

Your browser opens a TCP (Transmission Control Protocol) connection to the server's IP address on port 443 (the default HTTPS port). TCP is the reliable transport layer that ensures data arrives in order and without loss.

The TCP connection uses a three-way handshake:

1. Your browser sends a SYN (synchronize) packet to the server.
2. The server responds with a SYN-ACK (synchronize-acknowledge).
3. Your browser sends an ACK (acknowledge).

After these three packets, the TCP connection is open and ready for data. This adds one round trip of latency (the time for a packet to travel to the server and back).

Step 3: TLS Handshake Begins (Client Hello)

With the TCP connection established, the TLS handshake starts. Your browser sends a Client Hello message to the server. This message contains:

• Supported TLS versions: Which versions of TLS the browser can use (TLS 1.2, TLS 1.3).
• Supported cipher suites: A list of encryption algorithms the browser supports, in order of preference. Each cipher suite specifies the key exchange algorithm, the encryption algorithm, and the message authentication algorithm.
• A random number: Generated by the browser, used later in key generation.
• Session ID or ticket: If the browser has connected to this server before, it may include a session resumption token to skip some handshake steps.
• Server Name Indication (SNI): The domain name the browser wants to connect to. This is necessary because a single IP address may host multiple HTTPS websites, and the server needs to know which certificate to present.

The Client Hello is sent in plain text. This is necessary because encryption has not been established yet. The SNI extension means the domain name you are connecting to is visible to network observers, even though the subsequent data will be encrypted.

Step 4: Server Hello and Certificate

The server responds with a Server Hello message:

• Selected TLS version: The highest version both sides support.
• Selected cipher suite: The server picks one cipher suite from the browser's list.
• A random number: Generated by the server, used later in key generation.

Immediately after the Server Hello, the server sends its SSL certificate (and any intermediate certificates in the chain). The certificate contains:

• The domain name it was issued for.
• The server's public key.
• The certificate authority (CA) that issued it.
• The validity period.
• A digital signature from the CA.

In TLS 1.3, the certificate is encrypted. In TLS 1.2, it is sent in plain text. This is one of the security improvements in TLS 1.3.

Step 5: Certificate Verification

Your browser now verifies the server's certificate. This is the authentication step that prevents man-in-the-middle attacks.

Chain of Trust Verification

The browser builds a certificate chain from the server's certificate up to a trusted root certificate:

1. The server's certificate was signed by an intermediate CA.
2. The intermediate CA's certificate was signed by a root CA.
3. The root CA's certificate is pre-installed in your browser or operating system's trust store.

The browser verifies each signature in the chain. If any signature is invalid, the certificate is rejected.

Domain Name Check

The browser checks that the domain in the URL matches the domain (or domains) listed in the certificate. The certificate's Common Name (CN) or Subject Alternative Names (SANs) must include the domain being visited. If example.com is in the URL but the certificate is for other-site.com, the browser rejects it.

Validity Period Check

The browser checks that the current date falls within the certificate's validity period (between "Not Before" and "Not After"). Expired certificates are rejected with a warning page.

Revocation Check

The browser checks whether the certificate has been revoked by the CA. This can happen through CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol). If the certificate has been revoked (because it was compromised, for example), the browser rejects it.

For more on these checks, see How to Validate SSL Certificate.

Step 6: Key Exchange

After verifying the certificate, the browser and server need to agree on a shared secret key for encrypting the actual data. This is the key exchange step, and it uses asymmetric (public-key) cryptography to establish a shared symmetric key.

Why Two Types of Encryption?

Asymmetric encryption uses a pair of keys (public and private). Data encrypted with the public key can only be decrypted with the private key. This is secure but computationally expensive.

Symmetric encryption uses a single shared key for both encryption and decryption. It is fast but requires both parties to have the same key without an eavesdropper learning it.

HTTPS uses asymmetric encryption only for the key exchange. Once both sides have the shared symmetric key, all data is encrypted with symmetric encryption for performance.

TLS 1.3 Key Exchange

TLS 1.3 uses Diffie-Hellman key exchange exclusively (specifically, Elliptic Curve Diffie-Hellman Ephemeral, or ECDHE). The process:

1. Both the browser and server generate temporary (ephemeral) key pairs.
2. They exchange their public keys.
3. Each side combines their private key with the other's public key to derive the same shared secret.
4. The shared secret, combined with the random numbers from the Client Hello and Server Hello, produces the session keys.

The "ephemeral" part is important: the temporary keys are discarded after the handshake. Even if an attacker later obtains the server's long-term private key, they cannot decrypt past sessions. This property is called perfect forward secrecy.

TLS 1.2 Key Exchange

TLS 1.2 supports multiple key exchange methods, including RSA and Diffie-Hellman. With RSA key exchange, the browser encrypts a pre-master secret with the server's public key from the certificate. Only the server can decrypt it with the private key. Both sides derive the session keys from this pre-master secret.

RSA key exchange does not provide forward secrecy (if the server's private key is later compromised, all past sessions can be decrypted), which is why TLS 1.3 removed it.

Step 7: Handshake Complete

Both sides now have identical session keys derived from the key exchange. The browser sends a Finished message encrypted with the session key. The server sends its own Finished message. Both sides verify that the other's Finished message decrypts correctly, confirming that the handshake completed without tampering.

The TLS handshake is now complete. From this point on, all communication is encrypted with the session keys using the agreed-upon symmetric cipher (typically AES-GCM in modern configurations).

Handshake Speed

In TLS 1.3, the entire handshake takes one round trip (one Client Hello, one Server Hello with certificate and key share, then done). Combined with the TCP handshake, a new HTTPS connection requires two round trips total before data can flow.

In TLS 1.2, the handshake takes two round trips, making the total three round trips before data flows.

For returning visitors, TLS session resumption can reduce the TLS handshake to zero round trips (0-RTT in TLS 1.3), making HTTPS connections nearly as fast as plain HTTP.

Step 8: Encrypted HTTP Communication

With the encrypted channel established, your browser sends the HTTP request (GET /index.html, for example) through the TLS layer. The request is encrypted, sent over the network, and decrypted by the server.

The server processes the request and sends the HTTP response (the HTML page, CSS, images, etc.) back through the same encrypted channel.

Every piece of data is encrypted: the URL path, headers, cookies, request body, response body, and status codes. A network observer sees only the encrypted bytes and the IP addresses of the two endpoints.

Step 9: Connection Reuse

Modern browsers keep HTTPS connections open for reuse (HTTP keep-alive). Subsequent requests to the same server use the existing encrypted connection without repeating the TLS handshake. This makes page loads with many resources (images, scripts, stylesheets) much faster.

HTTP/2 (which browsers only support over HTTPS) goes further by multiplexing multiple requests over a single connection. Instead of opening a new connection for each resource, all resources from the same server flow through one encrypted channel simultaneously.

What an Observer Sees

If someone is monitoring your network traffic (on public Wi-Fi, at your ISP, or anywhere in between), here is what they can and cannot see during an HTTPS connection:

Visible:

• The IP address of the server you are connecting to.
• The domain name (from the SNI in the Client Hello, unless Encrypted Client Hello is used).
• The approximate amount of data transferred.
• The timing of requests and responses.

Not visible:

• The specific URLs you visit on the site.
• Page content, form data, cookies.
• HTTP headers and status codes.
• Any data you submit or receive.

References

1. RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3," August 2018. https://datatracker.ietf.org/doc/html/rfc8446
2. RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2," August 2008. https://datatracker.ietf.org/doc/html/rfc5246
3. Cloudflare, "What happens in a TLS handshake?" https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
4. Mozilla Wiki, "Security/Server Side TLS," https://wiki.mozilla.org/Security/Server_Side_TLS