7 ms·
> A CDN is effectively part of the developer's infrastructure. Agree. If the CDN is compromised, all bets are off. In my opinion, CloudFlare Flex/Full are a lo
by phlo 10y ago
> A CDN is effectively part of the developer's infrastructure.
Agree. If the CDN is compromised, all bets are off. In my opinion, CloudFlare Flex/Full are a lot more vulnerable to attack (because the resources can be obtained insecurely over the public internet) than others (where TLS is either terminated at the network boundary and encryption is only lacking thereafter, or where resources are pushed through secure connections over the Internet).
> as opposed to just being secure on your network.
I'm not sure it is a reasonable thing to ask end-users to understand how many networks are involved in serving their content. I also don't think the situation would benefit from CloudFlare (or any other proxy) announcing which parts of the connection they encrypt. Instead, I think CloudFlare should be more strict in their origin connectivity: only accept encrypted data, and if the origin certificate is not a CA-issued one, Trust on First Use and ask the site admin to verify updated certs. CF is also in an excellent position to adopt a perspectives [1]-like approach, if an MITM is suspected.
[1] https://perspectives-project.org https://perspectives-project.org
- ethbro 10y agoFrom a UI perspective the green lock is largely binary: either a site or connection has it or doesn't. Overloading it to mean something less than client to source is disingenuous and how we ended up with the infamous NSA Google unencrypted back-haul slide. 10 years ago one might have been able to make a "good enough" attempt argument, but nowadays I don't see how one can't include a nation-state backbone adversary in ones encryption calculus.