Hacker News Reader

Comment by AdmiralAsshat | Hacker News Reader

pretty neat from a routing standpoint and devastating to user privacy on the whole

I'm interested. Please expand on the privacy point. I thought the general move to CloudFlare was a good thing for privacy, as it provides an easy mechanism for getting sites onto HTTPS without having every site to worry about managing certificates.

View on HN

CloudFlare pipes all traffic through an interception proxy and delegates signing of SSL certificates to their own infrastructure. A domain behind CloudFlare can be monitored (they see everything in plaintext), the content tampered with, or the origin completely changed without a single notification to the outside world anything has been altered.

If you're sitting back in your evil chair, this is the perfect vantage point through which to intercept what seems like the majority of all browsing traffic in the world. Even if you're not planning world domination, this is an otherwise unobtainable amount of user metrics you can package up and sell.

The point between cloudflare and your app doesn't need to be unencrypted, the lack of privacy is that cloudflare is a massive MITM and thus has access to all the data between you and your app.

Thus the evil guy sitting back in their chair is cloudflare or it's you for not configuring https between your app and them.

And this announcement means that if your app is on Google Cloud, you don't need to encrypt between CF and your app. It's now going down a private interconnect, and I bet that interconnect is encrypted (like all Google's internal data pipes).

Besides Cloudflare being the biggest man-in-the-middle on the internet, their DDoS mitigation offering is also questionable. If you google "clouflare bypass" [1], you get to websites that can tell you the origin IP address of a cloudflare customer's domain name. So, malicious guys could hit the real IP directly.

[1] https://www.google.com/search?q=cloudflare+bypass

> If you google "clouflare bypass", you get to websites that can tell you the origin IP address of a cloudflare customer's domain name.

Those rely on a known DNS history from before CloudFlare was added to a domain. If bypass is a concern, changing the server's IP and making sure it never shows up in a public DNS record again solves things.

Yes, DNS history is one way to leak your IP. There are several other ways that the origin IP may get leaked, so you should be very careful if you use Cloudflare:

* Keep all subdomains on CloudFlare

* Don't use wildcard subdomains if you are not on Pro account

* Don't host mail or other services on the same server as your web server (email headers have origin IP)

* Never initiate an outbound connection based on user action

* Make sure that your web server and web application are patched against all known information disclosure vulnerabilities.

* Change your origin IP once configured for maximum DDoS protection on CloudFlare

Cloudflare documents it here: https://blog.cloudflare.com/ddos-prevention-protecting-the-o...

If CloudFlare is compromised by an intelligence agency or forced by law enforcement and courts to cooperate, they're a large single-point-of-failure for privacy.

Less severely, they themselves know the vast majority of sites users are visiting and the content they're being served. Valuable stuff for advertisers, among others.

Additionally, a lot of sites probably just use CFs crypto, without securing it to their backend servers. Hence there could be less encryption overall.

Indeed, CloudFlare will happily run an HTTPS front-end proxy to an origin which is using a self-signed certificate, or even to a HTTP origin. Thought that site was secure? Think again!

If the origin used a self-signed cert, doesn't cloudflare use certificate pinning?

CloudFlare strips HTTPS protection off on their machines and views all plain text. So, you get HTTPS protection on the public Internet in exchange for CloudFlare getting to see everything.

This may or may not be what you want/need.

Given what we learned from the NSA sniffing inter-datacenter communications within Google, do we really want wide scale solutions that rely on removing the SSL layer?

SSL added and removed at CloudFlare :)

It's worth remembering that that's one operating mode. There are others.

If they can cache it, they can read it.

Then I shall restate with greater precision.

The operating mode described by the comment to which I was responding, that of CloudFlare performing all steps of SSL termination, is one operating mode available. CloudFlare offers at least one other operating mode in which they are not responsible for all aspects of SSL termination. In particular, they offer an operating mode in which they do not hold private keys. This is referred to as "Keyless SSL". Thus the concern voiced by the comment to which I was responding, that of CloudFlare stripping SSL, is but one available option rather than the only available option.

Clearer?

Keyless SSL only prevents CloudFlare from having access to SSL key material. They can still read and modify any traffic that passes through them.

True, but this isn't the concern I was addressing.

And sometimes modifying is a desirable feature.

"Keyless SSL" is a bit of a misnomer. CloudFlare still holds the keys to encrypt and decrypt the content it is distributing and therefore sees everything (they can inject into your traffic as well). Even if they don't hold the private key, they can act in every way as if they did hold the private key.

Setting up HTTPS is not hard. Getting a certificate is not hard.

...for a single server. HTTPS on a cloud platform is significantly more difficult and expensive.

We use Google Appengine, and although they have an SSL solution, it was an order of magnitude cheaper and easier to use Cloudflare's SSL.

I'll qualify this by saying our site is public, so we only need SSL because of the HTTPS-only crusade. If you are serving sensitive data, you do need to spend that magnitude more money and time to set up your own SSL.

Reply on news.ycombinator.com