Weaponizing middleboxes

Posted Sep 22, 2021 1:52 UTC (Wed) by ttuttle (subscriber, #51118)
In reply to: Weaponizing middleboxes by bferrell
Parent article: Weaponizing middleboxes

These aren't CDNs, they're middleboxes. There's a big difference; sites delegate content serving to CDNs and CDNs serve content in consensual, above-board protocol ways, while middleboxes hijack connections and monitor or modify content in nonconsensual, sketchy protocol ways. It sounds like at least some of the attacks target those sketchy protocol behaviors, so they wouldn't apply to legitimate CDNs.

Weaponizing middleboxes

Posted Sep 22, 2021 2:18 UTC (Wed) by pabs (subscriber, #43278) [Link] (7 responses)

CDNs are just consensual middleboxes, I expect some aspects of CDNs are sketchy.

Weaponizing middleboxes

Posted Sep 22, 2021 2:22 UTC (Wed) by ttuttle (subscriber, #51118) [Link] (6 responses)

I would expect their DNS, TCP/IP, and (perhaps a bit less so) SSL stacks to be relatively above-board, and any sketchiness to be at the HTTP and above levels.

Nobody *wants* to do the kind of horrid TCP/UDP/IP hacks that middleboxes do; it's only necessary because they're not formally delegated to handle the connections and answer the requests they want to.

Weaponizing middleboxes

Posted Sep 22, 2021 2:37 UTC (Wed) by pabs (subscriber, #43278) [Link] (5 responses)

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.

Weaponizing middleboxes

Posted Sep 22, 2021 4:52 UTC (Wed) by ttuttle (subscriber, #51118) [Link]

That's terrible, but that's an application-layer problem -- their policies for the upstream HTTP(ideally-S) connections are wrong. It might be exploitable, but not in the way described here.

Weaponizing middleboxes

Posted Sep 22, 2021 12:07 UTC (Wed) by james (subscriber, #1325) [Link] (3 responses)

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.