W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Proposal: Marking HTTP As Non-Secure

From: Chris Palmer <palmer@google.com>
Date: Tue, 16 Dec 2014 12:10:42 -0800
Message-ID: <CAOuvq237TV+W4eFj29Kzx19rX83WwNx--Lb_753bYk4d3vr=-Q@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC