4 ms·

I've never understood CloudFlare's position on this issue/feature. They generally do a great job at improving, caring and fighting for internet security, yet co

I've never understood CloudFlare's position on this issue/feature. They generally do a great job at improving, caring and fighting for internet security, yet continue to offer a product (Flexible SSL) that they know is insecure: This option is not recommended if you have any sensitive information on your website. It should only be used as a last resort if you are not able to setup SSL on your own web server, but it is less secure than any other option (even “Off”) [1] So by CF's own admission this is less secure than having SSL disabled. That's of course technically incorrect assuming the visitor is aware that SSL is terminated at CloudFlare, and insecure from there to the origin server. If the visitor is aware of this distinction (and know what it means, which includes knowing where the CF edge and origins are located) then it does add some security (the coffeeshop's Wi-Fi etc). However it's probably fair to assume that most visitors of CloudFlare-protected sites are not aware of this distinction. They're probably just aware that Green Lock + HTTPS = secure. So instead this product primarily gives a visitor a false sense of security, which in my opinion is much worse and potentially dangerous. I guess CloudFlare agrees with that; why else would they say it's less secure than no SSL? In the end, CloudFlare should clarify why they continue to offer a seemingly secure encryption product that they themselves consider less secure than no encryption. They say it should only be used "as a last resort", but when is choosing "Flexible SSL" really the last resort? I mean, you can just disable SSL entirely or do it properly (and even get a free certificate from CF), both of which are more secure. I don't know, but here's an idea: It might be a good product for CloudFlare customers, such as TBP, who don't care enough to actually secure their visitors' traffic, but still want to give the appearance thereof. Which is exactly what the more prominent product page lists as the advantages of "Flexible SSL"[2]: - You do not need an SSL certificate on your server. - Visitors will see the SSL lock icon in their browser. I might be missing something and I'd honestly appreciate if someone can shed some light on this. I respect CloudFlare a lot and appreciate their efforts to improve internet security. It's just difficult to maintain a brand as a company on the forefront of the internet security battle, while also enabling customers to somewhat deceitfully give the appearance of security at the expense of their visitors' security and safety. It seems pretty clear that CF needs to discontinue this product before it hurt their brand as well as unassuming visitors. [1] https://support.cloudflare.com/hc/en-us/articles/200170416-What-do-the-SSL-options-mean- https://support.cloudflare.com/hc/en-us/articles/200170416-W... [2] https://www.cloudflare.com/ssl/ https://www.cloudflare.com/ssl/

regecks 10y ago
Yup, I have never seen a straight answer to this concern. One one hand, it seriously undermines the meaning of the browser padlock. On the other hand, this has already been happening in less visible ways - Cloudflare is definitely not the first to do this. Plenty of sites and services terminate SSL early (and plenty of public CDNs offer edge SSL). The idea of end-to-end transport security via TLS is a bit flimsy to begin with tbh. What I find disappointing is that it encourages the "checklist security" approach. Management/dev/ops sees that this is the simplest way to get the padlock to show up, and the story ends there.
witty_username 10y ago
Suppose Flexible SSL were disabled and HTTP was used instead; then a malicious actor can redirect the page "http://thepiratebay.com" http://thepiratebay.com" to "https://thepiratebay1.com" https://thepiratebay1.com". Thus HTTPS (encryption) is there, but it isn't The Pirate Bay (authentication is not there). So, Flexible SSL is still better than HTTP, at least you're protected from your coffee shop.
- deleted 10y ago
  [deleted]
- runesoerensen 10y ago
  I agree that it's somewhat technically more secure in that it prevents a wide array of attack vectors. Despite of that my point is that, for the vast majority of visitors, the solution ends up being less secure due to imperfect information; If you access a service over HTTP you can accurately asses the (lack of) security and, based on an informed assessment of the risks, decide wether you want to proceed. If you access a site over a seemingly secure connection that is terminated prior to reaching the origin, then you most likely don't have the necessary information to assess the security and associated risks relative to what you're doing: Your browser is telling you that you're at the right domain and that the connection is secure with modern cryptography (if the site is using CloudFlare). However that's not the entire story. The browser is not telling you that the secure connection is terminated at the CloudFlare edge. This leaves it to the CloudFlare-protected site to inform the visitor that the connection is only secure some of the way in order for the visitor to make an accurate assessment of the connection's security. I don't think most CF customers who pick "Flexible SSL" are thoroughly and accurately informing visitors of these nuances (and even if they are an MITM can modify it). That's why I absolutely do not think it's better than HTTP -- exactly because of the problems outlined in this article. In this case I'd argue that, from the perspective of a TBP visitor, "Flexible SSL" improves security on less relevant vectors while significantly decreasing security on the vectors that matter. The coffee shop owner probably doesn't care that much about the IP rights of H/Bollywood, but this is the attack vector that Flexible SSL helps mitigate. The government does however care about such rights and CloudFlare's ISP was forced/willing to help them. CFs solution did nothing to mitigate this vector. Now I'm not saying this is all CloudFlare fault, but I do think they share a part of the responsibility. TBP's recklessness has allowed millions of people around the world to access and use their site under the false assumption that they were protected. What I don't get is why CloudFlare has any interest in enabling such behavior. They know full well the risks associated with this solution and even admit it's inferiority compared to commando-style unencrypted HTTP. It also decreases my trust in other CloudFlare-protected sites - for all I know, as a visitor, the site may or may not be using Flexible (or perhaps just "Broken") SSL. My suggestion is simply that they use their knowledge to provide a better service to their customers and their visitors. That probably means discontinuing this product - or clarify why the don't think that's necessary.

regecks 10y ago

Yup, I have never seen a straight answer to this concern. One one hand, it seriously undermines the meaning of the browser padlock. On the other hand, this has already been happening in less visible ways - Cloudflare is definitely not the first to do this. Plenty of sites and services terminate SSL early (and plenty of public CDNs offer edge SSL). The idea of end-to-end transport security via TLS is a bit flimsy to begin with tbh. What I find disappointing is that it encourages the "checklist security" approach. Management/dev/ops sees that this is the simplest way to get the padlock to show up, and the story ends there.

witty_username 10y ago

Suppose Flexible SSL were disabled and HTTP was used instead; then a malicious actor can redirect the page "http://thepiratebay.com" http://thepiratebay.com" to "https://thepiratebay1.com" https://thepiratebay1.com". Thus HTTPS (encryption) is there, but it isn't The Pirate Bay (authentication is not there). So, Flexible SSL is still better than HTTP, at least you're protected from your coffee shop.

deleted 10y ago
[deleted]
runesoerensen 10y ago
I agree that it's somewhat technically more secure in that it prevents a wide array of attack vectors. Despite of that my point is that, for the vast majority of visitors, the solution ends up being less secure due to imperfect information; If you access a service over HTTP you can accurately asses the (lack of) security and, based on an informed assessment of the risks, decide wether you want to proceed. If you access a site over a seemingly secure connection that is terminated prior to reaching the origin, then you most likely don't have the necessary information to assess the security and associated risks relative to what you're doing: Your browser is telling you that you're at the right domain and that the connection is secure with modern cryptography (if the site is using CloudFlare). However that's not the entire story. The browser is not telling you that the secure connection is terminated at the CloudFlare edge. This leaves it to the CloudFlare-protected site to inform the visitor that the connection is only secure some of the way in order for the visitor to make an accurate assessment of the connection's security. I don't think most CF customers who pick "Flexible SSL" are thoroughly and accurately informing visitors of these nuances (and even if they are an MITM can modify it). That's why I absolutely do not think it's better than HTTP -- exactly because of the problems outlined in this article. In this case I'd argue that, from the perspective of a TBP visitor, "Flexible SSL" improves security on less relevant vectors while significantly decreasing security on the vectors that matter. The coffee shop owner probably doesn't care that much about the IP rights of H/Bollywood, but this is the attack vector that Flexible SSL helps mitigate. The government does however care about such rights and CloudFlare's ISP was forced/willing to help them. CFs solution did nothing to mitigate this vector. Now I'm not saying this is all CloudFlare fault, but I do think they share a part of the responsibility. TBP's recklessness has allowed millions of people around the world to access and use their site under the false assumption that they were protected. What I don't get is why CloudFlare has any interest in enabling such behavior. They know full well the risks associated with this solution and even admit it's inferiority compared to commando-style unencrypted HTTP. It also decreases my trust in other CloudFlare-protected sites - for all I know, as a visitor, the site may or may not be using Flexible (or perhaps just "Broken") SSL. My suggestion is simply that they use their knowledge to provide a better service to their customers and their visitors. That probably means discontinuing this product - or clarify why the don't think that's necessary.