- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Wed, 17 Dec 2014 18:50:22 +0100
- 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