Questions › Networking/Security

HTTPS and TLS: what encryption buys you

Transport SecurityEasyNetworking/Security

What does HTTPS actually protect, and what does the TLS handshake establish? What does it NOT protect?

What it tests

Understanding the three guarantees of TLS and the common misconception that 'HTTPS = safe'.

Approach & answer

HTTPS is HTTP carried over TLS (Transport Layer Security). TLS provides three guarantees for data in transit: (1) CONFIDENTIALITY — the traffic is encrypted, so a network eavesdropper (someone on the same Wi-Fi, an ISP, a proxy) sees ciphertext, not your URLs' paths, headers, cookies, or bodies; (2) INTEGRITY — tampering is detected, so an attacker can't silently modify the page or inject content in flight; (3) AUTHENTICATION of the server — the certificate, signed by a trusted Certificate Authority, proves you're actually talking to example.com and not an impostor, which defeats man-in-the-middle attacks. The handshake establishes this: the client and server negotiate a cipher, the server presents its certificate (which the client validates against trusted CAs and checks the domain/expiry), and they derive a shared symmetric session key (modern TLS 1.3 does this in one round trip, using ephemeral keys for forward secrecy so a later key compromise can't decrypt past traffic). After the handshake, the actual HTTP flows encrypted with that fast symmetric key. Crucially, HTTPS protects data IN TRANSIT ONLY — it says nothing about what happens at the endpoints. It does NOT mean the site is trustworthy or safe (a phishing site can have a valid certificate — the padlock means 'encrypted connection to this domain', not 'good site'), it doesn't protect data once it's decrypted on the server or sitting in your browser, and it doesn't hide WHICH site you visited (the domain leaks via DNS and the TLS SNI field, though the path and content are hidden). Related pieces: HSTS (Strict-Transport-Security header) forces browsers to always use HTTPS for a domain, preventing downgrade attacks and protocol stripping. The practical takeaway: HTTPS is table stakes and protects the pipe, but 'has a padlock' is not the same as 'is safe to trust'.

Use this technique when

Explaining why HTTPS matters; correcting 'the padlock means it's safe'; reasoning about MITM.

Code

TLS gives you, for data IN TRANSIT:
  1. Confidentiality  eavesdropper sees ciphertext (not paths, cookies, bodies)
  2. Integrity        tampering in flight is detected
  3. Authentication   the CA-signed cert proves you're talking to the real domain

Handshake (TLS 1.3, ~1 round trip):
  negotiate cipher -> validate server cert -> derive shared session key
  (ephemeral keys => forward secrecy)

Does NOT mean:
  - the site is trustworthy (phishing sites can have valid certs)
  - your data is safe once decrypted at the endpoints
  - the DOMAIN is hidden (leaks via DNS + TLS SNI); path & body are hidden
HSTS header forces HTTPS-only, blocking downgrade/stripping attacks.

References