8 ms·

Is anyone else getting worried about the amount of the internet that is proxied through cloudflare?

hoistbypetard 7y ago
That worries me the same way the consolidation of email services does, even though I don't find CloudFlare themselves as scary as I find some of the email providers. We've seen monocultures before. They can be really unhealthy for the ecosystem.
jesseb 7y ago
It's going to be interesting to see how much of the net is unavailable when they inevitably have a major outage.
- eganist 7y ago
  https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/ https://blog.cloudflare.com/details-of-the-cloudflare-outage...
filmgirlcw 7y ago
As opposed to the amount of the internet hosted by Amazon? Like, I understand the argument, I’m just not sure why we get angsty about one type of market dominance and not another.
- im3w1l 7y ago
  How much of the internet is hosted by Amazon?
  - BlueTemplar 7y ago
    From that "I tried to boycott the GAFAM" story, IIRC it was "about half" ?
- stephenr 7y ago
  Why can't we be concerned about both?
- PierceJoy 7y ago
  This is whataboutism. How do you know the parent isn't opposed to Amazon as well? Regardless, the topic here is Cloudflare, not Amazon.
- AznHisoka 7y ago
  Amazon has no control over who can visit what website, for the most part. They just host your site. Cloudflare on the other hands acts more like a gatekeeper. They have more control over who can visit.
  - oarsinsync 7y ago
    Unless you're managing the webserver process yourself, Amazon has the exact same level of control over who can visit your website as Cloudflare. When you're managing the webserver yourself, they can still filter by IP as they run the network. With a bit more effort (but this feels unlikely to be happening wide-scale), they can still transparently MITM your connections as the private keys are still stored on their infrastructure.
doctorpangloss 7y ago
If stuff like Face- and TouchID are really as secure as they claim, biometrics (and being able to afford an iPhone) could prove you are human and compete with elaborate DDoS protection. CDN and WAF are really competitive businesses though.
- CaptainMarvel 7y ago
  I don’t see what the security of biometrics has to do with proving you are a human for DDOS purposes..
  - deleted 7y ago
    [deleted]
  - alias_neo 7y ago
    I read it as using biometrics as your Captcha to prove you're human and hopefully pass without friction. Granted the idea would only really work on mobile due to the ubiquity of biometrics, but in context, I generally do git from OCs without any biometrics.
    - oarsinsync 7y ago
      Biometric authentication prove you're the same entity that enrolled, not necessarily that the entity that enrolled is human. Or to put it another way: Garbage In, Garbage Out.
      - alias_neo 7y ago
        Indeed, also biometrics, in my opinion are a terrible way to do any sort of remote proof/authentication; if your biometrics are "leaked" you can't just change them.
cmroanirgo 7y ago
I'm certainly concerned. Just the other day I was revisiting the notion that using SRV records in DNS for web traffic would be absolutely ideal for small to medium sites. Unfortunately, the browsers (which have faults listed against them) refuse to implement them. Instead we have these CDNs giving us the ever-valued low latency, rather than giving the next layer down infrastructure (you and me using our VPSes) the ability to do it without needing BGP AS# agreements and fixed IPs and the like. Now, the reasons the browsers don't implement them is because of the RFC which introduced SRV records suggested that existing tech shouldn't use SRV... Now the most damning thing about this is the Chrome [1] won't do it because Firefox didn't do it[0]...(see comment 2 on chrome/webkit bug). Both are excellent reads, with lots of coherent thought... and yet are just...rejected. And finally, there's this page: https://jdebp.eu/FGA/dns-srv-record-use-by-clients.html https://jdebp.eu/FGA/dns-srv-record-use-by-clients.html, which has a section: > The SRV Lookup Laggards' Hall of Shame For which Mozilla sits there as #1. So, yes, I'm concerned. Yes there are alternate ways so that everyone doesn't need to use a CDN. Yes, it's the browsers themselves that have been stopping us....for 19 years. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=14328 https://bugzilla.mozilla.org/show_bug.cgi?id=14328 [RESOLVED WONTFIX] [1] https://bugs.chromium.org/p/chromium/issues/detail?id=22423 https://bugs.chromium.org/p/chromium/issues/detail?id=22423 [RESOLVED INVALID]
- jiggawatts 7y ago
  Many of the arguments there boil down to: "SRV points to host names instead of IP address, so this is 2x the DNS round-trips compared to A records." Basically, they're complaining about the added indirection slowing down the user experience. Analysing their arguments is interesting. First: In 20 years since this rejection by the Mozilla and later the Google teams the load-balancing problems have been solved... just as inefficiently. The typical implementation of global services load-balancing (GSLB) or global traffic management (GTM) as commonly used in Citrix NetScaler or BIGIP F5 is to use DNS CNAME records pointing at a DNS stub zone "owned" by the load balancers. This delegation is done via NS records that have to be looked up as a second step. The appliances then return either a CNAME or A record pointing to the actual web servers. So between 1-4 DNS lookups is typical, but I've seen as many as 10+ in extreme cases. Azure CDN comes to mind, which has 6 CNAMEs in a row across several domains and associated name servers. More importantly, caching typically doesn't help much with GSLB/GTM, because they inherently must use short TTLs. There's a very direct trade-off between availability and performance. Typical TTL times are single-digit seconds to a couple of minutes at most. If it were any longer, clients would continue to try to connect to failed sites for a long time before giving up and requesting a fresh DNS address from the load balancers again. Hence, because of these low TTLs it is common for every page view on such sites to trigger at least one DNS request if you're clicking around at a normal rate. Hilariously, this doesn't show up in benchmarks because load-testing tools load pages fast enough to amortize this cost, so developer and testers don't notice! Second: Modern DNS servers use the "additional" section in their responses to also include the "A" records along with the CNAME or SRV host names. Windows Server DNS does this by default, as do many others. This means that the additional round trips are zero as long as the SRV records point to a zone managed by the same name server. In other words, SRV-based load balancing could use a single round-trip just like efficiently implemented GSLB/GTM solutions. This then combines with the client-side failover capability of SRV records to allow long TTLs, on the order of hours or days. Clients aren't forced to flush their DNS record caches to connect to secondary or tertiary sites, as they already have the records available and can fail over faster than with GSLB/GTM. Third: The "workaround" for the inherently poor DNS performance of traditional GSLB/GTM is to use IP routing tricks that make a single IP route to the nearest data centre location instead of a single destination. Cloudflare's 1.1.1.1 service and Google's 8.8.8.8 work like this, as does Azure Front Door. However, this is something that inherently requires a large scale to implement and is typically unavailable to small organisations. More centralisation of power into the hands of a few megacorporations is not healthy for the Internet! As an aside: I've noticed that Azure DNS Zones does not use the "additional" DNS response section, which means that two sets of lookups are required for every CNAME or SRV query. This doubles their revenue for alias records of all types compared to the more efficient implementation. I wouldn't say that this was done in bad faith, but from the outside it certainly looks... suspicious. Certainly, their incentive to grow their cloud revenue is much more direct than some nebulous public good of a "better, faster web".
