Re: Proposal: Marking HTTP As Non-Secure

On 17-Dec-14 17:22, 'Adrienne Porter Felt' via Security-dev wrote:
> 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.

Looking the same in the URL bar is already a good improvement on today.
However, the interstitial will continue to provide a negative incentive
to webmasters to attempt to apply security, as if they get it wrong,
users get a worse experience. Going for http might just be the safer
choice. The interstitial thus has the opposite effect of what this
proposal aims to achieve.

In an ideal world, where there were no technical reasons for the
interstitial (meaning the browser wouldn't leak cookies or other data
and the user would be at least as secure as when using http), would you
still want to show it to users? And if so why?


> On Wed, Dec 17, 2014 at 3:52 AM, Sigbjørn Vik <sigbjorn@opera.com
> <mailto:sigbjorn@opera.com>> wrote:
> 
>     On 17-Dec-14 08:48, tylerl@google.com <mailto: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 <http://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 <http://facebook.com>' request was intercepted on the
>     way and replaced by a http
>     MiTM (status B, really bad), or if 'facebook.com
>     <http://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
> 
> To unsubscribe from this group and stop receiving emails from it, send
> an email to security-dev+unsubscribe@chromium.org
> <mailto:security-dev+unsubscribe@chromium.org>.


-- 
Sigbjørn Vik
Opera Software

Received on Wednesday, 17 December 2014 16:38:06 UTC