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

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

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Thu, 18 Dec 2014 11:00:47 -0500
Message-ID: <5492FA2F.2020505@fifthhorseman.net>
To: chaals@yandex-team.ru, "softwaredevjirka@gmail.com" <softwaredevjirka@gmail.com>, "blink-dev@chromium.org" <blink-dev@chromium.org>
CC: "annevk@annevk.nl" <annevk@annevk.nl>, "sigbjorn@opera.com" <sigbjorn@opera.com>, "tylerl@google.com" <tylerl@google.com>, "palmer@google.com" <palmer@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "security-dev@chromium.org" <security-dev@chromium.org>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>
On 12/18/2014 04:07 AM, chaals@yandex-team.ru wrote:
> There is a certificate error. The point is that since it is expected behaviour, 
> I get trained to say "yeah, whatever" so I can pay for the connection I need. 
> Despite the fact that it is very difficult to be *sure* that the error is not 
> actually a real problem.
> I'd love to see a better situation relying on a proper standard.
> But in general I don't.

This is the closest thing to a standard for dealing with this situation
that i know of:


Until this mechanism is deployed, when you believe that you will be on
such a network, and you are willing to expose yourself to their
middlebox devices, you should *not* accept the bogus cert.  Accepting
the bogus cert potentially means sending the middlebox the cookies that
you would have sent to the desired origin, which is a Bad Thing.

Instead, you should open a new browser window and point it at
http://www.example.org/, which does not use https, and so can be
rewritten/hijacked by the captive portal situation however they like.

This is a clunky mess, of course, but that's the nature of captive portals.


Received on Thursday, 18 December 2014 16:01:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC