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

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

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Wed, 17 Dec 2014 18:50:22 +0100
Message-ID: <5491C25E.1020901@opera.com>
To: Anne van Kesteren <annevk@annevk.nl>
CC: tylerl@google.com, blink-dev <blink-dev@chromium.org>, Chris Palmer <palmer@google.com>, WebAppSec WG <public-webappsec@w3.org>, security-dev@chromium.org, dev-security@lists.mozilla.org
On 17-Dec-14 18:17, Anne van Kesteren wrote:
> On Wed, Dec 17, 2014 at 12:52 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:
>> 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*.
> 
> You would advocate not blocking on certificate failures
> and just hand
> over credentials to network attackers?

My comment above is about the relative security of http versus
non-perfect https. In most cases, non-perfect https is better. In some
cases, they are equally bad.[*]

Another topic is how to deal with broken https. Browsers today present
the user with an interstitial designed to allow him to shoot himself in
the foot, after which they leak any cached secure data to the broken
site. I consider that leakage a bug.

> What would happen exactly when
> you visit e.g. google.com 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.

-- 
Sigbjørn Vik
Opera Software
Received on Wednesday, 17 December 2014 17:50:56 UTC

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