Building on the TLS handshakes we studied in the previous module, we now look at how this is applied to the web. HTTP (Hypertext Transfer Protocol) was designed for a trust-based environment where data was sent in cleartext. HTTPS is not a separate protocol, but rather HTTP residing inside a secure TLS tunnel.
In a standard HTTP connection, the application data is sent directly over TCP. In HTTPS, a 'TLS Layer' is inserted between the Application layer and the Transport layer. The TCP connection is established first, then the TLS handshake occurs, and only then does the HTTP request (GET, POST, etc.) begin to flow.
💡 A common misconception is that HTTPS encrypts the 'internet'. It only encrypts the communication between the client (browser) and the server (or proxy). The data is decrypted at the server and may then travel in plaintext across an internal backend network.
The key difference visible in the output is the port (80 vs 443) and the intervening TLS handshake. Without this handshake, every header, cookie, and password sent in a POST request is visible to anyone on the local Wi-Fi or ISP.
HTTPS provides three critical security guarantees: Encryption (hiding data from eavesdroppers), Data Integrity (preventing tampering during transit), and Authentication (proving the server is who they claim to be via the X.509 certificates we studied earlier).
⚠️ Encryption without Authentication is useless. If you encrypt data to a server but don't verify the server's identity, you are simply encrypting your data for an attacker who is performing a MitM attack.
| Feature | HTTP | HTTPS |
|---|---|---|
| Encryption | None (Plaintext) | TLS/SSL Encrypted |
| OSI Port | 80 | 443 |
| Identity Proof | None | X.509 Certificates |
| Integrity Check | None | HMAC / AEAD Tags |
| SEO Rank | Neutral/Lower | Positive Boost |
Modern browsers now label HTTP sites as 'Not Secure'. This is a psychological push to move the entire web to HTTPS. However, the 'Lock' icon only means the connection is encrypted; it does NOT mean the website is safe. A phishing site can have a perfectly valid HTTPS certificate.
Avoid 'Hardcoding' HTTP URLs in your application's API calls. This creates a vulnerability where a client might be tricked into sending data over a cleartext channel.
Verify exercises to earn ★ 130 XP and unlock next lab level.