@tasket wrote:
<<< FWIW, its not clear to me that a CDN using individual certs for multiple unrelated domains is so much of a problem, as long as the private key stays with the CDN. The user is placing their trust in the technical competence of the service that contracted the CDN. However, I would like to see a paper or blog post that explores the threat model you're suggesting. >>>
There are none that I know of.
But IMO it's not hard to understand that, when your browser is NOT DIRECTLY communicating with the server of a suggested owner, the attack surface significantly increases, because:
• The higher the concentration of information, the higher the risks. If they want (and they do, because it pays off), cloud- and CDN providers can spy on every byte that passes through their networks. If not unecrypted data, at the very least meta data. In NL we say: "kennis is macht" which translates into "knowledge means power". Big tech literally knows EVERYTHING about us. That's extremely scary.
• Your browser has an E2EE connection with a sneaky MitM instead of to the server you were made to believe it is.
• Fastly is an alias for FISA Section 702. Google and Let's Encrypt simply *LIED* to us when they said that we needed "encrypted connections" because of the Snowden revelations. That argument is moot if one of the E's in E2EE is not a server that is ONLY accessible by trustworthy employees of the owner of the domain name.
• You don't know *anything* about the actual "upstream" server and the security of the connection between the MitM and the actual server. There may even be more MitM's without you knowing it. You also don't know the IP-address of the actual server, so you cannot determine its location: it may be hosted in Russia, China, North Korea or Iran.
- CDN's are the perfect place to hide behind for malicious servers. Nobody get's to know their IP-address, and nobody blocks CDN IP-addresses because that would cause a lof of false positives. By continuously rotating domain names, blocking them (only *AFTER* they were found to be malicious by someone with "blocking power", which may take a lot of time) is mostly pointless (and leads to extremely long block lists).
• When you read this text, it may be proxied by a Fastly server in the (part of the) computing centre that your ISP hired to offer their services to you (infosec.exchange uses Fastly). Fastly uses a (modified) Varnish cache that, AFAIK, is useful only for *UNencrypted* data.
That means that the Fastly server near you must have access to the same private key that all Fastly caching servers worldwide have access to. Having a private key (or access to a centrally stored one) accessible from *a large number* of servers *worldwide*, including countries with non-democratical regimed, DOES pose a huge security risk.
And that risk further increases if the same key pair is used for multiple years (Fastly uses more than one key pair for over four years). Note: I'm not very worried about my infosec.exchange account; I don't toot secrets. The biggest risk is account takeover by a malicious AitM. Be *very* suspicious if you observe "me" writing things that sound weird (such as cryptocoin ads).
• With multiple unrelated domain names per certificate, AND the fact that the same key pair is used in *many* such certificates, means that it's *NOT TLS* that warants that your browser eventually communicates with the intended server, but some proprietary "switch" protocol used by Fastly. We have no idea what the chances are that your browser is communicating with (or leaking data to) another server ALSO "behind" Fastly.
• Last but not least: it *SHOULD* be impossible for a cloud provider -and a CDN in particular- to obtain a USEFUL certificate (that includes reliable information describing the *real life* identity of the owner of the "webserver") - because it is SOMEBODY ELSE'S website.
IMO exactly THAT is why Google, Cloudflare, and all other big tech, say that anything but DV-certs sucks *AND* why most browsers have removed the ability for users to inspect certificates, or even to see _which type_ of cert is being used (DV, OV, EV or QWAC).
This system exists because it is in THEIR (big tech) interest - and, "of course", their shareholders. It is NOT in your interest, not mine and not of any other internet user. Big tech even FACILITATES cybercrime; resulting in larger profits - that will only increase. While WE pay that bill - with actual money and with our privacy. Lack of privacy implies increased risks - not for those who invade it.
Achter Cloudflare
Géén E2EE
CDN's
DDoS-aanvallen
Nadelen
Nee, niet *u*
Men In Black
Knip
Certificaten en foutmeldingen
MitM
De tweede verbinding?
AitM
Trump
DV-certs
Nepwebsites
