How do you prevent man-in-the-middle vulnerability with CF?

Note: I haven’t setup a CF site yet; I’m still gathering information to decide whether I want to use the service. If my below description/understanding of how CF operates is incorrect, please provide correction in a comment.

As I was reviewing CF’s documentation for their WAF firewall, I saw the following note:

  • Access to http.request.cookies field requires a Cloudflare Pro, Business, or Enterprise plan.

Of course CF is a business and can’t give away all their services for free…but it got me thinking that if they block cookies sent from the user’s browser [e.g. for free users], what data might an attacker who managed to breach the CF network block or alter in transit?

For regular websites, usually TLS handles data security between the client and the server so that you have a configuration like:
Client <-> TLS <-> Server
Here, the client is communicating directly with the source server using a negotiated secret key.

But with CF, it looks like you have a configuration like this:
Client <-> TLS1 <-> CF <-> TLS2 <-> Server
In this CF configuration, clients are securely communicating with CF servers using a key associated with TLS1 and then CF decrypts the user data, [modifies?] and re-encrypts the data using a separate key associated with TLS2 to the source server. Responses from the server to the client perform the same steps, but in reverse. Using this configuration, CF has the ability to read/modify data from both the client and the server – it’s effectively a “man-in-the-middle” proxy.

To maintain security/integrity, between the client and my source server, what I really want is for CF to send the client the source server’s TLS certificate so that the connection looks like this:
Client <-> CF <-> TLS <-> Server
In this configuration, CF is just a pass-through proxy; the client makes a TLS request, CF applies whatever options I’ve applied [eg. firewall rules] and then proxies the connection directly to the source server so that source server negotiates the TLS key exchange. The source server response to CF is similarly a pass-through back to the client.

Looking at the CF plans/feature matrix, it looks like only enterprise and business plans are permitted to supply their own certificates?? Is that correct? Why?

I realize that by using CF as a direct-pass through proxy, the key exchange burden rests solely on the source server which can be an issue for DDoS protection features, but my website is almost entirely dynamic (extremely little static content) so that my backend source server is going to be handling the bulk of the processing anyways.

What I’m really looking for from CF is the ability to geoblock and intelligently work with implicitly blocking malicious connection attempts (e.g. by monitoring the CF network to identify malicious connections and block them from ever reaching my source server in the first place)

Many of the CF features seem intriguing, but so far I keep finding myself needing the business/enterprise plans to achieve a basic configuration that I would find acceptable. Unfortunately, I’m only an individual at the moment/can’t afford those higher tiered plans.

I’d love to hear that there is another way to achieve this functionality with the Pro plan (or something in-between Pro and Business.) It’s late here so I may have overlooked something.

As always, thank you for all helpful input.

Yep - that is required for Cloudflare’s product suite to function.

Not entirely sure how Cloudflare would do many firewall rules beyond plain IP/GeoIP if it couldn’t see within the data - but it’s not an option.

You would still supply Cloudflare with the private keys, nothing changes as far as Cloudflare still doing the TLS termination.

There is no way to achieve this functionality with Cloudflare. Well, maybe with a product like Magic Transit which is IP transit for Enterprises.

For obvious reasons, there’s a reason that Cloudflare Trust Hub exists & demonstrates the audits, regulatory compliance & safeguarding that goes into protecting your data from prying eyes.

Bummer, not having the option to use end-to-end encryption is a deal breaker for me.

Yeah, GeoIP [and CF known high risk IP] blocking are basically the only features I was interested in using from CF.

Bummer. Does CF Management watch these forums for suggestions?
Implementing this should be super simple for them/be more lightweight than relying on CF resources to perform the TLS termination. I’ve run my own configuration of this setup for close to 20 years so I’m really quite shocked they don’t already offer support for it.

Basically all I’m looking for from CF is for them to accept connections to my domain from their network IPs (if the incoming connection passes the WAF rules) and proxy them directly to my backend server, where my backend server will handle the TLS termination.

(The motivation for moving to CF is to demonstrate my efforts to geoblock regions that have active privacy legislation [Europe/GDPR, California/CCPA, Virginia…, various segmented locations.] )

Personally, I do not agree with this new internet model of fragmenting the internet with geoblocks, but several legal resources online recommend doing it to demonstrate the service does not target the restricted regions… (Of course there are VPNs, proxies, TOR, … so it’s really just more non-sense, but whatever)

I also noticed CF offers the ability to block by country in their WAF which is great, but it looks like blocking by US state is restricted to Enterprise/Business subscriptions. Why is blocking by state restricted to business accounts?

Anyways, if someone from CF Management is watching-- to use your service I need end-to-end TLS encryption terminated at my backend server (just forward everything not blocked by WAF to my box. I realize this doesn’t provide any DDoS protection benefits – and I also need the ability to block by country and US-state. I’m happy to pay for a Pro subscription, but can’t yet afford business level subscriptions.

Thanks all for your comments.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.