How HTTPS Actually Works

Every time you see that padlock icon, a complex cryptographic handshake takes place. Here is what actually happens when your browser connects securely.

The Padlock

You have seen it thousands of times: the small padlock icon in your browser's address bar. It means your connection is secure, encrypted, protected from eavesdroppers. But what does that actually mean? What happens in the fraction of a second between typing a URL and seeing that padlock appear?

The answer involves public-key cryptography, symmetric encryption, digital certificates, certificate authorities, and a carefully choreographed protocol called TLS. Understanding how these pieces fit together is essential for anyone who builds, maintains, or simply uses the web.

HTTP: The Insecure Baseline

HTTP, the Hypertext Transfer Protocol, is the foundation of data communication on the web. When you request a web page over plain HTTP, your browser sends a request in cleartext, and the server responds in cleartext. Anyone positioned between you and the server, your ISP, a Wi-Fi eavesdropper, a government agency, can read every byte of that communication. They can see which pages you visit, what you type into forms, and what the server sends back.

HTTPS is HTTP with a security layer. Originally, that layer was SSL (Secure Sockets Layer). Today, it is TLS (Transport Layer Security), the successor to SSL. Despite the name change, people still casually refer to "SSL certificates" and "SSL connections," which can be confusing. In practice, modern HTTPS uses TLS 1.2 or TLS 1.3.

The TLS Handshake

When your browser connects to an HTTPS server, the first thing that happens is the TLS handshake. This is a multi-step process that establishes a secure channel before any application data is exchanged.

In TLS 1.3, the handshake works roughly like this:

Step 1: Client Hello. Your browser sends a message to the server that includes the TLS version it supports, a list of cipher suites it can use, and a set of key shares (public keys for key exchange).

Step 2: Server Hello. The server picks a cipher suite, selects a key share, and sends its own public key along with its digital certificate. It also sends encrypted extensions and a "Finished" message, all in a single round trip.

Step 3: Client Finished. The browser verifies the server's certificate (more on this below), computes the shared secret, and sends its own "Finished" message. From this point on, all data is encrypted.

TLS 1.3 reduced the handshake to a single round trip, down from two in TLS 1.2. This matters for performance: every round trip adds latency equal to the time it takes a packet to travel between the client and server and back.

Key Exchange: The Clever Part

The core challenge of encrypted communication is the key exchange problem. You and the server need to agree on a shared secret key for encryption, but you are communicating over an insecure channel. Anyone listening can see everything you send. How do you agree on a secret without an eavesdropper learning it?

The answer is Diffie-Hellman key exchange (or its elliptic-curve variant, ECDHE). The math works like this, conceptually: both sides generate a private key and a corresponding public key. They exchange public keys openly. Each side then combines their own private key with the other's public key to derive the same shared secret. An eavesdropper who sees both public keys cannot derive the shared secret without one of the private keys.

This shared secret is then used to derive symmetric encryption keys for the session.

Symmetric vs. Asymmetric Encryption

You might wonder why the handshake uses public-key (asymmetric) cryptography if the actual data transfer uses symmetric encryption. The reason is performance. Asymmetric operations (like RSA or elliptic-curve math) are computationally expensive, orders of magnitude slower than symmetric operations (like AES). The handshake uses asymmetric cryptography once to establish a shared secret, then switches to fast symmetric encryption for the rest of the session.

The symmetric cipher used in modern TLS is typically AES-GCM or ChaCha20-Poly1305. These are authenticated encryption algorithms, meaning they provide both confidentiality (nobody can read the data) and integrity (nobody can tamper with the data without detection).

Certificates and Trust

Encryption alone is not enough. If you establish an encrypted connection to a server, but you cannot verify that the server is who it claims to be, an attacker could intercept your connection, present their own certificate, and relay traffic between you and the real server. This is a man-in-the-middle attack.

Digital certificates solve this. A certificate is a document that binds a public key to a domain name (like example.com). It is signed by a Certificate Authority (CA), a trusted third party that has verified the certificate holder's identity. Your browser comes pre-installed with a list of trusted root CAs, typically around 100-150 of them.

