Hacker News Reader

Comment by steckerbrett | Hacker News Reader

It's becoming unusual not to see sites behind CloudFlare now, pretty neat from a routing standpoint and devastating to user privacy and security on the whole. If things continue in this direction we'll have the cloudflare, and some scraps of regular internet off the side.

View on HN

The more popular it becomes, the more incentive there is for other companies to enter the space and grab a chunk of the money. The barriers to entry are not insurmountable for e.g. existing CDN companies to start offering DNS, WAF and DDOS mitigation products, making them more like Cloudflare. They already have the peering/hosting relationships and engineering teams experienced at working with large volumes of traffic. I wouldn't be too worried about Cloudflare taking over the internet this early on.

Is there reason for people to enter a market with a single obvious leader though? I got the impression that making peering agreements with people on any sort of scale was a bit of a bear. It is already quite ubiquitous, a surprising number of websites use it even if it's not completely obvious, reddit.com has some sort of stealth configuration that bypasses the normal DNS setup for example.

> Is there reason for people to enter a market with a single obvious leader though?

Were there not search engines before Google? Isn't AWS the cloud computing "leader" while Google is trying to break into the space? There is no such thing as an obvious leader, only juicy prey waiting for the next hungry org to eat its lunch.

> I got the impression that making peering agreements with people on any sort of scale was a bit of a bear.

Hardly. Peering agreements are of similar difficulty level as any vendor negotiation, whether it be with a specific network or an interconnection fabric (IXP).

That's how the market works... otherwise we wouldn't have any new companies if everyone gave up before competing with the big guys. There's a lot of potential to do better against anyone.

To continue with your point, we use https://sucuri.net/ where I work because it has such a great set of tools and extension for our Wordpress blog, which kept getting hacked.

Lots of space in this area.

Good example: "Sucuri is Building a Comprehensive Alternative to CloudFlare"

http://wptavern.com/sucuri-is-building-a-comprehensive-alter...

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.

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.

That's a lot of hyperbole there. If you look at the top 500 websites very few of them are behind CloudFlare, CloudFlare's penetration seems to be SMBs mostly (since larger orgs can afford the in-house mitigations that CloudFlare offers).

Did you know reddit is? You wouldn't know it from looking at the WHOIS, I'm betting lots of places are behind it without showing the normal indicators.

    Name Server: CNS1.REDDIT.COM
    Name Server: CNS2.REDDIT.COM
    Name Server: CNS3.REDDIT.COM

Doesn't look like it from here..

    ;; ANSWER SECTION:
    CNS1.REDDIT.COM.	172246	IN	A	   173.245.58.24

Delegated to?

    OrgName:        CloudFlare, Inc.
    OrgId:          CLOUD14

There we go! CloudFlare after all.

It might be easier if you use curl.

curl -I https://www.reddit.com HTTP/1.1 200 OK Server: cloudflare-nginx

Those top 500 websites have the money to sit atop of CloudFlare's enterprise plan, which I believe offers custom-branded DNS servers.

it’s routed through a high-performance interconnect instead of the public Internet

The public internet does seem to be shrinking, more and more closed data silos and now huge chunks of traffic going through a 'trusted' man-in-the-middle. From an individual sites standpoint it's amazing (and I use it for most of my sites), but the bigger they become the more juicy a target they are.

Is this not some kind of peering, though ? The way I see it, Cloudflare decided to peer with Google instead of using transit or, even worse, public internet (with the overhead it has over AS-to-AS connections). I don't see how the "public internet" somehow lost anything.

Reply on news.ycombinator.com