Surprised Troy is so pro-cloudflare. I feel like they create a lot of security headaches.
+1 for being interested in expanding this
They're presenting sites over HTTPS to visitors while tunneling the full request in plain text over HTTP across the internet back to the origin server. Because of this, web browsers like Chrome will allow access to sensitive APIs like Geolocation despite the end to end communication being insecure.
If I could, I'd personally blacklist all "Flexible SSL" sites from my daily browsing.
2 of Cloudflare's 3 SSL options generate an insecure setup yet look perfectly fine to the user with a shiny green padlock in the address bar. That really isn't acceptable.
You could still run a volume analysis on the reply. If it's very short, you can guess it's a 404. If it isn't, you might be able to get which prefix was queried... \end{tin foil hat}
> https://api.pwnedpasswords.com/range/aaaaa = 28.8KB
> https://api.pwnedpasswords.com/range/01234 = 28.5KB
> https://api.pwnedpasswords.com/range/af0fa = 23.2KB
The experiment is left as an exercise to the reader :)
[1] https://blog.cloudflare.com/incident-report-on-memory-leak-c...
This makes CF seem fine for your different variants of popcorn.gif, your (subresource integrity checked) Javascript implementation of the VIC-20 computer, or a public blog post, and NOT so great for patient access to histology results, private web forums, banking, and many other things on the Web.
1) Injecting themselves on the application layer (the current model)
2) Injecting themselves on the network layer, passing through only encrypted traffic between the client and your servers
Not every feature they currently offer would still be possible in model #2, but most of them (including DDOS protection) can still work in a limited fashion.