- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Mon, 22 Dec 2014 13:51:07 +0100
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Tyler Larson <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 22-Dec-14 13:05, Anne van Kesteren wrote: > On Wed, Dec 17, 2014 at 6:50 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote: >>> 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. > > 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 bar. > 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 https://www.pcwebshop.co.uk is no less safe than http://www.pcwebshop.co.uk. 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 google.com 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