HTTP vs HTTPS Explained

When you open a login page, type in your password, and hit submit, what happens under the hood? At a high level, the browser sends an HTTP request to the server, and the server sends an HTTP response back. That part is simple. The problem is what happens between the browser and the server. This is where HTTP and HTTPS behave very differently.

Before the browser can send application data, it usually establishes a network connection using the TCP three-way handshake. This is the classic path for HTTP/1.1 and HTTP/2. HTTP/3 uses QUIC instead of TCP, but we'll leave that aside for now. First, the client sends a SYN request. The server acknowledges it and replies back with a SYN-ACK. The client then sends back an ACK. Now the TCP connection is established.

With plain HTTP, the browser can send a request immediately. But here's the catch: the entire HTTP message travels in clear text—the request line, headers, cookies, and body. If this is a login form, the submitted username and password can be read by anyone who can observe the traffic. On a shared network, that could be a malicious Wi-Fi access point. It could also be a proxy or other machines sitting between the client and server. If an attacker can modify traffic in transit, they can also change the response before it reaches the browser.

In short, HTTP gives us a standard message format, but it has three fundamental problems: it does not provide privacy, it does not prove server identity, and it does not protect messages from being changed in transit. HTTPS fixes these problems by adding TLS. TLS stands for Transport Layer Security. SSL was the older predecessor, which is why people still say "SSL certificates," but modern HTTPS uses TLS. It's important to understand that HTTPS does not replace HTTP. Instead, it puts the HTTP message inside a secure tunnel. It is HTTP over TLS.

For the classic TCP path, the beginning looks the same. The browser still starts with the standard TCP handshake, but after TCP connects, the browser does not send the HTTP request yet. It first initiates the TLS handshake.

The TLS handshake has two jobs. First, the browser needs to know it is talking to the real server, not an attacker pretending to be that server. Second, the browser and server need to create shared keys that can protect the rest of the connection. Let's start with identity. The TLS handshake begins with a Client Hello. This message tells the server which TLS versions and cryptographic options the browser supports. The server responds with a Server Hello. It chooses the settings for this connection and sends its certificate.

The certificate is the website's identity document. It names the domain, includes the server's public key, and is signed by a certificate authority that browsers already trust. Before the browser trusts the connection, it checks the certificate. If the certificate is expired, it is rejected. If the certificate is for the wrong hostname, it is also rejected. The browser also checks the certificate chain. The chain must lead back to a trusted certificate authority. The server also has to prove it controls the private key that matches the public key in the certificate. If these checks fail, the browser stops and shows a warning. This is the part of HTTPS that prevents a random server from pretending to be your bank, your email provider, or your internal admin panel.

But the certificate does not encrypt every byte of application data. The certificate proves server identity. For encryption, the browser and server need shared keys. This is the second problem: key exchange over an untrusted network. Many HTTPS explanations use the older TLS 1.2 RSA key exchange as the mental model. In that model, the client generates a premaster secret, encrypts the secret with the server's public key, and sends the encrypted value to the server. Only the server has the matching private key, so only the server can decrypt it. Both sides then derive the symmetric keys used for the session. This model is useful because it shows why public and private keys are involved, but it is not how modern HTTPS usually establishes shared keys. In TLS 1.3, static RSA key exchange was removed. The certificate is still used for authentication, but the shared secrets are usually created with an ephemeral Diffie-Hellman key exchange. In simple terms, the client and server exchange temporary public values. Each side keeps its private key secret. Using those pieces, both sides calculate the same shared secret independently. The shared secret itself is never sent across the network. That detail is important because it gives us forward secrecy. If someone records encrypted traffic today and steals a server certificate private key later, they still should not be able to decrypt those old sessions. The temporary handshake keys are gone. The math behind the key exchange is complicated, but the goal is simple: the client and server finish the handshake with the same secret keys. An observer sees the handshake messages, but not enough information to calculate those keys. At this point, the browser knows two things: it knows which server it's talking to, and it has keys for protecting the connection. Now, the browser can finally send the HTTP request. This time, the HTTP request is not sent as readable text on the wire. The request path, headers, cookies, and body are encrypted. An observer may still see some connection metadata, such as the server IP address, but they cannot read or silently change the HTTP message itself. The server decrypts the data and processes the HTTP request. Then it sends back an encrypted HTTP response. Now, why switch to symmetric encryption? Because symmetric encryption is fast enough for bulk data. Asymmetric cryptography is useful for identity and key agreement, but it is expensive compared with symmetric encryption. After the handshake, most of the connection is regular HTTP data: headers, cookies, JSON, HTML, images, and API responses. All of it needs efficient encryption and integrity protection for the life of the connection. This gives us the full mental model. In the classic path, TCP creates the reliable connection, TLS turns it into a protected channel, and HTTP carries the request and response. With plain HTTP, the message travels directly across the network. With HTTPS, the browser first verifies the server and creates fresh traffic keys. Then the same HTTP message travels through an encrypted channel. It's the same HTTP, but with a different security model. That is why the "S" matters.