5 ms·

On one hand, Troy is right: absolutism can hurt security, and a partially encrypted connection (e.g. CloudFlare's "flexible" version) is better than a wholly un

by phlo 10y ago

On one hand, Troy is right: absolutism can hurt security, and a partially encrypted connection (e.g. CloudFlare's "flexible" version) is better than a wholly unencrypted one. On the other hand, opportunistic encryption as described can also be misleading and dangerous. Yes, most attackers will have a harder time achieving MITM between CloudFlare and your EC2 hosts than an unsecured Starbucks Wifi, but the possibility remains. And in the case of the non-"(strict)" versions, there is no way for the user to tell that the data was not encrypted. The security community has spent a lot of (well-placed) effort training users to look for the padlock symbol before trusting a website. CF's opportunistic encryption undermindes that. Files can be served over insecure HTTP to CloudFlare, and even a competent end-user will have no way to tell. As Troy mentioned, Let's Encrypt and CF's Origin CA are steps in the right direction. Trust On First Use could be another one, allowing for a partial departure from the CA model. In any case: opportunistic encryption is a big improvement over no encryption at all -- but it should be clearly recognizable as such, and must not be confused with identity verification.

saurik 10y ago
A CDN is effectively part of the developer's infrastructure. One could also take data from their endpoint and publish it on a public log somewhere with the compete traffic dump. The green lock can only tell you that your connection from your network to some endpoint not on your network is encrypted, not that the connection is secure; trying to force CloudFront to display "past this point things are less secure" will, if anything, train users to believe the lock means something it can't ever mean: that your data is secure in general, as opposed to just being secure on your network. If the developer has another proxy (maybe nginx) behind CloudFront managing connections to an application server over HTTP, should that also send this header? If the web application is using an unencrypted database backend connection, should common web frameworks start returning that header? At what point do we start only giving websites green lock icons when they pass an independent security audit? We need to be downplaying the overall importance of the green lock icon, not reinforcing it: users already think it means way way more than it ever could (specially, "it is safe to give my credit card number to this website", which is almost totally unrelated to what the lock icon is for :/).
- 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 ago
    From 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.
_pmf_ 10y ago
> Trust On First Use could be another one, allowing for a partial departure from the CA model. Any step away from the horrible "HTTP is fine, but god help you if using a custom certificate" scaremongering currently implemented by browsers is good to me. I absolutely cannot understand this: if is's a trusted, non expired certificate, show it as green. If not, there's nothing more insecure about it than using plain HTTP; should we display huge scary warnings for plain HTTP, too?
- acdha 10y ago
  That's been in progress for the last couple years. They've been making certain features like geolocation only available to secure origins and the browser UI is changing: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure https://www.chromium.org/Home/chromium-security/marking-http...
- regecks 10y ago
  Opportunistic encryption in HTTPS was meant to address this, but I think there were problems.
- tptacek 10y ago
  What's a "custom certificate"? A self-signed certificate provides no security: any MITM could simply substitute their own.
  - phlo 10y ago
    A self-signed certificate provides the same (or slightly better) security as an HTTP connection, but browsers treat them differently. They sternly warn against the former and silently ignore the latter. I agree with the parent post: both cases should trigger a non-intrusive indication of non-security, e.g. a broken padlock. Scary warnings are in order if a site was previously using a trusted cert and has either stopped doing so, or changed its (untrusted) public key. Trusted certs are a sensible way for a trusted level above that. They should be supplemented with HPKP as well, and scary warnings if the secure cert disappears.

by phlo 10y ago

saurik 10y ago

A CDN is effectively part of the developer's infrastructure. One could also take data from their endpoint and publish it on a public log somewhere with the compete traffic dump. The green lock can only tell you that your connection from your network to some endpoint not on your network is encrypted, not that the connection is secure; trying to force CloudFront to display "past this point things are less secure" will, if anything, train users to believe the lock means something it can't ever mean: that your data is secure in general, as opposed to just being secure on your network. If the developer has another proxy (maybe nginx) behind CloudFront managing connections to an application server over HTTP, should that also send this header? If the web application is using an unencrypted database backend connection, should common web frameworks start returning that header? At what point do we start only giving websites green lock icons when they pass an independent security audit? We need to be downplaying the overall importance of the green lock icon, not reinforcing it: users already think it means way way more than it ever could (specially, "it is safe to give my credit card number to this website", which is almost totally unrelated to what the lock icon is for :/).

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 ago
  From 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.

_pmf_ 10y ago

> Trust On First Use could be another one, allowing for a partial departure from the CA model. Any step away from the horrible "HTTP is fine, but god help you if using a custom certificate" scaremongering currently implemented by browsers is good to me. I absolutely cannot understand this: if is's a trusted, non expired certificate, show it as green. If not, there's nothing more insecure about it than using plain HTTP; should we display huge scary warnings for plain HTTP, too?

acdha 10y ago
That's been in progress for the last couple years. They've been making certain features like geolocation only available to secure origins and the browser UI is changing: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure https://www.chromium.org/Home/chromium-security/marking-http...
regecks 10y ago
Opportunistic encryption in HTTPS was meant to address this, but I think there were problems.
tptacek 10y ago
What's a "custom certificate"? A self-signed certificate provides no security: any MITM could simply substitute their own.
- phlo 10y ago
  A self-signed certificate provides the same (or slightly better) security as an HTTP connection, but browsers treat them differently. They sternly warn against the former and silently ignore the latter. I agree with the parent post: both cases should trigger a non-intrusive indication of non-security, e.g. a broken padlock. Scary warnings are in order if a site was previously using a trusted cert and has either stopped doing so, or changed its (untrusted) public key. Trusted certs are a sensible way for a trusted level above that. They should be supplemented with HPKP as well, and scary warnings if the secure cert disappears.