When the server sends its certificate during the TLS handshake, your browser checks several things: Is the certificate valid (not expired, not revoked)? Does the domain name match? Is it signed by a CA that the browser trusts? This chain of trust can be multiple levels deep: the server's certificate might be signed by an intermediate CA, which is in turn signed by a root CA that your browser trusts.

If any of these checks fail, you see a warning page. The connection might still be encrypted, but it is not authenticated, and the browser rightly treats it as insecure.

Certificate Transparency

The CA system has a known weakness: if a CA is compromised or coerced, it can issue fraudulent certificates. This has happened. In 2011, the Dutch CA DigiNotar was compromised, and fraudulent certificates for Google and other domains were issued.

Certificate Transparency (CT) addresses this by requiring CAs to log every certificate they issue to public, append-only logs. Anyone can monitor these logs to detect misissued certificates. Browsers now require CT compliance for certificates to be trusted.

Perfect Forward Secrecy

Modern TLS configurations use ephemeral key exchange, meaning a new key pair is generated for every session. Even if an attacker later obtains the server's long-term private key, they cannot decrypt past sessions because those sessions used ephemeral keys that no longer exist. This property is called perfect forward secrecy (PFS).

Before PFS became standard, TLS connections often used the server's RSA key directly for key exchange. An attacker who recorded encrypted traffic and later stole the server's private key could decrypt all of it retroactively. PFS eliminates this risk.

What HTTPS Does Not Do

HTTPS protects data in transit between your browser and the server. It does not protect data at rest on the server. It does not verify that the server's software is secure or that the site is trustworthy. A phishing site can have a valid HTTPS certificate. HTTPS also does not hide which domain you are connecting to: the Server Name Indication (SNI) extension sends the hostname in cleartext during the handshake, though encrypted SNI is an active area of development.

Common TLS Attacks and Defenses

The history of TLS is a history of attacks and patches. Understanding common attacks illuminates why the protocol evolved as it did:

BEAST (2011): Exploited a vulnerability in TLS 1.0's CBC (Cipher Block Chaining) mode by predicting the initialization vector of the next block. The fix was to use TLS 1.1+ (which randomizes the IV) or to use RC4 instead of CBC. RC4 was later found to have its own vulnerabilities, leading to its deprecation.

Heartbleed (2014): A buffer over-read vulnerability in OpenSSL's implementation of the TLS heartbeat extension. An attacker could read up to 64 KB of server memory per request, potentially extracting private keys, session cookies, and user data. The bug was in the implementation, not the protocol, but it demonstrated that TLS security depends on correct implementation as much as correct protocol design.

POODLE (2014): Exploited a vulnerability in SSL 3.0 by forcing browsers to downgrade from TLS to SSL 3.0, then exploiting SSL 3.0's padding. The fix was to disable SSL 3.0 entirely, which most browsers and servers did within months.

FREAK and Logjam (2015): Exploited legacy "export-grade" cryptography that had been mandated by US government regulations in the 1990s. These regulations required that software exported from the US use weak encryption (512-bit RSA for FREAK, 512-bit Diffie-Hellman for Logjam). Even though the regulations were lifted in 2000, the weak cipher suites remained in TLS implementations for backward compatibility. The attacks could force a connection to use these weak ciphers, then break the encryption in real time.

These attacks drove the development of TLS 1.3 (2018), which removed support for older cipher suites, simplified the handshake, and eliminated many of the protocol options that had been the source of vulnerabilities. TLS 1.3 is not just faster than its predecessors; it is more secure because it offers fewer configuration options and therefore fewer opportunities for misconfiguration.

How HTTPS Affects Performance

Early HTTPS implementations imposed a measurable performance penalty: the TLS handshake added 1-2 round trips of latency, and encryption/decryption consumed CPU cycles. These costs were significant enough that many websites used HTTPS only for login pages and payment forms, serving all other content over unencrypted HTTP.

Modern implementations have largely eliminated this penalty. TLS 1.3 reduced the handshake to a single round trip (and zero round trips for resumed sessions using 0-RTT). Hardware AES-NI instructions on modern CPUs make encryption and decryption nearly free. HTTP/2, which requires HTTPS in practice (all major browsers only support HTTP/2 over TLS), actually improves performance through multiplexing and header compression. The net result is that HTTPS is often faster than HTTP 1.1 in practice.

