A home server behind a firewall sending traffic through an encrypted tunnel into a black-box global network, before reaching a browser. Below, a sealed document is unlocked, read, and resealed inside the network. A world map shows one compromised point radiating risk outward to every continent.

The Man in the Middle, By Design

By design, Cloudflare functions as a legal man-in-the-middle. Because they sit directly between a user and a website’s origin server to provide caching, firewalls and DDoS protection, Cloudflare can see all of that traffic in plain text — passwords, credit card numbers, the lot.

That isn’t a bug, a misconfiguration, or a worst-case edge condition. It’s the architecture working exactly as intended. The technical reason comes down to how the cryptographic keys are handled.

The Two-Connection System

When a user visits a website sitting behind Cloudflare, the connection is not a single end-to-end encrypted pipe running from the browser to the website’s real server. It's split into two separate connections, with Cloudflare sitting between them as the only party that holds both sets of keys.

  • Connection 1 — user to Cloudflare. The browser establishes a secure HTTPS connection with Cloudflare’s edge servers. Cloudflare holds the private SSL/TLS key for this connection, which means Cloudflare decrypts the traffic the moment it arrives at their data centre.
  • The plain-text buffer. For a brief moment, inside Cloudflare’s own server memory, the data sits completely unencrypted. This is the window in which Cloudflare inspects it — to block attacks through their WAF, filter out bots, or serve a cached copy.
  • Connection 2 — Cloudflare to origin. Once inspected, Cloudflare re-encrypts the data using a second certificate and passes it on to the real website server, often through a Cloudflare Tunnel.
User browser SENDS YOUR DATA CONNECTION 1 Cloudflare HOLDS BOTH KEYS CONNECTION 2 Origin server RECEIVES DATA PLAIN TEXT, INSIDE CLOUDFLARE’S MEMORY Passwords · cookies · session tokens Uploaded files · credit card numbers THIS IS WHAT MAKES THE WAF, BOT FILTERING AND CACHING POSSIBLE
Two encrypted connections, one unencrypted moment in the middle. That moment is not an accident — every feature Cloudflare sells depends on it existing.

Why They Must Control the Encryption

Cloudflare cannot perform its core duties without decrypting the traffic first. If the data stayed encrypted end-to-end, from the user all the way to the web server, none of the following would be possible:

  • The Web Application Firewall could not inspect incoming data to block SQL injection or cross-site scripting payloads.
  • Bot Management could not read HTTP headers or behavioural cookies to identify and block scrapers.
  • Their servers could not read the specific URL paths being requested, which makes web caching impossible.

Every one of those is a genuinely useful feature. That’s precisely what makes the trade-off worth naming rather than ignoring: the convenience and the visibility are the same mechanism. You cannot buy one without the other.

The Enterprise Exception

Tellingly, Cloudflare does offer architectures that avoid this — but only to clients who can pay for them, and for whom the legal exposure of a third party reading raw customer data is unacceptable. Banks and government institutions get options ordinary customers don’t:

  • Keyless SSL. The website owner keeps their private cryptographic key strictly on their own hardware. Cloudflare’s edge servers talk to the client’s key server to complete the handshake, but the key itself never leaves the client’s premises.
  • Spectrum. Cloudflare acts as a simple packet forwarder at the transport layer, without decrypting anything. It terminates the TCP or UDP socket at each end but passes the payload through untouched — which also means no WAF, no caching, and no application-layer inspection of any kind. You get the DDoS protection and lose everything that requires reading the traffic.
  • Encrypted log payloads. When Cloudflare logs a blocked attack, DLP lets the customer encrypt that log entry with their own public key. Cloudflare can no longer read what it just captured — only the customer, holding the matching private key, can decrypt it later.

Notice what all three have in common: each one exists specifically to take Cloudflare back out of the plain-text loop. If the default architecture were as harmless as it's often made to sound, these products wouldn’t need to exist.

Why FS HOT Will Never Use Cloudflare

None of this is really about whether Cloudflare is trustworthy on any given day. It’s about what the architecture requires, structurally, regardless of anyone's intentions.

My Problem with this A significant proportion of the web now passes through one Cloudflare’s edge servers to get anywhere at all. That is a concentration of trust and visibility that no single organisation should hold.

FS HOT sits on its own server, behind its own firewall, with its own certificate, talking to visitors directly. One connection, not two — which happens to be quicker, not slower, than routing everything through someone else’s edge network first. But speed was never really the point. Nobody’s plain-text buffer sits between you and this page.