Why You Shouldn't Trust CloudFlare's 'Flexible SSL' and How to Bypass It With BetterCap

Let me clear one thing about this post … this is not a CloudFlare vulnerability report and, even in that case, there’s really nothing they could do in order to fix it unless they’d block direct traffic to HTTP websites.
This is only a blog post about why you shouldn’t blindly trust free services that offer you some sort of SSL protection if your server itself is not SSL protected by default.

UPDATE: n0on3 noted on twitter that even a properly configured server / blocking plain HTTP won’t work if the mitm catches the first request.

During this week, I’ve been playing with CloudFlare free plan in order to turn my websites into HTTPS protected websites, while configuring my account and playing a little bit with bettercap I figured out something really weird and I tweeted this ( from the @bettercap account ):

Someone from their team asked me to report this issue on HackerONE and eventually they decided to not accept it … well, not a big deal, I didn’t want to get money out of it in the first place and I didn’t consider this to be a “real” vulnerability from their side, but just something they should take into account while writing their documentation and informing users, this is how it ended ( and that’s why I’m disclosing this ) :

The Attack

My configuration is the following:

• One website hosted on my dedicated server running only via HTTP ( no HTTPS available ).
• CloudFlare SSL configured to Flexible ( since I have no certificate whatsoever ).

As you can see, with Flexible SSL, your server doesn't handle HTTPS traffic by itself.

• HSTS on with everything enabled ( browser preload as well ).

• A page rule configured ( as they wrote on the documentation ) to “Always uses https“.

What I was expecting was that every request made against the HTTP website would be redirected to the CloudFlare HTTPS endpoint, effectively forcing every user to only browse through HTTPS … well, it turned out that this configuration is quite easy to bypass using BetterCap or any other offensive tool that performs sslstripping and “Redirect to HTTPS” patching …

But how? And why?

This attack will work if and only if the victim/target is browsing the HTTP(S) CloudFlare protected website for the very first time, since from the second time on, its browser would cache the HSTS preload rule and would perform a HTTP -> HTTPS redirect without waiting for an actual 307 redirect from the CloudFlare’s proxy.

You just need to launch bettercap with the following command line arguments:

sudo bettercap -T IP-OF-THE-TARGET --proxy

From that moment on, bettercap will start sslstripping and patching every redirect to HTTPS:

As you can see from the screenshot, once bettercap intercepted the redirect to the HTTPS website, it just killed it and left the victim browsing the page through HTTP ( while proxying the data through HTTPS to the real endpoint ).
This allows the tool to see the traffic from both sides in cleartext, manipulate it, and so forth.

This happens because the my original webserver had only the HTTP port exposed and no HTTPS capabilities at all, as I already mentioned the only way for CloudFlare to fix this would be to block all the traffic going through the original HTTP server and only permit it if it’s through SSL.