[lkoolma]

After working with a few large corporations and their DDoS protection solutions, I did not have a good experience with Verisign, and they were not able to handle attacks or get things working. However, I have great experiences with Akamai and Cloudflare. I trust the people at Wikimedia will choose wisely. I would I have learned that Verisign has one of the worst BGP mitigation/scraping solutions out there. There are a few alternatives that have more experience and provide much better uptime, include solutions from Cloudflare and Akamai.

[dangxiaopin]

Any serious mitigation solution must be BGP based, not proxy. Besides its technical merits and convenience, it also minimizes the risk of a benevolent controller (e.g. Matthew Prince of Cloudflare) ruining your company, because it becomes your upstream provider only during the attacks. Otherwise the GRE tunnels are not in use. The IP addresses are still yours always.

We used Verisign for mitigation of a 44Gbps volumetric attack and it worked very well. We also evaluated Neustar, but Verisign's infrastructure seemed to be more robust.

[aftbit]

That's your requirement, but it might not be Wikipedia's requirement. Ownership of IPs is really a technical detail invisible to most people; ownership of eyeballs by way of the domain name and top Google result is probably more important. Cloudflare doesn't impact that ownership other than being able to temporarily take you offline if they choose to terminate your site.

Still, large proxy-based CDNs do have the ability to completely bypass all the same-origin protections in the browser. Even if they are angels and don't abuse this trust for identity theft and surveillance, it makes them a juicy target for bad actors, state sponsored and otherwise.

[snazz]

A proxy is a perfectly acceptable “serious” solution for this type of problem, as well as nearly all of the rest. Wikipedia is not the kind of website that would warrant being removed from Cloudflare. What’s wrong with having an upstream provider for caching close to the user and other features when you’re not under attack?

[SahAssar]

> What’s wrong with having an upstream provider for caching close to the user and other features when you’re not under attack?

The problem is that you are basically mitm:ed all the time.

[acdha]

That’s not what MITM means. I get that you don’t like Cloudflare but voluntary use of a CDN isn’t a MITM any more than, say, Amazon is a MITM because you host on EC2.

[SahAssar]

Cloudflare is in between the client and the server, decrypting, rewriting and (if set up right) re-encrypting the request/response. It masquerades as the server by presenting a proper certificate for the domain even though it is not the entity that is actually controlling the domain.

That to me sounds very much like MITM, although it is not a MITM attack since the entity controlling the domain opted into it, so basically it is voluntary MITM.

Using a VPS like EC2 is a different story since the decryption happens within the layer that you control. Of course you need to make sure that you choose a vendor for that layer that you trust, but on EC2 the traffic that amazon sees is encrypted with keys they don't have and decrypted with keys stored on a layer that I control. Amazon could read out the memory of my EC2 to get the keys but their business depends on not doing so, so in this case either I have a vendor that always will decrypt and read traffic (Cloudflare), or a vendor whose business depends on hypothetically being able to but not doing it. There is a clear difference to me.

That is the same for most CDN's (including CloudFront and all the other major offerings), so I'm not trying to single out Cloudflare.

[acdha]

If you don’t trust Cloudflare, don’t use them but there’s no meaningful security distinction between what they do and what AWS does: in both cases you have a vendor with the capability of violating your security and a promise that they won’t abuse that access.

This is why having a threat model is so important: it keeps you from wasting effort on things which sound like security but aren’t actually changing anything meaningful.

[cramforce]

The MITM can be avoided by using Signed Exchanges. https://developers.google.com/web/updates/2018/11/signed-exc...

[snazz]

Cloudflare’s business also depends on not messing with your traffic, right? It would certainly be easier for them to get your users’ content than for Amazon to do the same, but I think you still have to accept that risk with either. “Hypothetically being able to but not doing it” isn’t a whole lot of confidence if I were hosting some kind of shady website.

[dangxiaopin]

You upload your private SSL key to Cloudflare for example. And I was talking about hosting on your own hardware/colos like most large sites do (7x cheaper than AWS list prices on avg)

[acdha]

Please specify in detail how you believe that’s an MITM using the standard industry definition. In particular, consider whether “attack” and “voluntary business agreement” are synonyms.

[judge2020]

A better comparison would be Cloudfront and Application Load Balancers since you can expose your own ec2 server or load balancer and be e2e encrypted (unless AWS wanted to run commands on your instance, which they could do, but that's a different threat vector entirely).

[acdha]

That was the model I had in mind but it’s not really a meaningful distinction since the host could almost certainly compromise those servers as well. In any case, you’re trusting a third party rather than having their involvement maliciously imposed.

[awirth]

Akamai has a BGP based DDoS mitigation service via their prolexic acquisition.