HTTPS

HTTP transmits content in plaintext. Anyone on the same Wi-Fi network, an ISP along the network path, or a malicious router operator can inspect HTTP traffic. Login passwords, session cookies, personal information, and card numbers all flow through unprotected. In a man-in-the-middle attack, it is even possible to intercept a response, alter its content, and forward it to the user. The user has no way to verify whether the server they connected to is the real one.

The early web was designed for document sharing among researchers, so HTTP was built without considering authentication or encryption. When e-commerce emerged in the early 1990s and the need to securely transmit credit card information arose, Netscape developed SSL and layered it on top of HTTP, giving birth to HTTPS. Initially, the computational cost of encryption was high enough that it was common to apply HTTPS only to sensitive pages like payments and logins. But as hardware performance improved and TLS 1.3 simplified the handshake, the overhead dropped significantly. Today, browsers display a 'Not Secure' warning for HTTP sites, effectively enforcing HTTPS as the default.

An HTTPS connection first opens a TCP socket, then performs a TLS handshake. The handshake consists of roughly five stages. 1. ClientHello: The client sends the server its supported TLS versions and cipher suite list. 2. ServerHello: The server selects a cipher suite and sends its CA-signed certificate. 3. Certificate verification: The client checks that the certificate was issued by a trusted CA and that the domain matches. 4. Key Exchange: The client and server negotiate a session key. In TLS 1.3, a Diffie-Hellman-based exchange allows the session key to be derived without exposing the server's private key. 5. Finished: All subsequent HTTP traffic is encrypted with the negotiated symmetric key. The essence is two things: certificate verification to confirm 'is this server genuine?' and key exchange to create 'a channel nobody in the middle can read'.

The difference between HTTPS and HTTP is not just the presence of encryption. Because HTTPS verifies server identity through CA certificates, it also prevents man-in-the-middle attacks where an attacker impersonates the server and intercepts responses. With HTTP, the client has no way to know whether a response actually came from the real server. What HTTPS encrypts is the transport layer only. Data stored on the server, server-side logs, and the client device itself are outside the scope of HTTPS protection. HTTPS guards against eavesdropping and tampering on the network path -- it does not guarantee the security of the entire system. HTTPS and CSP (Content Security Policy) serve different roles. While HTTPS ensures the integrity of the transport layer, CSP controls which sources a page is allowed to load resources from. Malicious code that comes directly from the server, such as in an XSS attack, cannot be stopped by HTTPS.

HTTPS is now the baseline assumption for all public web services. Even when a server sends Set-Cookie in an HTTP response, the Secure attribute restricts the cookie to HTTPS connections only, and browsers like Chrome display warning banners on HTTP pages. Thanks to free CAs like Let's Encrypt, certificate issuance and renewal can be automated, so certificate cost is no longer a barrier. Web servers like Nginx and Caddy have built-in automatic certificate renewal, enabling HTTPS activation with a single line of configuration. HTTPS may be omitted for internal service-to-service communication or local development, but for services that receive public traffic, using HTTP without TLS is often disallowed by security policy. Especially in architectures where reusable credentials like OAuth or JWT tokens travel in headers, the absence of transport encryption directly exposes the system to session hijacking.