skocznymroczny 7y ago
Yes, especially considering they already showed they are open to censorship.
- jjeaff 7y ago
  Choosing your customers is not censorship. They didn't block anything or censor anyone. They simply kicked a customer off their services. That customer was free to host their own traffic or find another CDN willing to serve them.
Snetry 7y ago
Seeing large chunks of the internet behind or controlled by one entity strikes fear in me

That worries me the same way the consolidation of email services does, even though I don't find CloudFlare themselves as scary as I find some of the email providers. We've seen monocultures before. They can be really unhealthy for the ecosystem.

jesseb 7y ago

It's going to be interesting to see how much of the net is unavailable when they inevitably have a major outage.

eganist 7y ago
https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/ https://blog.cloudflare.com/details-of-the-cloudflare-outage...

filmgirlcw 7y ago

As opposed to the amount of the internet hosted by Amazon? Like, I understand the argument, I’m just not sure why we get angsty about one type of market dominance and not another.

im3w1l 7y ago
How much of the internet is hosted by Amazon?
- BlueTemplar 7y ago
  From that "I tried to boycott the GAFAM" story, IIRC it was "about half" ?
stephenr 7y ago
Why can't we be concerned about both?
PierceJoy 7y ago
This is whataboutism. How do you know the parent isn't opposed to Amazon as well? Regardless, the topic here is Cloudflare, not Amazon.
AznHisoka 7y ago
Amazon has no control over who can visit what website, for the most part. They just host your site. Cloudflare on the other hands acts more like a gatekeeper. They have more control over who can visit.
- oarsinsync 7y ago
  Unless you're managing the webserver process yourself, Amazon has the exact same level of control over who can visit your website as Cloudflare. When you're managing the webserver yourself, they can still filter by IP as they run the network. With a bit more effort (but this feels unlikely to be happening wide-scale), they can still transparently MITM your connections as the private keys are still stored on their infrastructure.

doctorpangloss 7y ago

If stuff like Face- and TouchID are really as secure as they claim, biometrics (and being able to afford an iPhone) could prove you are human and compete with elaborate DDoS protection. CDN and WAF are really competitive businesses though.

CaptainMarvel 7y ago
I don’t see what the security of biometrics has to do with proving you are a human for DDOS purposes..
- deleted 7y ago
  [deleted]
- alias_neo 7y ago
  I read it as using biometrics as your Captcha to prove you're human and hopefully pass without friction. Granted the idea would only really work on mobile due to the ubiquity of biometrics, but in context, I generally do git from OCs without any biometrics.
  - oarsinsync 7y ago
    Biometric authentication prove you're the same entity that enrolled, not necessarily that the entity that enrolled is human. Or to put it another way: Garbage In, Garbage Out.
    - alias_neo 7y ago
      Indeed, also biometrics, in my opinion are a terrible way to do any sort of remote proof/authentication; if your biometrics are "leaked" you can't just change them.

