5 ms·

> 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

by _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.
  - tptacek 10y ago
    How does the browser tell the difference between your personal self-signed certificate for a domain where the difference between HTTP and HTTPS doesn't matter, and the case where an attacker substitutes a self-signed certificate for WWW.BANKOFAMERICA.COM?
    - 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 _pmf_ 10y ago

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.
- tptacek 10y ago
  How does the browser tell the difference between your personal self-signed certificate for a domain where the difference between HTTP and HTTPS doesn't matter, and the case where an attacker substitutes a self-signed certificate for WWW.BANKOFAMERICA.COM?
  - 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 :)