Transport Layer Security

A single request on the internet passes through many points: the café's shared wireless network, the building's network gear, a carrier's equipment, and then the server. Sent without protection, the contents can be read at any of those points. That includes the password sent at login. One untrustworthy hop is enough to expose the whole path.

Theo checked that state directly at Pagedeck once. One internal-only tool was serving without protection, and connected to café wireless he watched his own requests: document contents and the value representing his logged-in state were both visible. Copying that one value into another browser would have opened someone else's account. The tool had been left out of the rollout because nobody outside the company could reach it, which stopped being true on a café network.

Separate from interception, there's a second problem. Type the right address and have a different server answer in the middle, and the user has no way to tell. Hiding the contents doesn't solve that half. Who you are connected to has to be established as well, which is why Transport Layer Security (TLS) handles the two together.

It handles three things at once: hiding contents, verifying the other end, and detecting tampering.

1. Hiding contents. It applies encryption, turning the data into an unreadable form, to the transit path. Intercept it and what remains is a meaningless value.
2. Verifying the other end. The server presents a certificate that an issuing authority signed after confirming domain ownership. The browser checks the signature to judge whether this really is the owner of the address. The padlock in the address bar means that check passed. Ownership of the domain is all an ordinary certificate proves; nothing about the operator behind it is verified.
3. Detecting tampering. Change one character in transit and the receiving end notices. Hashing, which condenses content into a short irreversible value, supplies the material for that.

The opening of a connection runs in four steps.

1. The client opens a connection and sends the list of methods it can use.
2. The server answers with its certificate and the method it selected.
3. The client checks the certificate, and the two sides generate a temporary key for this connection only.
4. Everything after that travels encrypted under that temporary key. The list-and-select exchange in the first two steps is also where weak methods get refused.

Because a fresh temporary key is generated each time, a server certificate leaking later doesn't unlock conversations that already happened. That property is what the recent version of the standard pushed hardest on.

What actually trips teams up in operation is expiry rather than the technology. Certificates have a validity window — 90 days at the short end, a year at the long. Without automatic renewal in place, connections break one day on which nothing was changed. The performance cost belongs to an older era and is negligible now, though the extra round trips at connection setup are real, which is why the work is often terminated at a CDN or a load balancer first. Treat the renewal job as a service with alerting of its own.

For the job of protecting data in transit there is effectively no replacement. The things raised as comparisons cover a different scope.

1. Private networks and virtual private networks. These separate the passage itself from the outside. Inside that passage traffic often still travels unprotected, so the whole thing is exposed the moment the assumption that inside is safe fails. The passage and the contents are problems on different layers. A flat internal network turns one compromised laptop into access to everything reachable from it.
2. Application-layer encryption. This encrypts the payload once more, separately from transport. Messaging products where even the operator must not read the contents use it. It's a layer placed on top, not a substitute.
3. Encryption of stored data. That protects what sits on disk, which is a different problem. Both are needed and neither stands in for the other. Writing down what is applied where is how a missing stretch becomes visible.

What there is to choose is not an alternative but a version. Secure Sockets Layer (SSL), the old name in the same lineage, carries known weaknesses if used today, and the name survives only by convention — certificates are still called SSL certificates. In real configuration, allowing 1.2 and above with 1.3 preferred is the current baseline. Version support drifts like any other setting, so it gets reviewed rather than set once. On the web, a connection with this protection applied is called HTTPS, which isn't a separate technology but the same traffic carried over this standard.

"This internal tool is serving without protection. On shared wireless the login value is visible as-is."

Naming the stretch that got skipped because it was internal.

"The certificate expires next week. Let's confirm automatic renewal is in place."

Incidents in this area mostly come from expiry.

"I'm turning off the old versions. A few outdated browsers will fail to connect, and that's the right trade."

Choosing to lose a little compatibility rather than leave a weak configuration.

Theo applied this to every address, internal tools included, and set certificates to renew automatically. The rollout itself was half a day of work.

The trouble came afterward. One renewal failed and nobody noticed, and when the certificate expired overnight every connection broke. Screens showed a warning that the connection wasn't secure, and from the user's side that was indistinguishable from the service being down. The failure mode was silence — the automation reported nothing either way. Theo added separate monitoring that warns 30 days and 7 days before expiry. What was needed wasn't the automation but something watching whether the automation still ran.

The most common reading is that a padlock means a safe site, because browsers displayed that icon next to the word "secure" for years. What the icon guarantees stops at two facts: the connection is protected, and the address belongs to whoever holds it. A fraudulent site can obtain a certificate for its own domain, so the padlock appears there too. Whether to trust the site is a judgment made on other grounds, and browsers have quietly stopped labeling the icon as security.

Protecting only the login screen is the other common reading, since the password looks like the value that matters most. But every request after login carries the value that represents the logged-in state. Intercept that one value and the account opens without any password. A configuration that protects one screen has left everything except that screen open. A protected form embedded in an unprotected page fails the same way.