Network Security & TLS

September 28, 2026 • 10 min read

Table of contents

Assume the road is watched
Two kinds of lock
Certificates: someone has to vouch
The TLS handshake
What TLS does not do
Firewalls and NAT
The big picture

Everything in this series so far has been in the clear. Your packets were described as frames, segments, and headers, and every one of those words means a machine you do not control could read them. The application post left that open: the network is a public road with strangers on it, and HTTP is printed in the clear. This post closes the loop. What an attacker can do, the one piece of arithmetic that makes private conversations possible on a public network, who is trusted to say whose name is whose, and what all of it still fails to protect.

Assume the road is watched

Three things can go wrong on a network, and it is worth naming them precisely because every defense maps to one of them.

Eavesdropping. Someone reads what you send. Every router on the path, every provider along the way, and anyone on the same Wi-Fi can read plaintext HTTP.

Tampering. Someone changes what you send in flight. Without protection, a machine in the middle can rewrite a payment amount or inject a script into a page, and neither end notices.

Impersonation. Someone pretends to be the other end. If nobody vouches for names, the machine answering your request could be anyone at all.

In cryptography, the rule of thumb is that the network is hostile. Design assuming every packet is being read and written, and confidentiality becomes a property of the message instead of a property of the road.

Real example: on an open Wi-Fi network, a device that only forwards traffic can sit between you and a website, read unencrypted requests, and serve its own pages instead. With HTTPS, that device sees which host you are talking to and nothing about what you are saying.

Two kinds of lock

Cryptography offers two families, and the difference between them is the reason the internet works.

Symmetric encryption¹ uses one shared key for both encrypting and decrypting. It is fast, simple, and strong. Its only problem is distribution: to talk to a server you must already possess a secret it also possesses, and there is no way to send the first secret securely without already having one.

Asymmetric encryption² comes as a pair: a public key you give to the world and a private key you keep. What one can do, the other can undo. Encrypt with the public key and only the private key can decrypt. This solves distribution: an open, unauthenticated channel can carry a public key safely, because an attacker who substitutes his own key is the problem the next section addresses.

symmetric:     one shared secret           fast, both directions

asymmetric:    public key (share it)       slow, solves the chicken-and-egg
               private key (never share)   problem of getting the secret there

Neither is usable alone. Asymmetric cryptography is roughly a hundred times slower than symmetric and cannot encrypt a large document efficiently. Symmetric is fast but cannot start the conversation. Real security uses both, in a pattern called hybrid encryption:

1. asymmetric  prove identity, agree on a shared secret
2. symmetric   encrypt the actual data with that secret
3. symmetric   the data is encrypted separately in each direction

The bulk of the traffic is cheap symmetric encryption. Expensive asymmetric math happens once, at the start, to establish a secret that the fast layer then uses. Every encrypted connection on earth is this pattern.

Certificates: someone has to vouch

Asymmetric keys solve the transport of a secret. They do not solve the harder problem of identity, and this is the part people skip. If a machine in the middle sends you its own public key and claims to be your bank, the cryptography works perfectly and you have just been robbed.

The answer is a third party everyone already trusts: the certificate authority³. A public key certificate⁴ is a public key plus a statement about who owns it, signed by an authority. It is the digital equivalent of a notarized stamp: not that the claim is certainly true, but that someone paid to check.

your browser
   │  certificate: "example.com's key is correct"
   │  signed by: Let's Encrypt Authority X
   │  signed by: an authority in the browser's built-in root list
   ▼
the browser checks the signatures back up to a root it trusts

The browser ships a list of root certificates it was built with. If a chain of signatures leads from the server’s certificate to one of those roots, the browser accepts the identity. That entire trust system is public key infrastructure⁵, and the trust decisions were made long before your connection, baked into the browsers and operating systems you installed.

certificate chain:

root (trusted by your browser, pre-installed)
  └── intermediate (vouches for the next one)
        └── leaf: example.com's public key

Two consequences follow from this design. First, certificates expire, because a certificate with no end date could never be revoked quietly. Second, automated issuance exists: services like Let’s Encrypt issue certificates automatically to anyone who proves control of a domain, which is why enabling HTTPS went from an annual project to a single command.

The TLS handshake

TLS⁶ is the protocol that runs this pattern on every HTTPS connection. It happens in milliseconds, before any of your actual request, and it is the moment where the previous four sections all meet.

