3 ms·

It clearly doesn't and probably won't, for the forseeable future. I'm arguing for the browser to have the same behavior for all insecure connections, be they H

by phlo 10y ago

It clearly doesn't and probably won't, for the forseeable future. I'm arguing for the browser to have the same behavior for all insecure connections, be they HTTP or HTTPS on a self-signed cert. There clearly shouldn't be an indication of "security" (these should continue to be reserved for the CA-issued and particularly EV certs), but I agree with GP in that there shouldn't be a scary warning message either. The scary warnings have their place: if a page that was previously secure (i.e. CA-signed cert) stops being so (either because it is now being served over HTTP [potentially sslstripped], or because it now uses a self-signed cert), then a warning should be issued. Finally, we already have HSTS preload lists to bridge the gap before first access. If a site is on one of these and served insecurely, a scary warning is appropriate as well.

tptacek 10y ago
You're not following. If browsers adopted the behavior you're suggesting they did, any attacker could quietly turn off SSL for any site. If you propose to generate that warning only for sites that are supposed to have CA-signed certificates, you have to explain how the browser tells the difference between those sites and your own legitimately self-signed site. That's why self-signed certificates generate warnings even though HTTP connections don't. Just get a real certificate, or have your users add your certificate to the trust store manually.
- phlo 10y ago
  Again, I'm suggesting browsers should continue to display a warning if a site that was previously served over an authenticated connection stops being served over an authenticated connection. In this case, an attacker could only turn off SSL if a site has never been encountered before. High-value sites are included in HSTS lists already, so this gap can be bridged. Right now, attackers can quitely turn off SSL for most sites if they just strip it from the connection; requesting over HTTPS and re-serving over HTTP. The majority of users types "example.org" into their address bar, not "https://example.com" https://example.com". Most users won't notice, especially not if the favicon is replaced with a fake green padlock. > Just get a real certificate, or have your users add your certificate to the trust store manually. Yep. Given the availability of Let's Encrypt (and others), the discussion is mostly moot anways :)

by phlo 10y ago

tptacek 10y ago

You're not following. If browsers adopted the behavior you're suggesting they did, any attacker could quietly turn off SSL for any site. If you propose to generate that warning only for sites that are supposed to have CA-signed certificates, you have to explain how the browser tells the difference between those sites and your own legitimately self-signed site. That's why self-signed certificates generate warnings even though HTTP connections don't. Just get a real certificate, or have your users add your certificate to the trust store manually.

phlo 10y ago
Again, I'm suggesting browsers should continue to display a warning if a site that was previously served over an authenticated connection stops being served over an authenticated connection. In this case, an attacker could only turn off SSL if a site has never been encountered before. High-value sites are included in HSTS lists already, so this gap can be bridged. Right now, attackers can quitely turn off SSL for most sites if they just strip it from the connection; requesting over HTTPS and re-serving over HTTP. The majority of users types "example.org" into their address bar, not "https://example.com" https://example.com". Most users won't notice, especially not if the favicon is replaced with a fake green padlock. > Just get a real certificate, or have your users add your certificate to the trust store manually. Yep. Given the availability of Let's Encrypt (and others), the discussion is mostly moot anways :)