- From: Chris Palmer <palmer@google.com>
- Date: Tue, 16 Dec 2014 12:10:42 -0800
- To: Sigbjørn Vik <sigbjorn@opera.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>
On Tue, Dec 16, 2014 at 5:59 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote: > There is no need to distinguish unsecured from dubiously secured, they > can just go into the same bucket. There isn't even any need to warn > users about certificate errors, the UI is just downgraded to insecure, > as a self-signed site is no less secure than an http site. There are > technical reasons for the warnings, but those can be bug-fixed. Active > attacks (e.g. certificate replacement to an invalid one, HSTS failure, > revoked certificates, ...) might still be hard-blocked, but note that > this constitutes a fourth state, and the UI is becoming very complicated > already - there are probably better ways to map such cases into the > insecure state, but that is a separate discussion. Well, we do have to make sure that the browser does not send cookies to an impostor origin. That's (1 reason) why Chrome uses interstitial warnings today. We could do away with interstitials if the definition of the origin included some notion of cryptographic identity — e.g. (HTTPS, facebook.com, 443, [set of pinned keys]) instead of just (HTTPS, facebook.com, 443) — but there'd still be problems with that, and very few site operators are currently able to commit to pinning right now. (And, that might never change.) > BTW, have you explicitly contacted other browser teams? This mass mailing is that.
Received on Tuesday, 16 December 2014 20:11:15 UTC