CDNs (Content Delivery Networks) handle TLS termination at edge servers geographically close to the user, further reducing the latency impact. When you connect to a website served by Cloudflare or Fastly, the TLS handshake happens with a server in your city, not with the origin server that might be on another continent. The encrypted connection between the CDN and the origin server is persistent, eliminating the handshake overhead for subsequent requests.

Key Takeaways

Common TLS Attacks and Defenses

The history of TLS is a history of attacks and patches. Understanding common attacks illuminates why the protocol evolved as it did.

BEAST (2011): Exploited a vulnerability in TLS 1.0's CBC (Cipher Block Chaining) mode by predicting the initialization vector of the next block. The fix was to use TLS 1.1+ or to use RC4 instead. RC4 was later found to have its own vulnerabilities, leading to its deprecation.

Heartbleed (2014): A buffer over-read vulnerability in OpenSSL's implementation of the TLS heartbeat extension. An attacker could read up to 64 KB of server memory per request, potentially extracting private keys, session cookies, and user data. The bug was in the implementation, not the protocol, but it demonstrated that TLS security depends on correct implementation as much as correct protocol design.

POODLE (2014): Exploited a vulnerability in SSL 3.0 by forcing browsers to downgrade from TLS to SSL 3.0, then exploiting SSL 3.0's padding. The fix was to disable SSL 3.0 entirely.

FREAK and Logjam (2015): Exploited legacy "export-grade" cryptography that had been mandated by US government regulations in the 1990s. The attacks could force a connection to use weak ciphers, then break the encryption in real time. These attacks drove the development of TLS 1.3, which removed support for all legacy cipher suites.

How HTTPS Affects Performance

Early HTTPS implementations imposed a measurable performance penalty: the TLS handshake added 1-2 round trips of latency, and encryption consumed CPU cycles. These costs were significant enough that many websites used HTTPS only for login pages and payment forms.

Modern implementations have largely eliminated this penalty. TLS 1.3 reduced the handshake to a single round trip (and zero round trips for resumed sessions using 0-RTT). Hardware AES-NI instructions on modern CPUs make encryption and decryption nearly free. HTTP/2, which requires HTTPS in practice (all major browsers only support HTTP/2 over TLS), actually improves performance through multiplexing and header compression. The net result is that HTTPS is often faster than HTTP 1.1 in practice.

CDNs handle TLS termination at edge servers geographically close to the user, further reducing the latency impact. When you connect to a website served by Cloudflare or Fastly, the TLS handshake happens with a server in your city, not with the origin server on another continent.

The Let's Encrypt Revolution

Before Let's Encrypt (launched 2015), TLS certificates cost money (typically $10-100 per year), required manual renewal, and involved a bureaucratic validation process. These costs and friction were the primary reasons many websites did not use HTTPS. Let's Encrypt, sponsored by the Internet Security Research Group (ISRG) with backing from Mozilla, Cisco, Akamai, and the EFF, provides free certificates with automated issuance and renewal. The ACME (Automatic Certificate Management Environment) protocol automates the entire process: a server proves it controls a domain, and Let's Encrypt issues a certificate, typically in under a minute.

Let's Encrypt has issued over 3 billion certificates since its launch. The percentage of web traffic using HTTPS has grown from approximately 40% in 2015 to over 90% in 2024. The encryption of the web, once considered a distant goal, has been largely achieved through a combination of free certificates, browser pressure (Chrome marking HTTP sites as "Not Secure"), and SEO incentives (Google uses HTTPS as a ranking signal).

Key Takeaways

The Push to Encrypt Everything

In 2014, only about 30% of web traffic was encrypted. Today, that figure is over 95%. This shift was driven by several factors: Google began using HTTPS as a ranking signal, browsers started marking HTTP sites as "Not Secure," and Let's Encrypt launched in 2015, providing free, automated TLS certificates to anyone.

The result is a web where encryption is the default, not the exception. The padlock in your address bar represents a remarkable amount of cryptographic engineering, all happening in milliseconds, every time you load a page.