How Does HTTPS Encryption Work Between Your Browser and Server?

Scott Helme's June 2026 crawl of the Tranco top 1 million sites found 576,464 sites negotiating TLS 1.3 and only 70,395 still on TLS 1.2. TLS 1.1 is extinct. TLS 1.0 clings to 106 sites. The protocol that powers HTTPS encryption has effectively consolidated around a single version, and that version does something fundamentally different from its predecessors.

HTTPS is HTTP wrapped in TLS. The browser and server run a handshake using asymmetric cryptography to agree on a shared symmetric key, then they switch to that symmetric key for the actual data. TLS 1.3, defined in RFC 8446, removed static RSA key exchange and made forward secrecy mandatory. It also dropped CBC-mode cipher suites entirely, leaving only AEAD constructions like AES-GCM and ChaCha20-Poly1305.

w3techs reported in August 2026 that roughly 90% of websites now default to HTTPS. The padlock is no longer a differentiator. It is baseline infrastructure.

You can look up exactly which cipher suite a site negotiates using the TLS cipher suite lookup tool.

HTTPS is not a separate protocol. It is HTTP sent over a TLS connection, which is itself sent over a TCP connection. The URL scheme https:// tells the browser to establish TLS before sending any HTTP request. Without TLS, the HTTP request and response travel in plaintext, and anyone on the network path can read them.

The history matters because it explains why the naming is confusing. Netscape shipped SSL 2.0 in 1994 as part of Netscape Navigator, according to Eric Rescorla's account in "SSL and TLS: Designing and Building Secure Systems" (Addison-Wesley, 2001). SSL 2.0 had serious flaws, including MAC-then-encrypt ordering issues and no protection against man-in-the-middle downgrade attacks. SSL 3.0 followed in 1995 and fixed some of these problems.

The IETF took over the protocol and published TLS 1.0 as RFC 2246 in January 1999. The name changed from SSL to TLS, but the structure was the same: a handshake phase to negotiate keys, followed by a record layer that encrypts application data. TLS 1.0 through 1.2 iterated on this design. TLS 1.3, published as RFC 8446 in August 2018, was a more aggressive revision. It threw out static RSA key exchange and CBC-mode cipher suites. It also removed compression and reduced the handshake from two round trips to one.

NIST SP 800-52 Revision 2, published in August 2019, provides federal guidance on TLS configuration. It requires TLS 1.2 support at minimum and mandates TLS 1.3 support by January 1, 2024. The full document is available at NIST SP 800-52 Rev. 2. Internet Society Pulse reports that 96% of the top 1000 sites support HTTPS and 88% support TLS 1.3, as of 2026.

The TLS 1.3 handshake is shorter than its predecessors. Here is what happens when your browser connects to an HTTPS server.

The client sends a ClientHello message. This message includes the TLS versions the client supports and a list of cipher suites. It also includes a key share for ephemeral Diffie-Hellman (typically X25519 or P-256). The client sends the Server Name Indication (SNI) in plaintext at this point, which leaks the hostname the client is connecting to.

The server responds with a ServerHello. It picks a TLS version and cipher suite from the client's list, sends its own key share, and includes its certificate. The server also sends a CertificateVerify message, which proves it holds the private key corresponding to the certificate's public key. Both sides now have enough information to compute the shared secret via ephemeral Diffie-Hellman.

From the shared secret, both sides derive traffic keys using HKDF (HMAC-based Key Derivation Function). The server can start sending encrypted data immediately after its first flight. The client sends a Finished message confirming the handshake transcript, and then both sides switch to symmetric encryption for all application data.

The symmetric ciphers used are AEAD (Authenticated Encryption with Associated Data) constructions. TLS 1.3 supports exactly five cipher suites, all AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, and TLS_AES_128_CCM_8_SHA256. There are no CBC-mode options and no RC4. Static RSA key exchange is not supported.

Here is how TLS 1.2 and TLS 1.3 compare on the dimensions that matter:

The forward secrecy point is significant. With static RSA key exchange (TLS 1.2), if an attacker records encrypted traffic today and compromises the server's private key later, they can decrypt all the recorded sessions. With ephemeral Diffie-Hellman (TLS 1.3), the ephemeral keys are destroyed after the session. Compromising the long-term private key does not help decrypt past sessions. Scott Helme's June 2026 crawl found that 96% of TLS 1.3 connections use X25519 for key exchange, which is the modern elliptic curve Diffie-Hellman group.

