I know that enabling http compression would make a server vulnerable to the BREACH attacks. So we have disabled compression from the server side, tested and it was all good.
Then we implemented Cloudflare for the instance. We performed the SSL security scan again and found that the application is using gzip and so it is vulnerable to BREACH. From a detailed inspection we identified that the compression is enabled by Cloudflare.
Even though they claim that they have inbuilt BREACH attack prevention mechanism,folks from Security SE claims that BREACH can be exploited.
Then, in the next step, we disabled the Brotli compression offered by Cloudflare. But during testing, the scanner again detected compression. Now we are stuck. I understand that browser to Cloudflare traffic is compressed with Brotli and Cloudflare → Server will remain uncompressed (since we have disabled gzip from the server side). Does this actually mitigate the BREACH attack issue?
I guess it depends on whom you trust more. My money (and LOTS of other people’s money) is on Cloudflare.
The brotli compression is also vulnerable to BREACH. So I am definitely vulnerable irrespective of trust. I wanted the answer to couple of queries.
- Why does the SSL scanner show vulnerable to BREACH even when I disabled Brotli in CloudFlare and gzip from server side? This happens only when CloudFlare is active. If I am running my instance without CloudFlar and gzip disables, then the scanner says all good. So it has definitely something to do with CloudFlare.
- Let me assume that the scanner shows a false positive. In that case am I vulnerable to BREACH if compression is disabled on both server and CloudFlare?
I would like to have an authoritative answer to close this issue. I have posted the same is SO community as well.
If you want an authoritative answer, you’ll have to get it from Cloudflare itself:
Login to Cloudflare and then contact Cloudflare Support by clicking on the Get More Help button.
So you are asking multiple questions. The first is “Is Cloudflare vulnerable to BREACH Attacks?” The answer to that is no.
I have no idea why a 3rd party reporting tool would indicate it is, but in my experience it is much more likely that the tool is poorly designed (checking for the ability to request gzip content for example rather than actually trying to exploit the vulnerability). However, if they believe they have an actual exploit, Cloudflare participates in the HackerOne program for responsible disclosure and they can report it there.
The second question is “Why is my content compressed through Cloudflare?” The answer to that is Cloudflare will by defualt support compression when a client requests it. We support gzip by default and optionally Brotli. You have disabled Brotli compression, but our default behavior remains in place unless it is overridden by explicit cache control directives. You can include a no-transform directive in your cache headers to prevent Cloudflare from applying compression.
For your third question:
The answer is no. The mitigation is performed by Cloudflare as described in Answer 1 and in our associated blog posts, etc. If you want to disable compression and the associated performance benefits, you can as described in answer 2.
That sounds like a great answer. I read the PCI compliance and Clouflare SSL link you have provided. Just one more question.If we are not using cloudflare SSL for our application (we use another vendor for this), what happens in this scenario? Cloudflare offers BREACH attack prevention ony if their SSL service is used?
This topic was automatically closed after 30 days. New replies are no longer allowed.