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

Re: Proposal: Marking HTTP As Non-Secure

From: Adrienne Porter Felt <felt@google.com>
Date: Wed, 17 Dec 2014 08:22:34 -0800
Message-ID: <CAFE8Ch6Kbw5yV3z5q_OETF6uDVRp6+6uitnqkJRUao0sXv+FsA@mail.gmail.com>
To: Sigbjørn Vik <sigbjorn@opera.com>
Cc: tylerl@google.com, blink-dev <blink-dev@chromium.org>, Chris Palmer <palmer@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>, dev-security@lists.mozilla.org
We plan to continue treating B and C differently. If there is a validation
failure (C), Chrome will show a full-page interstitial. That will not be
the case for HTTP (B). They will look the same in the URL bar because they
are both insecure but the overall experience will be quite different.

On Wed, Dec 17, 2014 at 3:52 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:
>
> On 17-Dec-14 08:48, tylerl@google.com wrote:
>
> > Given these roughly 3 distinct scenarios with respect to connection
> status:
> >
> > A: The connection is successfully secured. (HTTPS)
> > B: No security was attempted. (HTTP)
> > C: Securing the connection has failed. (Certificate validation failure)
> >
> > A few people have said that B and C are roughly identical from a
> > security perspective and could be represented as the same state -- in
> > both cases no security is provided. I would disagree here. In the case
> > of the failed certificate verification, the client has attempted to
> > secure the connection and that attempt has failed. In the case of HTTP,
> > the client made no indication of a preference for security. While
> > scenario B represents the *absence* of security, scenario C represents
> > the *failure* of security, and is therefore more troublesome. While we
> > want to raise the awareness of scenario B, we shouldn't promote it to
> > the severity of scenario C. Doing so conflates two very different cases
> > and failure modes; while both represent the absence of verifiable
> > transport security, the latter indicates that the user's expressed
> > expectation of security has not been met, while the former simply
> > reflects the absence of any expectation of security.
>
> I respectfully, but strongly, disagree :) If you want to separate the
> states, I'd say that C is better than B. C has *some* security, B has
> *none*. Consider a self-signed certificate, where the site owner chooses
> to provide what little security he can, this is still much better than
> plain old http. Or a certificate expired by one day, which is the same
> certificate that the browser has seen on that site for the 2 years past,
> this is still way better than B.
>
> If a malicious actor can get write access to a page with status C, he
> can immediately change the security level to status B anyway. Redirect
> the page to http://official-looking.subdomain-facebook.com, and present
> B, so displaying B as better doesn't help users much against attacks. If
> a malicious actor does not have write access to a page with status C,
> then status C is already better than status B. If the browser can detect
> an active attack (like the login form having moved to http from https or
> replacement of a good certificate by a bad one) then the browser should
> of course warn against the attack, but that is a different scenario.
>
> In most cases, users type 'facebook.com', and give no preference for
> security. Any such preference is a server preference. The same holds for
> clicking links, the user has no expectation of where he will be taken.
> For bookmarks, or cases where the user explicitly types 'https://', the
> user might have an expectation of security. If he does, and the security
> level of the page indicates either B or C, he should immediately be
> alerted anyway. If you think this indicates an explicit preference for
> security, then the browser could warn similar to an active attack in
> these cases.
>
> But my main point against this is still that you need an entire
> paragraph to explain the difference, to people who already know the
> background. A user wants to know if he is secure or not, not if his
> 'facebook.com' request was intercepted on the way and replaced by a http
> MiTM (status B, really bad), or if 'facebook.com' made a bug leaving you
> exposed (status C, pretty bad). Most users wouldn't understand the
> difference. I consider it arrogant trying to force users to understand
> the difference, most users just want to go to facebook, not get a
> lecture on internet safety. I consider it harmful to try to display the
> difference, as the more states we have in the UI, the more users have to
> learn, which means they will remember less, and the states become less
> meaningful. Keep it simple, and keep to user expectations, not
> implementation details.
>
> As a consumer buying bread, you want to know if the bread is safe to eat
> or not. Whether the farmer tried to control pesticide usage and failed,
> or he didn't try to control it, makes little difference. Professional
> health and safety inspectors (akin to browser and web developers) are
> about the only ones who care.
>
> > I've
> > received many reports from operators large and small indicating
> > visible
> > losses of revenue due to the nearly-hidden warning Chrome currently
> > displays for a SHA-1 cert with a long expiration.
>
> Are you able to share more details on this?
>
> --
> Sigbjørn Vik
> Opera Software
>
Received on Wednesday, 17 December 2014 16:23:01 UTC

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