The Difference Between HTTP and HTTPS: How TLS Encryption Protects Your Data

When you open a login page, type your password, and click submit, what exactly happens between the browser and the server? On the surface, the process seems simple: the browser sends an HTTP request, and the server returns an HTTP response. The real issue isn't at either end—it's in that invisible network journey between the browser and the server. It's precisely this journey that makes HTTP and HTTPS worlds apart.

This article starts from the underlying network handshake, systematically breaking down HTTP's three fundamental security flaws and how HTTPS addresses them through TLS, helping you build a clear and complete mental model.

How HTTP Works and Its Three Security Flaws

Before the browser sends application data, it typically needs to establish a network connection first. For classic HTTP/1.1 and HTTP/2, this path relies on the TCP three-way handshake (HTTP/3 uses a QUIC-based mechanism instead, which we won't cover here).

TCP (Transmission Control Protocol) is the core protocol at the transport layer of the internet protocol stack, providing connection-oriented, reliable byte-stream transmission. The three-way handshake is designed to prevent confusion caused by duplicate initialization of historical connection requests—if there were only two handshakes, the server couldn't distinguish between a new connection request and a delayed old request arriving from the network.

The three-way handshake works as follows: the client first sends a SYN (Synchronize) request, the server replies with a SYN-ACK acknowledgment, and the client returns an ACK. The SYN flag is used to synchronize sequence numbers between both parties, which will be used in subsequent data transmission to ensure ordered packet delivery and correct retransmission mechanisms. At this point, the TCP connection is established.

For plaintext HTTP, once the connection is established, the browser can immediately send requests. But problems follow—the entire HTTP message is transmitted in plaintext across the network, including the request line, headers, cookies, and request body. If this is a login form, the username and password can be directly read by anyone who can observe the traffic.

In a shared network environment, this could be a malicious Wi-Fi access point, or a proxy or other machine positioned between the client and server. Worse still, if an attacker can tamper with traffic in transit, they can even modify content before the response reaches the browser—such as injecting malicious JavaScript code into a web page, or replacing software download links to point to files containing trojans.

In summary, HTTP provides standardized message formatting but has three fundamental flaws:

• Lack of privacy: Data is transmitted in plaintext, readable by any intermediary;
• No server identity verification: You cannot confirm the other party is the real server;
• No message integrity guarantee: Messages may be silently tampered with during transit.

How HTTPS Builds a Secure Tunnel Through TLS

HTTPS solves the above three problems by layering TLS (Transport Layer Security) on top of HTTP. TLS's predecessor was SSL (Secure Sockets Layer), designed by Netscape in the mid-1990s. After SSL went through two major versions (2.0 and 3.0), IETF took over standardization and renamed it TLS. Currently all versions of SSL and TLS 1.0, 1.1 have been deprecated due to security vulnerabilities. Modern browsers require at least TLS 1.2, while TLS 1.3 (released in 2018) is the currently recommended version. This is why people still habitually say "SSL certificate," but modern HTTPS actually uses TLS.

Here's a key insight: HTTPS doesn't replace HTTP—it transmits HTTP messages inside an encrypted tunnel. Its essence is simply "HTTP over TLS."

On the classic TCP path, the beginning is exactly the same as regular HTTP—the browser still completes the TCP three-way handshake first. But after the handshake completes, the browser doesn't immediately send an HTTP request. Instead, it initiates a TLS handshake.

The TLS handshake serves two core tasks:

1. Allowing the browser to confirm it's communicating with the real server, not an impersonator;
2. Allowing the browser and server to negotiate a shared key to protect subsequent communications.

TLS Handshake Step One: Verifying Server Identity

The TLS handshake begins with a Client Hello. This message tells the server which TLS versions and encryption algorithm options (called "Cipher Suites") the browser supports. In TLS 1.3, the Client Hello also includes the client's key share parameters to reduce handshake round trips. The server then returns a Server Hello, selecting the connection parameters, and sends its certificate.

The certificate is the website's "identity document." It contains domain information, the server's public key, validity period, issuer information, and is signed by a Certificate Authority (CA) that the browser already trusts.

A Certificate Authority is a trusted third-party organization responsible for verifying the identity of website operators and issuing digital certificates to them. Browsers and operating systems come with a built-in set of "root certificates"—these root CAs form the trust anchors of the entire internet PKI (Public Key Infrastructure) system. In practice, root CAs typically don't directly issue certificates to end websites. Instead, they form certificate chains through "intermediate CAs": the root CA signs the intermediate CA's certificate, and the intermediate CA then signs the website's certificate. Major global CAs currently include Let's Encrypt (which provides free certificates and has greatly accelerated HTTPS adoption), DigiCert, Sectigo, and others.

Before trusting the connection, the browser performs a series of checks on the certificate:

• Is the certificate expired? If so, reject it;
• Does the certificate match the current hostname? If not, reject it;
• Can the certificate chain be traced back to a trusted CA? The browser verifies signatures level by level, from the website certificate to the intermediate CA to the root CA;
• Can the server prove it possesses the private key matching the certificate's public key? (In TLS 1.3, the server proves this by digitally signing the handshake transcript)

If any of these checks fail, the browser aborts the connection and displays a security warning.

This mechanism is precisely what prevents a random server from impersonating your bank, email provider, or internal admin panel.

TLS Handshake Step Two: Exchanging Keys Over an Untrusted Network

The certificate solves the identity problem, but it doesn't encrypt every byte of application data by itself. Encryption requires the browser and server to have a shared key—and this key exchange must be completed over an untrusted network.

Many HTTPS tutorials still use the older TLS 1.2 RSA key exchange as their teaching model: the client generates a pre-master secret, encrypts it with the server's public key, and sends it over; since only the server possesses the matching private key, only it can decrypt it. Both parties then derive the session's symmetric key from this.

This model helps explain why public and private keys are involved, but it is not how modern HTTPS actually works.

In TLS 1.3, static RSA key exchange has been removed. Certificates are still used for authentication, but the shared key is typically generated through Ephemeral Diffie-Hellman key exchange.

The Diffie-Hellman key exchange protocol was proposed by Whitfield Diffie and Martin Hellman in 1976 and is one of the pioneering achievements of public-key cryptography. Its core relies on the computational difficulty of the "discrete logarithm problem": given a large prime p and generator g, knowing the result of g^a mod p, it is computationally infeasible to deduce the exponent a. Modern TLS 1.3 uses an elliptic curve variant (ECDHE, Elliptic Curve Diffie-Hellman Ephemeral), which provides equivalent security with shorter key lengths (e.g., a 256-bit elliptic curve key provides security strength comparable to a 3072-bit RSA key), thereby reducing computational overhead and bandwidth consumption.

In simple terms, the client and server each exchange ephemeral public values while keeping their own private keys secret. Based on this information, both parties can independently compute the same shared key, which itself is never transmitted over the network.

This detail is crucial because it provides Forward Secrecy: even if someone records encrypted traffic today and later steals the server's certificate private key, they still cannot decrypt those historical sessions—because the ephemeral handshake keys are long gone.

Forward secrecy means in practice that each TLS session uses independently generated ephemeral key pairs. Even if an attacker records encrypted traffic long-term (which is not uncommon in state-level surveillance scenarios) and someday obtains the server's long-term private key by compromising it, they cannot retroactively decrypt past communications. This stands in stark contrast to the old RSA key exchange—in RSA mode, all sessions' symmetric keys were protected by the same server private key, and once that key leaked, all historical traffic would be exposed. This is precisely why TLS 1.3 mandates the use of key exchange algorithms with forward secrecy.

The mathematics behind key exchange is complex, but the goal is simple: at the end of the handshake, the client and server hold the same key; observers can see the handshake messages but cannot derive the key from them.

Encrypted Transmission: Symmetric Encryption Protects the Actual HTTP Data

At this point, the browser knows two things: which server it's communicating with, and that it has a key to protect the connection. Now, the browser can finally send its HTTP request.

This time, the HTTP request no longer appears as readable text on the network. The request path, headers, cookies, and body are all encrypted. Observers may still see some connection metadata (such as the server IP address or the domain name exposed through the SNI extension), but cannot read or silently tamper with the HTTP message itself.

The server decrypts the data, processes the HTTP request, and then returns an encrypted HTTP response.

So why switch to symmetric encryption after the handshake? Because symmetric encryption is fast enough to handle large volumes of data. Symmetric encryption algorithms (such as AES-256-GCM, ChaCha20-Poly1305) use the same key for both encryption and decryption. Their operations are essentially bitwise operations and permutations, achieving throughput of several GB per second on modern CPUs (especially processors with AES-NI hardware instruction set support).

Asymmetric encryption (public/private keys) is useful for authentication and key negotiation, but involves large-number modular exponentiation or elliptic curve point multiplication, making it typically 2-3 orders of magnitude slower than symmetric encryption. Therefore, TLS's design adopts a "hybrid encryption" strategy: use asymmetric mechanisms for one-time identity authentication and key negotiation, then use the negotiated symmetric key to protect all subsequent data transmission. After the handshake completes, the vast majority of content in the connection is regular HTTP data—headers, cookies, JSON, HTML, images, API responses—all requiring efficient encryption and integrity protection throughout the connection's lifetime.

It's worth noting that modern TLS uses AEAD (Authenticated Encryption with Associated Data) modes (such as AES-GCM) that simultaneously provide encryption and message authentication. This means any tampering with ciphertext is immediately detected by the receiver—this is the specific mechanism by which HTTPS solves the "message integrity" problem.

The Complete Mental Model: The Layered Relationship Between HTTP and HTTPS

Putting all the pieces together, we get a clear layered model:

• TCP is responsible for establishing a reliable connection (ensuring ordered packet delivery, retransmitting lost packets);
• TLS transforms this connection into a protected secure channel (identity verification + key negotiation + encrypted transmission + integrity checking);
• HTTP is responsible for carrying requests and responses (defining methods, paths, headers, status codes, and other semantics).

In plaintext HTTP, messages traverse the network directly. In HTTPS, the browser first verifies the server's identity, generates a fresh session key, and then the same HTTP messages are transmitted through an encrypted channel.

From the network protocol stack perspective, this layering is quite elegant: the HTTP layer doesn't need to know whether the underlying connection is encrypted, and the TLS layer doesn't care whether the upper layer is transmitting HTTP or some other protocol (in fact, TLS is also used to protect SMTP email transmission, FTPS file transfer, and other scenarios). Each layer does its own job, combining through clean interfaces.

Same HTTP, different security model—this is exactly what that extra letter "S" means.

Key Takeaways