Weaponizing middleboxes

Posted Sep 22, 2021 12:07 UTC (Wed) by james (subscriber, #1325)
In reply to: Weaponizing middleboxes by pabs
Parent article: Weaponizing middleboxes

As an example, ISTR reading about a CDN that was offering TLS encrypted connections, but either doing plain-text connections to the backend infrastructure or doing TLS connections but not verifying the certificates.

You could well be describing Cloudflare.

They support either:

no encryption between Cloudflare and the "real" server;
a self-signed certificate on the "real" server;
a Cloudflare-signed certificate on the "real" server that is valid for up to 15 years; or
a "real" TLS certificate

all while (normally) presenting the end-user with a valid TLS certificate.

The site does get to control which option Cloudflare will use: it's the first thing you'll see under TLS in the Cloudflare configuration site (and you have to go past that to enable user-to-Cloudflare TLS).

Rather more sketchy is their description of this as "end-to-end encryption" when Cloudflare is very obviously decrypting and re-encrypting the traffic.

Weaponizing middleboxes

Posted Sep 25, 2021 11:32 UTC (Sat) by nilsmeyer (guest, #122604) [Link] (2 responses)

> Rather more sketchy is their description of this as "end-to-end encryption" when Cloudflare is very obviously decrypting and re-encrypting the traffic.

I agree, this also seems to evade the privacy policy that all supposedly encrypted (there's a padlock in front of the URL!) data is shared with the CDN provider or whoever provides the load balancer.

Weaponizing middleboxes

Posted Sep 25, 2021 12:57 UTC (Sat) by mbunkus (subscriber, #87248) [Link] (1 responses)

Yeah sure. But that's just how it is. Most of the services offered by CDNs are inherently incompatible with end-to-end encryption (e.g. you cannot cache the content without having access to the content; you likely cannot do effective DDoS protection without inspecting at least parts of the content etc.). If your site gets enough traffic that you cannot handle it on your own with simple setups like haproxy/nginx in front of several backend servers, you have to bite the bullet somehow: either implement your own distributed infrastructure & keep all control or hire someone else & give them access to the unencrypted content in the middle (not in transit). As the former requires a lot of knowledge in all stages (design, implementation, management) it isn't something you can do within a short amount of time, often requiring hiring extra people, too. Using a CDN is the logical step, especially if you're in any way time-constrained.

And to be honest, I really have no quarrels with that kind of a model. I'm much more concerned about the myriad of half-incompetent people not configuring their data storage correctly & having my credit card information in world-readable databases or S3 buckets. 'cause that happens all the time, whereas one of the big CDNs somehow leaking your data… not so much.

Weaponizing middleboxes

Posted Sep 29, 2021 15:31 UTC (Wed) by nilsmeyer (guest, #122604) [Link]

The problem usually isn't even legitimate traffic, it's (D)DoS attacks and the scrubbing requires the CDN to at least have access to some metadata.