What HTTPS does not protect
The padlock is a statement about two things: a name, and a key. It says the connection reached the server named in the certificate, and that nobody on the path can read or alter what flows. It says nothing whatsoever about who that server belongs to, or what they do with what you send.
| The padlock means | The padlock does not mean |
|---|---|
| The name matched a certificate | The site is honest |
| The traffic is unreadable on the path | The server stores it safely |
| Nobody altered it in transit | Nobody at the far end will misuse it |
| A CA vouched for the key | The CA checked anything but control of the name |
Certificates are free and automated, which is exactly right for encryption everywhere and means a phishing domain has one too. The padlock has never been an endorsement.
What an observer still learns
Encryption hides the body, and the envelope around it stays largely visible:
- The address. Packets have to be routed, so the destination IP is always in the clear — and for a single-tenant server that alone identifies the site.
- The hostname. SNI is sent in the plaintext ClientHello so the server knows which certificate to present. Encrypted Client Hello is the fix, and is still deploying.
- The DNS lookup, unless you use DNS over HTTPS or TLS — plain DNS announces the name to the whole path before the connection is even opened.
- Sizes and timings. Which page of a site you loaded is frequently recoverable from the pattern of response sizes alone.
Attacks the protocol does defend against
Not all of this is bad news. Some attacks were anticipated and closed with a few bytes. A downgrade attack works by editing the ClientHello — the one message that is not yet signed by anything — to strip out the strongest version on offer.
The defence is eight bytes the server writes into its own random value, which the client reads and recognises. It costs no round trip, and it cannot be stripped, because the server random is covered by the signature over the transcript.
The other half of the problem is the very first request, which is often plain http://
before any redirect. HSTS is the answer: a header instructing the browser to refuse
cleartext for this host in future, and preload lists ship that instruction with the
browser so even the first visit is protected.
Key takeaways
- The padlock states that a name matched a certificate and the channel is protected. It is not an endorsement of the operator.
- The destination address, the hostname via SNI, the DNS lookup and the traffic’s shape all stay visible.
- Downgrade attacks are defeated by a sentinel in the server random, which cannot be stripped because it is covered by the signature.
- HSTS and preloading close the cleartext first request, which is the gap a redirect alone leaves open.
- Interception works by adding a CA to the device’s trust store — TLS is not broken, the trust list was changed.