I hoped it was apparent from my comment that "this is of course by design, to inspect the traffic" meant I understood they are doing it to detect DDoS traffic and separate it from legitimate traffic. But many Cloudflare users are not so technical. I would simply advocate for being more upfront about this behavior.
That said, their Magic Transit and Spectrum offerings (paid) provide L3/L4 DDoS protection without payload inspection.
Honestly, I was confused because both pages you link are full of the word proxy, have links to deeper discussions of what a proxy does (including explicit mentions of decryption/re-encryption), and are literally developer docs. Additionally Cloudflare's blog explaining these things in depth are high in search results, and also make the front page here on the regular.
I incorrectly interpreted your comment as one of the multitude of comments claiming nefarious reasons for proxying without any thought for how an alternative would work.
Magic Transit is interesting - hard to imagine how it would scale down to a small site though, they apparently advertise whole prefixes over BGP, and most sites don't even have a dedicated IP, let alone a whole /24 to throw around.
I understand your sentiment, as I reacted similarly the first time someone brought this to my attention. However, after logging into my Cloudflare account, viewing the DNS record page, and attempting to find any mention of SSL decryption, and then clicking on related docs pages (and links from them!) I was still unable to find this information.
You're right that Cloudflare has written many high-quality blog posts on the workings of the Internet, and the inner workings at Cloudflare. Amusingly, they even at times criticize HTTPS interception (not their use of it) and offer a tool to detect: https://blog.cloudflare.com/monsters-in-the-middleboxes/
I still believe that this information should be displayed to the relevant user configuring the service.
What are those many ways? Help me understand - I've been doing this shit a long time and I can't think of many ways to provide what Cloudflare does in a way that is cheap, easy, and scalable without working at the HTTP layer. So please help me learn something new, what are those ways?
offer a l2 load balancer that act as a queue. if the site decides its a dos/bad request it sends either a dowgraded response the load balancer can read or a side channel comms. then the load balancer drop everything from that ip or other identifiable patterns based only on l2 info.
there are many others. just buy a book for industries that value privacy or pay someone.
I hoped it was apparent from my comment that "this is of course by design, to inspect the traffic" meant I understood they are doing it to detect DDoS traffic and separate it from legitimate traffic. But many Cloudflare users are not so technical. I would simply advocate for being more upfront about this behavior.
That said, their Magic Transit and Spectrum offerings (paid) provide L3/L4 DDoS protection without payload inspection.
Honestly, I was confused because both pages you link are full of the word proxy, have links to deeper discussions of what a proxy does (including explicit mentions of decryption/re-encryption), and are literally developer docs. Additionally Cloudflare's blog explaining these things in depth are high in search results, and also make the front page here on the regular.
I incorrectly interpreted your comment as one of the multitude of comments claiming nefarious reasons for proxying without any thought for how an alternative would work.
Magic Transit is interesting - hard to imagine how it would scale down to a small site though, they apparently advertise whole prefixes over BGP, and most sites don't even have a dedicated IP, let alone a whole /24 to throw around.
I understand your sentiment, as I reacted similarly the first time someone brought this to my attention. However, after logging into my Cloudflare account, viewing the DNS record page, and attempting to find any mention of SSL decryption, and then clicking on related docs pages (and links from them!) I was still unable to find this information.
You're right that Cloudflare has written many high-quality blog posts on the workings of the Internet, and the inner workings at Cloudflare. Amusingly, they even at times criticize HTTPS interception (not their use of it) and offer a tool to detect: https://blog.cloudflare.com/monsters-in-the-middleboxes/
I still believe that this information should be displayed to the relevant user configuring the service.
There are many types of proxies, and MITM decryption is not an inherent part of a proxy. The linked page from the Admin Panel is https://developers.cloudflare.com/dns/manage-dns-records/ref... and links to pages like "How Cloudflare works" (https://developers.cloudflare.com/fundamentals/concepts/how-...) which still do not mention HTTPS interception. It sounds like you found a link I didn't. In the past someone argued that I should've looked here: https://developers.cloudflare.com/data-localization/faq/#are...
But if you look closer, those are docs for the Data Localization Suite, an Enterprise-only paid addon.
12 replies →
many ways but they are not plug and play so they would lose a few clients... but that is irrelevant as snooping trafic is their real businnes model.
What are those many ways? Help me understand - I've been doing this shit a long time and I can't think of many ways to provide what Cloudflare does in a way that is cheap, easy, and scalable without working at the HTTP layer. So please help me learn something new, what are those ways?
offer a l2 load balancer that act as a queue. if the site decides its a dos/bad request it sends either a dowgraded response the load balancer can read or a side channel comms. then the load balancer drop everything from that ip or other identifiable patterns based only on l2 info.
there are many others. just buy a book for industries that value privacy or pay someone.