How HTTPS Actually Works (And What It Doesn't Protect)

Every time you log into a website, enter a card number, or send a message, HTTPS is the reason an attacker sitting on the same network can't just read it. Understanding exactly how it works — the handshake, the certificates, what can go wrong — is foundational for anyone doing web security.

HTTP vs HTTPS

Plain HTTP sends everything in cleartext. A request from your browser to a login page looks exactly like this on the wire:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=alice&password=hunter2

Anyone on the same network — same coffee shop WiFi, same ISP, any router in the path — can read this. HTTPS wraps HTTP inside TLS (Transport Layer Security), encrypting the entire request and response so only the intended server can read it.

The TLS handshake

Before any HTTP data is sent, the browser and server perform a handshake to agree on encryption parameters and verify the server's identity. Simplified:

• —ClientHello — browser sends supported TLS versions, cipher suites, and a random nonce
• —ServerHello — server picks a cipher suite and sends its certificate
• —Certificate verification — browser checks the certificate against trusted root CAs
• —Key exchange — both sides derive a shared session key without sending it over the wire
• —Finished — both sides confirm the handshake with a MAC, then start sending encrypted data

The entire handshake typically adds one round-trip. After it completes, every byte is encrypted with a session key that exists only in memory on both ends.

Certificates and trust

The certificate is how you know you're talking to the real server and not an attacker who intercepted the connection. It contains:

• —The server's public key
• —The domain it's valid for (e.g. *.example.com)
• —An expiry date
• —A digital signature from a Certificate Authority (CA)

Your browser ships with a list of trusted root CAs — organisations like Let's Encrypt, DigiCert, Sectigo. If the certificate chain traces back to one of those roots and the domain matches, the browser trusts it. If not, you see a red warning screen.

What HTTPS actually protects against

• —Eavesdropping — a passive attacker on the same network cannot read your traffic
• —Tampering — an attacker cannot modify data in transit without detection
• —Impersonation — certificate verification confirms you're talking to the real server

What HTTPS doesn't protect against

HTTPS is a transport-layer control. Once the data arrives at the server, it's decrypted. The server sees everything. HTTPS does nothing about:

• —SQL injection, XSS, IDOR — vulnerabilities in the application itself
• —A compromised server reading your data after decryption
• —Malware on your device that intercepts data before it's encrypted
• —Stolen session cookies — once issued, the cookie is the credential regardless of encryption

What attackers can still see

Even with HTTPS, some metadata leaks. The TLS handshake reveals the Server Name Indication (SNI) — the hostname you're connecting to — in cleartext, so a network observer can see which domains you visit. The IP address is always visible. DNS queries are usually unencrypted unless you're using DoH or DoT.

Encrypted Client Hello (ECH) is being rolled out to fix the SNI leakage, but adoption is still limited.

TLS versions

TLS 1.0 and 1.1 are deprecated — they have known weaknesses including POODLE and BEAST. TLS 1.2 is still widely used and considered secure with modern cipher suites. TLS 1.3 is the current standard: it removed weak cipher suites, improved the handshake to one round-trip, and added forward secrecy by default.

$ openssl s_client -connect example.com:443 | grep Protocol
    Protocol  : TLSv1.3

Finding a server that still accepts TLS 1.0 is a finding in a penetration test — it means downgrade attacks may be possible and weaker ciphers are available.

Certificate pinning

Mobile apps sometimes use certificate pinning — hardcoding which certificate or CA they trust rather than relying on the device's root store. This stops an attacker with a rogue CA from intercepting traffic even if they can install a certificate on the device.

It also makes intercepting traffic with Burp Suite harder during mobile testing — you need to bypass the pin with tools like Frida or by patching the app binary.