client                                   server
  │ ClientHello                            │
  │  - supported versions                  │
  │  - supported cipher suites             │
  │  - "I want TLS 1.3"                    │
  │  - server name: example.com            │
  │───────────────────────────────────────▶│
  │                          ServerHello    │
  │                          certificate   │
  │                          its key       │
  │◀───────────────────────────────────────│
  │                          Finished      │
  │◀───────────────────────────────────────│
  │ Finished                               │
  │───────────────────────────────────────▶│
  │                                         │
  ▼  both now share a secret                ▼  real data, encrypted

Step by step, because each step answers one problem:

ClientHello lists what the client supports and, in the server name indication⁷ field, which host it wants. This is why one IP address can serve thousands of sites and why that field, sent in the clear, leaks which site you are visiting.
ServerHello picks one version and cipher, and sends the certificate plus the server’s public key.
The client verifies the certificate back to a root it trusts. This is the step that makes impersonation fail: a fake certificate does not chain to a trusted root.
Both sides run a key exchange⁸ over those public keys to derive the same secret without ever putting it on the wire. In TLS 1.3 the client also sends its own contribution, so a middle machine cannot negotiate a secret and silently relay it. The channel is authenticated, not just encrypted.
Finished messages prove each side actually derived the same keys, which closes the last gap: an attacker who only forwards traffic is detected.
From here the connection is encrypted and every HTTP request rides inside it.

1 RTT: handshake with a session ticket from a previous connection
0 RTT: resumption using a ticket, data sent immediately
      (safe only for operations that tolerate replay)

The ephemeral part of the key exchange is what gives forward secrecy⁹. Because the key used for a session is thrown away when the session ends, someone who records traffic for months and later obtains the server’s private key still cannot read the old conversation. The certificate’s key proves identity; the throwaway key does the work.

What TLS does not do

Honest limits, because overclaiming here causes real damage.

It protects data in transit, not endpoints. A server that logs your messages in plaintext hands over everything anyway. TLS moves the trust boundary; it does not remove it.
It does not hide metadata. The addresses, ports, sizes, and timings are still visible, and so is the hostname in the server name indication. Someone watching knows who you talked to, not what you said.
It does not protect against a compromised authority. Whoever controls a trusted root can issue a certificate for any name. This is the entire weakness of the system, and the reason some people pin certificates or distrust authorities entirely.
It does not cover everything else. Plain HTTP is still everywhere, from internal tools to old APIs, and plain protocols like DNS and email remain largely unprotected by default.

Firewalls and NAT

Two network features get confused with security constantly, so here is what each actually is.

A firewall¹⁰ filters traffic. Rules decide which connections are allowed in and out, and a stateful firewall remembers which connections it has seen permitted, so replies come back automatically. A firewall protects a boundary: it does not read traffic, and it cannot help once traffic is allowed through.

NAT¹¹, from the network layer post, is address translation, and it exists because of the shortage of IPv4 addresses, not for security. Inside a network, many machines share one public address; the router rewrites addresses on the way out and keeps a table of who asked for what.

NAT has one genuine security side effect: a machine behind NAT has no publicly reachable address, so unsolicited connections cannot reach it. That is a side effect of address translation, not a design goal, and it is why a home router looks protected in ways a corporate network does not. It is not a security control, and it should never be used as one.

Real example: the difference shows up the moment you add a port forwarding, or a hole punched for a call. Opening one path to a machine behind NAT removes the accidental protection of that address hiding, and the machine is exposed to the internet directly.

The big picture

A public network means eavesdropping, tampering, and impersonation are all on the table, so security has to be a property of the message, not of the road. Symmetric encryption is fast but needs a secret already shared; asymmetric keys can carry a secret across a public channel but are slow, so real protocols use both. Certificates and a chain of trusted authorities turn a public key into a proven identity, and the TLS handshake combines verification, key exchange, and proof into a private channel in one round trip. Firewalls filter; NAT translates addresses and only incidentally hides machines. And all of it protects data in transit only.

client ─── ClientHello ───────────────────▶ server
         ◀── certificate + ephemeral key ──
         verify chain → derive secret → Finished
         ▼
      encrypted HTTP, unreadable to every router in between

One post left, and it is the one this series was building toward. The final post takes everything above and follows it in real time: one machine, one address bar, and the full journey of a single request across all the layers, from the first letter typed to the first byte rendered.

/tags

/sponsor

Enjoyed this post? You can sponsor me and this site.

/Related