Re: Proposal: Marking HTTP As Non-Secure

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 11:53:28 UTC