The server's certificate is what makes the handshake an authentication mechanism, not just a key agreement. The certificate binds a public key to a domain name, and it is signed by a Certificate Authority (CA) that the browser trusts. The certificate format is X.509, defined by ITU-T recommendation X.509. Browsers ship with a root store (such as Mozilla's CA Certificate Store or Apple's root store) that lists the CAs they trust.

The chain of trust works like this: the server presents its leaf certificate, which is signed by an intermediate CA. The intermediate CA's certificate is signed by a root CA. The root CA's certificate is in the browser's root store and is self-signed. The browser verifies each signature up the chain. If any signature is invalid or the certificate has expired, the browser shows a certificate error. The same happens if the domain name on the certificate does not match the requested hostname.

Let's Encrypt, a free automated CA, now issues certificates for 302,116 of the sites in Helme's June 2026 dataset. Google Trust Services accounts for another 203,436. Together, these two automated CAs dominate the ecosystem. The old model of paying for annual certificates is nearly gone.

One remaining leak in HTTPS encryption is the SNI field. The ClientHello sends the target hostname in plaintext so the server knows which certificate to present. This means an observer on the network can see which site you are connecting to, even if they cannot read the content. Encrypted Client Hello (ECH) fixes this by encrypting the SNI using a public key published in the site's DNS records. Helme's June 2026 crawl found approximately 200,000 sites publishing an ECH configuration. ECH is still early in deployment, but it closes the last plaintext metadata leak in the TLS handshake.

HTTPS encrypts the content of HTTP requests and responses. It does not encrypt everything about the connection.

The destination IP address is visible in the TCP/IP headers. An observer can see that you connected to a specific IP address, even with ECH. If that IP address hosts only one domain, the observer knows which site you visited. CDNs mitigate this because thousands of sites share a small number of IP addresses, but the resolution is not perfect.

DNS resolution happens before the TLS connection. Unless you use DNS over HTTPS (DoH) or DNS over TLS (DoT), your DNS queries are plaintext UDP on port 53. Your ISP can see every domain you look up.

The timing and size of requests leak information. Even with encryption, an attacker can observe the size of the response and the timing between requests to infer which page you loaded. Liberatore and Levine demonstrated at ACM CCS 2006 that they could identify which website a user visited by analyzing packet sizes in encrypted HTTP connections, building profiles from 2,000 distinct websites. The paper is available at the ACM Digital Library.

HTTPS encryption also does nothing to protect data after it reaches the server. If the server stores passwords in plaintext or logs request bodies, the encryption in transit did not help. The same applies if the server gets compromised. HTTPS is transport security, not storage security.

When something goes wrong with HTTPS, the symptoms are usually a browser warning or a connection failure. Here is how to diagnose the common ones.

In Chrome or Firefox, open DevTools, go to the Security tab, and click on the connection. The browser shows the TLS version, the cipher suite, the certificate chain, and any issues. If the certificate is expired, the browser will tell you the expiration date. If the chain is incomplete (the server did not send the intermediate certificate), the browser will show a chain error.

For a deeper look, use OpenSSL from the command line:

``bash openssl s_client -connect example.com:443 -servername example.com ``

This prints the negotiated TLS version, cipher suite, server certificate, and the full handshake messages. If you want to see the cipher suites the server offers in order of preference, add the -tls1_3 flag to force TLS 1.3.

JWTs (JSON Web Tokens) are a common case where developers assume HTTPS is sufficient. A JWT sent over HTTPS is protected in transit, but the JWT itself is typically base64url-encoded, not encrypted. Anyone who can read the JWT (from browser local storage or a log file) can read its claims. You can inspect the contents of a JWT using the JWT decoder tool to see exactly what is inside one.

The TLS 1.3 handshake transcript is hashed with SHA-256 (or SHA-384, depending on the cipher suite). This hash binds the handshake to the negotiated parameters and prevents downgrade attacks. If you want to generate a SHA-256 hash manually, the SHA-256 hash generator does this for arbitrary input.

HTTPS encryption is TLS encryption, and TLS 1.3 is now the dominant version. The handshake uses ephemeral Diffie-Hellman to agree on a symmetric key, then AEAD ciphers protect the bulk traffic. Forward secrecy is mandatory, and static RSA and CBC mode are both gone. The remaining plaintext leak (SNI) is being closed by ECH, which roughly 200,000 sites already support. To see what your own site negotiates, run it through the TLS cipher suite lookup tool.