cmroanirgo 7y ago

I'm certainly concerned. Just the other day I was revisiting the notion that using SRV records in DNS for web traffic would be absolutely ideal for small to medium sites. Unfortunately, the browsers (which have faults listed against them) refuse to implement them. Instead we have these CDNs giving us the ever-valued low latency, rather than giving the next layer down infrastructure (you and me using our VPSes) the ability to do it without needing BGP AS# agreements and fixed IPs and the like. Now, the reasons the browsers don't implement them is because of the RFC which introduced SRV records suggested that existing tech shouldn't use SRV... Now the most damning thing about this is the Chrome [1] won't do it because Firefox didn't do it[0]...(see comment 2 on chrome/webkit bug). Both are excellent reads, with lots of coherent thought... and yet are just...rejected. And finally, there's this page: https://jdebp.eu/FGA/dns-srv-record-use-by-clients.html https://jdebp.eu/FGA/dns-srv-record-use-by-clients.html, which has a section: > The SRV Lookup Laggards' Hall of Shame For which Mozilla sits there as #1. So, yes, I'm concerned. Yes there are alternate ways so that everyone doesn't need to use a CDN. Yes, it's the browsers themselves that have been stopping us....for 19 years. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=14328 https://bugzilla.mozilla.org/show_bug.cgi?id=14328 [RESOLVED WONTFIX] [1] https://bugs.chromium.org/p/chromium/issues/detail?id=22423 https://bugs.chromium.org/p/chromium/issues/detail?id=22423 [RESOLVED INVALID]

jiggawatts 7y ago
Many of the arguments there boil down to: "SRV points to host names instead of IP address, so this is 2x the DNS round-trips compared to A records." Basically, they're complaining about the added indirection slowing down the user experience. Analysing their arguments is interesting. First: In 20 years since this rejection by the Mozilla and later the Google teams the load-balancing problems have been solved... just as inefficiently. The typical implementation of global services load-balancing (GSLB) or global traffic management (GTM) as commonly used in Citrix NetScaler or BIGIP F5 is to use DNS CNAME records pointing at a DNS stub zone "owned" by the load balancers. This delegation is done via NS records that have to be looked up as a second step. The appliances then return either a CNAME or A record pointing to the actual web servers. So between 1-4 DNS lookups is typical, but I've seen as many as 10+ in extreme cases. Azure CDN comes to mind, which has 6 CNAMEs in a row across several domains and associated name servers. More importantly, caching typically doesn't help much with GSLB/GTM, because they inherently must use short TTLs. There's a very direct trade-off between availability and performance. Typical TTL times are single-digit seconds to a couple of minutes at most. If it were any longer, clients would continue to try to connect to failed sites for a long time before giving up and requesting a fresh DNS address from the load balancers again. Hence, because of these low TTLs it is common for every page view on such sites to trigger at least one DNS request if you're clicking around at a normal rate. Hilariously, this doesn't show up in benchmarks because load-testing tools load pages fast enough to amortize this cost, so developer and testers don't notice! Second: Modern DNS servers use the "additional" section in their responses to also include the "A" records along with the CNAME or SRV host names. Windows Server DNS does this by default, as do many others. This means that the additional round trips are zero as long as the SRV records point to a zone managed by the same name server. In other words, SRV-based load balancing could use a single round-trip just like efficiently implemented GSLB/GTM solutions. This then combines with the client-side failover capability of SRV records to allow long TTLs, on the order of hours or days. Clients aren't forced to flush their DNS record caches to connect to secondary or tertiary sites, as they already have the records available and can fail over faster than with GSLB/GTM. Third: The "workaround" for the inherently poor DNS performance of traditional GSLB/GTM is to use IP routing tricks that make a single IP route to the nearest data centre location instead of a single destination. Cloudflare's 1.1.1.1 service and Google's 8.8.8.8 work like this, as does Azure Front Door. However, this is something that inherently requires a large scale to implement and is typically unavailable to small organisations. More centralisation of power into the hands of a few megacorporations is not healthy for the Internet! As an aside: I've noticed that Azure DNS Zones does not use the "additional" DNS response section, which means that two sets of lookups are required for every CNAME or SRV query. This doubles their revenue for alias records of all types compared to the more efficient implementation. I wouldn't say that this was done in bad faith, but from the outside it certainly looks... suspicious. Certainly, their incentive to grow their cloud revenue is much more direct than some nebulous public good of a "better, faster web".

skocznymroczny 7y ago

Yes, especially considering they already showed they are open to censorship.

jjeaff 7y ago
Choosing your customers is not censorship. They didn't block anything or censor anyone. They simply kicked a customer off their services. That customer was free to host their own traffic or find another CDN willing to serve them.

Snetry 7y ago

Seeing large chunks of the internet behind or controlled by one entity strikes fear in me