We have a web application where a large amount of data flows over a specific TCP port.
I would like to proxy all traffic to the web app via Cloudflare on all ports, except traffic on this specific TCP port.
Is that possible?
Not without something like Enterprise Spectrum or using a different unproxied subdomain/direct ip.
Normal Cloudflare Proxy only supports HTTP Traffic, and enabling proxy works with the Domain Name System, enabling proxy makes Cloudflare respond to DNS Queries to that record with their own Proxy IPs (which only support HTTP Traffic), there’s no way for DNS to operate conditionally based on the port you want to use, it has no concept of that.
You could just create a subdomain (i.e unproxied.example.com), you wouldn’t have Cloudflare’s benefits like DDoS Protection and would be exposing your real origin, but it would work.
Of course, like I said above, if you had Enterprise Spectrum you can do whatever setup you’d like, normal http on ports 80/443, and then TCP on any inbound port proxied to any IP on any outbound port.
(In case it’s worth clarifying, Enterprise Spectrum would still be proxying via Cloudflare to your origin, if that entirely is undesired, then you’ll just need an unproxied 
record/subdomain )
Cloudflare’s normal http proxy only works on a few ports as well, if it’s worth mentioning:
Thanks for the clarification.
Just to make sure I understand:
When proxy is enabled for a DNS record, Cloudflare will respond with an IP to their proxies. This will send the data to that proxy instead of to the target. Cloudflare will now inspect the traffic, and if all goes well, send the request on to the origin server (my server). Correct?
If the Cloudflare proxy only supports the ports mentioned in the article you link to - what happens to traffic on other ports? Does Cloudflare just not inspect it (with the WAF, rules etc.) but will still send it to the origin server, or will the traffic not pass at all?
Final question:
Does Cloudflare decrypt the traffic (https) at the proxy to inspect it, and the re-encrypt it (http) to the origin server?
1: That’s the gist.
2. Other ports aren’t open, it’s just not accepted/goes nowhere. Cloudflare operates an Anycast network, and each IP they use is shared among a lot of customers. With HTTP Traffic, they use the Host Header/SNI to serve and route the traffic to the right user. With other traffic, they’d have no idea which customer it belongs to.
With Cloudflare Spectrum, they allocate a unique IP just to you, which is how you can use any port & any tcp/udp protocol.
3: Cloudflare, as well as most other Pull CDNs, work in the same way.
Cloudflare issues certificates for your site, by default a Universal SSL Cert. Requests come to Cloudflare, Cloudflare serves their “Edge Certificate” and decrypts the HTTP request (if HTTP, they don’t need to serve/decrypt of course). They process it through all of the features, WAF, Rules, etc, and then to cache. If there is an item in cache for the request, they serve cached response.
If there is no cached item, or cache isn’t configured/enabled (dynamic), a separate HTTP request from Cloudflare is made to your origin web server. This request contains the body and request headers (+ some Cloudflare specific request headers). Your origin serves the response, and Cloudflare streams it back through, caching it if enabled.
The request to your origin is according to your Cloudflare Configuration. You can override dest. port with Origin Rules for example, and your SSL/TLS Mode determines if the request is HTTP or HTTPS (only full strict is secure!), under the network tab you can configure if origin connections are over http/2, etc.
Cloudflare isn’t really decrypting it/re-encrypting it, it’s a fully separate request.
Let me know if that explains your questions.
Cloudflare has other resources as well that may help you understand:
Thanks.
That is a fantastic explanation and i greatly appreciate you taking the time to write it.
We use https strict in the settings, but even so, if an attacker compromised Cloudflare’s network, you would be able to eavesdrop on traffic, the user believes is encrypted all the way to the origin server, right?
The user doesn’t know the traffic flows through Cloudflare (I know he could check the dns records, but that is unlikely to be something the average user does). He has been trained to trust the SSL cert in the browser and believes that as long as that is green, traffic is encrypted from him to the destination.
But when proxying through Cloudflare, a third party can listen in (the third party being Cloudflare or anyone with access to their anycast servers).
Is that right?
I do realize this is mostly a theoretical question as I am sure Cloudflare does a lot to prevent this from happening, but none the less worth understanding.
Best regards
Soren
Sure, that sort of attack (comprimising/hacking Cloudflare’s servers to intercept traffic) is possible. Cloudflare takes security very seriously, has a HackerOne bug bounty program, Transparency Reports, etc.
When proxying through Cloudflare, Cloudflare, being your DNS, responds to DNS Queries with their Proxy IPs, and responds to HTTPS Requests with the certificates they have issued for your domain (which they can do because they can do dns validation to get certs issued). It’s not like anyone can listen in, it’s very specific in how it works. I get what you’re saying though, in theory sure Cloudflare could listen in, but the reason why they can do it is very specific, and they need to do it to offer their security (WAF), Features and Products (Page Rules, Html/css/js minifying, etc).
Cloudflare’s not alone in doing this, any Pull CDN like Bunny, AWS Cloudfront, Fastly, etc, all do the same thing. Without decrypting/MITMing the traffic, you can’t really do much, features-wise or security-wise. Couldn’t even serve challenge pages to suspicious visitors (or even figure out what a “suspicious visitor” is, as all they would really have is src/dst port/ips).
Hope that helps!
Thanks.
I fully understand that this is not a Cloudflare specific problem.
I am just aware that people’s perception of what they think happens with an https protected site (encryption between them and the end server) is often not what really happens.
As a user, you need to also trust whoever has injected themselves into the middle of the stream to do these kinds of (very valuable) services.
And you often don’t know who they are (unless you make the effort to know every time).
I don’t think most people are aware of this chain of trust issue and that traffic can be (and probably in almost all cases for larger sites is) MitM’d without breaking ssl and this without user consent and without informing the user that this is happening (again - a tech savvy user can find out, true).
An eye opener for me and very well explained by you.
Again I thank you for your time!
Best regards
Soren