TLS

The lock icon in the browser address bar is not just saying “this connection is encrypted”. HTTPS has to handle identity verification, key negotiation, transport protection, and handshake latency, and it has to do that at Internet scale.

HTTPS is often broken into separate topics like certificates, cipher suites, HTTP/3, and QUIC, and then only a pile of terms is left. Once the main line is pulled back together, the structure becomes clear: HTTPS is essentially HTTP over TLS. What matters is not that HTTP changed, but that HTTP now runs over a secure channel with authentication and key negotiation.

TLS is often reduced to two words: encryption and certificates. That entry point is not wrong, but it is far from enough. What really changes engineering judgment is not “whether the data is encrypted”, but how the client confirms who it is talking to, how the two sides negotiate a session key on an open network, and how the mechanism can keep evolving without throwing away the old world.

If you only think of TLS as “a layer of encryption on top of TCP”, many later symptoms become hard to read. Why does an expired certificate stop the business request before it even leaves? Why do packet captures of TLS 1.3 show so little plaintext in the handshake? Why does 0-RTT save latency but still cannot be used for every request? Those cannot be explained by “encryption on or off” alone.