Cloudflare network outage disrupts Discord, Shopify Following in the rickety footsteps of Fastly, bedeviled by a bug earlier this week, network services biz Cloudflare briefly stumbled on Friday as an elevated error rate interfered with connectivity for customers in Chicago and Los Angeles. "Cloudflare is aware of, and investigating an issue which potentially impacts multiple …
Cloudflare and other CDN networks have a problem,
1) servers are becoming faster so they don't speed up delivery they add an extra unnecessary hop that slows things down.... or worse, a 5 seconds "checking your browser" delay.
2) Traffic is becoming encrypted, and they often aren't trusted to see the encrypted traffic. So they cannot cache what they cannot read.
Their core service is becoming redundant. So what service *do* they offer if their core service, caching and delivery, is useless?
Snake oil?
Block price-tracking bots as if they're somehow a bad thing?
If they cannot see your traffic (because its all encrypted now) they cannot tell your customers from your DOS attackers and cannot filter one from the other.
Neither can they speed up the connection, if its encrypted, it still has to arrive on your pipe on your server.
You could give them access to your TLS certs..... here have access to all our customers private data......
Yeh, right.... I can see how that will end up.
That's a nieve view of how networking attacks work in the real world. A CDN that doesn't handle TLS termination can prevent, or aliviate, a number of low level DoS attacks.
Such a CDN wouldn't be able to protect against higher level attacks, but allowing a CDN to handle TLS termination is reasonably standard practice (as has already been pointed out).
Yes, even in AC's bizzare world where SSL connections are just passed through, CDN's would still offer protection against common DoS mechanisms (like SYN floods and other similar junk-at-TCP-level stuff).
What I can't work out, is why AC thinks a customer with that level of distrust would be using a CDN in the first place. Either you trust them to terminate your traffic, or you don't (and if you don't they can still do all kinds of nasty without needing your keymatter).
If you do, then you give them the means to terminate your traffic (SSL keymatter)/have them acquire their own (via LetsEncrypt or wherever). If you don't, then you shouldn't be using them.
TBH, I think AC may have confused a CDN with a router - his model seems to consist solely of forwarding packets on.
Not sure where you are coming from but it has been common practice for CDN to terminate SSL for over a decade now(probably much longer). Most(maybe all) of the major CDNs are PCI compliant as well(contacted several last year as I was expecting to have to jump CDNs again our previous CDN went out of business early last year). So they have visibility into everything traversing them from a protocol perspective anyway. Even if you encrypt individual files to transfer they can still be cached in encrypted form since the CDN will see the raw data as it decrypts the SSL/TLS on top.
Really can't imagine many customers out there not trusting their CDNs to decrypt the traffic. Servers are faster but in my experience at least servers have rarely been the bottleneck when it comes to traffic, servers are eaten up by app transactions. It's origin bandwidth and latency that CDNs help in the most simple use cases. Not too uncommon to get more than a 90% reduction in origin bandwidth with CDN.
But they can do more if your developers are willing to leverage them, one useful function several provide is automatic image resizing. Tried to get the devs to use it at the org I am at for years but they never wanted to, instead they wanted to store ~15 copies of each image(pre generated in advance regardless if any of those copies would ever get used) in different resolutions, just a waste of resources, made worse seeing some images on the size be super sized only to be reduced dynamically by image tags in the browser.
CDNs do offer a nice protection from (D)DOS attacks as well at least some varieties of them just because they have such massive capacity.
CDNs certainly can go down, so for those that is super critical that their CDN does not go down then use multiple CDNs either dumb round robin DNS or use an intelligent DNS provider that can do health checks on the backend and automatically re publish DNS entries to point to an alternate provider(in the past I was at a company that did this not with CDN but with our own multiple backend systems(app stack was entirely transactional no static content nothing could be cached) and we kept the TTLs to 60s or less I believe using an anycast DNS provider this was ~11 years ago. Prior to that they used BGP to fail over between sites but that was quite problematic so we changed to DNS failover).
> 1) servers are becoming faster so they don't speed up delivery they add an extra unnecessary hop that slows things down.... or worse, a 5 seconds "checking your browser" delay.
Only in the event of a cache-miss - and it was never just about speed, it's also about capacity. Yes, you can scale your origins to handle massive spikes, but it might not be cost effective to maintain that scale
> 2) Traffic is becoming encrypted, and they often aren't trusted to see the encrypted traffic. So they cannot cache what they cannot read.
When was the last time you used a CDN or understood how it worked?
CDN's terminate the SSL connection, and (in the event of cache miss) establish a new SSL connection upstream
> Their core service is becoming redundant. So what service *do* they offer if their core service, caching and delivery, is useless?
Only in your mind. In the real world, the CDN market continues to see significant growth. They're a commodity rather than a specialist service nowadays, but uptake continues to be absolutely massive.
> Snake oil?
If any of what you had said was true, maybe, unfortunately there's less accuracy in your comment than in a Trump tweet.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
