Hacker News Reader

Comment by RKearney | Hacker News Reader

> When a proxy root certificate is installed, Internet browsers lose the ability to validate the connection end-to-end, and must trust the proxy to maintain the security of the connection to ensure that sensitive data is protected.

Sort of like how CloudFlare does with their "Flexible SSL". As an end user, I have no way of knowing if CloudFlare is proxying my credit card information over clear-text to an insecure origin server.

View on HN

I really wish CF would phase out flexible SSL or at least disable it by default. (And warn users of the risks when enabling it.) Same goes for any CDN offering HTTPS to HTTP proxying over the public Internet.

It made a bit more sense in 2014 when there were more barriers to getting a real cert for your personal blog / forum / whatever - the cost of the cert itself, hosting companies charging for a dedicated IP (because they hadn't gotten the memo on SNI), or the maintenance burden of manually renewing if you ran your own VM.

But Let's Encrypt makes it trivial to auto-provision a real certificate, and many (if not most) hosts support setting it up through their control panels. The HTTP-01 challenge (which is now the default) works fine behind Cloudflare.

If you don't want to (or can't) use Let's Encrypt, Cloudflare themselves offer certificates from a private CA that you can install on your origin. These certs are trusted by their proxies and can last a lot longer than publicly-trusted certs (10+ years I believe), so it's a good option if you're stuck with a server setup that makes you manually upload cert files.

There's just no good reason to proxy HTTPS traffic over HTTP anymore (if there ever was). Enabling it by default is encouraging awful security practices.

Seconding CloudFlare's private CA. It's simpler and arguably more secure (less people to talk to, fewer moving parts, and most importantly, no need for backward compatibility), so there's really no excuse.

> There's just no good reason to proxy HTTPS traffic over HTTP anymore (if there ever was). Enabling it by default is encouraging awful security practices.

I'm a big fan of end-to-end encryption but I think a statement that broad should include a threat model. Not everyone is saving user credentials, credit card numbers, etc. and if you're primarily concerned about someone hijaacking the local network or untargeted national snooping, having HTTPS between the user and CloudFlare is a really big improvement because far more tampering happens at the edge rather than between the datacenter server serving your content and CloudFlare's network.

I do agree that this should be less and less acceptable as so much of the infrastructure has improved but there are still things like personal blogs and other content sites where you mostly don't want things like hostile ISPs injecting ads or malware onto your pages. That might make a good transition for Flexible SSL — start rebadging the UI to increasingly strongly emphasize that it's not suitable for sites with logins, PII, etc.

> "untargeted national snooping"

While I do not disagree with your sentiment, there have been cases of untargeted national snooping/censorship affecting sites with flexible SSL because governments can and often do sit between the local Cloudflare server and the origin.

https://medium.com/@karthikb351/airtel-is-sniffing-and-censo...

I've also been hoping that Cloudflare would add a header indicating the backend encryption status, so that we can look at how sites are configured and whether any "important" sites are using flexible SSL:

https://github.com/cloudflare/claire/issues/17

> Sort of like how CloudFlare does with their "Flexible SSL". As an end user, I have no way of knowing if CloudFlare is proxying my credit card information over clear-text to an insecure origin server.

Cloudflare should really message if this is the case when using their gateway. Small UI changes to note this would likely go a long way toward coercing better overall security.

When I use Cloudflare as a proxy, I also configure authenticated origin pulls[1] for better endpoint hardening. This makes it a bit more difficult to find a way to bypass the CF proxy, since hunting around on shodan etc. to find the server in the IPv4 space echoing the same content will not work.

[1] https://blog.cloudflare.com/protecting-the-origin-with-tls-a...

Just a note, unless you're also validating the Host: header (and possibly even then), Authenticated Origin Pull can be bypassed if someone does find the right server:

https://medium.com/@ss23/leveraging-cloudflares-authenticate...

(Could have been fixed in the past couple months, but I doubt it.)

Same for Access, by the way.

Sometime in 2Q you'll be able to upload your own client certificate (issued under your own CA if you like) to be used with Authenticated Origin Pulls.

Note: This user is a (the?) Director of Product at Cloudflare.

You can also use Argo Tunnel to create a secure tunnel between your origin and Cloudflare.

> "Cloudflare should really message if this is the case when using their gateway. Small UI changes to note this would likely go a long way toward coercing better overall security."

I've always hoped that Cloudflare would add a HTTP header indicating the backend encryption status. I filed this issue back in 2015: https://github.com/cloudflare/claire/issues/17

In fact, Nick Sullivan, the Head of Cryptography at Cloudflare, stated a few years ago: "CloudFlare would be very happy to be able to indicate to the user the nature of how data is encrypted beyond the IP you are connecting to. Unfortunately there is no way to do that yet in modern browsers. Soon we will be sending an additional header down to the browser to indicate if a site is using strict SSL, it will be up to the browser to display it." However, as far as I can tell, this has not been implemented.

https://blog.cloudflare.com/introducing-strict-ssl-protectin...

https://tools.ietf.org/html/draft-richsalz-httpbis-https-dow...

I was shocked when I saw what looked to me like Cloudflare was helping websites represent a website as being served over HTTPS and then actually communicating with the website owners servers via HTTP.

It works perfectly well if your threat model is someone sniffing your wifi but not someone sniffing the backbone.

Right. Doesn’t protect against the NSA but it protects against e.g. hackers snooping on unsecured WiFi or malicious actors creating a mitm WiFi access point to snoop on your traffic.

Is there an attack vector on the Cloudflare to Server leg?

Sure. The intermediate network(s) could sniff the traffic (or the lines could physically be tapped). There could be a BGP hijack on the origin IP, or a DNS hijack if using a hostname as the origin.

But these types of attacks are a lot more advanced than a guy with a packet sniffer in a Starbucks, and will target different types of victims. I.E. if you run a small web forum, it's unlikely someone is going to perform a BGP attack to steal your users' passwords. And the types of ISPs between Cloudflare and AWS usually won't inject ads into HTTP traffic.

The NSA's MUSCULAR project was running physical taps on the fiber links that BigCorps were running between their own physical infrastructure. I'm sure they could find a way to get between CloudFlare the sites it terminates HTTPS for, if they really want to.

https://www.washingtonpost.com/world/national-security/nsa-i...

Most likely would be a VPS or VLAN bug at a place like Digital Ocean, Linode, etc, that let you spy on neighbor VPS traffic. Not that it happens often, but there are historical bugs to escape VMs and/or containers. Once out, you could sniff traffic for the whole physical box.

Or a router/switch exploit. Create a monitor port and dump the traffic wherever you want.

This is a valid use case for providing some level of security for sites that may not be able to host TLS certificates. The theory is that most of the threats that need protecting are on the client side rather than the server side. This isn't perfect, but at least the traffic from the client to the Cloudflare edge is secured.

Not only that, but the ability by browsers to validate end-to-end depends wholly on browsers trusting CAs. I'd say that is a lot worse of a trust-level.

You don't know that with any app, though ... right? The only thing TLS gives you is knowledge of what can happen between you and whatever terminates TLS. It tells you nothing about what happens after that

Reply on news.ycombinator.com