Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

On 22-Dec-14 13:05, Anne van Kesteren wrote:
> On Wed, Dec 17, 2014 at 6:50 PM, Sigbjørn Vik <> wrote:
>>> What would happen exactly when
>>> you visit e.g. from the airport (connected to something
>>> with a shitty captive portal)?
>> Assuming interstitials were replaced with cache separation:
>> The browser would detect that this isn't the same secure google you
>> talked to yesterday, and not share any data you got from google
>> yesterday with the captive portal. Once you reconnect to the authentic
>> google, the browser would use the first set of data again.
> How would the user distinguish this case from cookies expiring,
> getting lost for some reason,

A big fat warning against an active attack, possibly similar to existing
interstitials for insecure certificates. After the warning has been
dismissed, there would still be a "site insecure" warning in the address

> or the monthly two-factor authentication
> dance? This sounds very dangerous.

Asking for user input, for a user who doesn't check the address bar is
dangerous, regardless of interstitials or not; e.g. https stripping, URL
spoofing or phishing.

However, what you describe is a very different scenario from a regular
self-signed certificate. You describe an active attack, where a
previously good certificate is being replaced by an invalid one. In such
cases, warning the user is still good - after all, the browser has
positive evidence that someone is tampering with the connection.
However, even if warning the user, the browser shouldn't share network
credentials with the impostor afterwards.

My point is that is no less safe than Forcing the user to interact with confusing
dialogs every time he goes to the https version makes users ignore such
dialogs (or makes users and webmasters prefer http). Or if a site has
used a certificate for two years, and it has now expired by one day,
that doesn't indicate that someone is out to get you. In these cases,
just load the page without forcing the user to click through dialogs,
but do display that the connection is insecure - the same way http is
insecure. Reserve the big fat warnings for cases where the browser can
actually detect that an attack is going on (as in your example) - and
even in those cases, do protect the user.

> What if uses certificate pinning?

Certificate pinning or HSTS are designed to hard-fail on insecure
connections. Improving that UI is a fight for another day ;)

Sigbjørn Vik
Opera Software

Received on Monday, 22 December 2014 12:51:34 UTC