Re: [Repo-criteria-discuss] HSTS screw?

[Hanno Böck]

On Mon, 10 Oct 2016 21:44:19 -0400
Richard Stallman <address@hidden> wrote:

> I cannot use my preferred browser to connect to a WiFi portal in the
> best way any more.  Portals generally require the user to specify some
> site to visit.  The best choice is wikipedia, a site that does nothing
> nasty and that lots of people use.
> 
> But now the browser forces https when I connect to Wikipedia.  (Is
> this HSTS at work?)  That typically fails totally because the portal
> does not handle https at all.

Yes, this is HSTS.
The problem here is that Captive Portals are just an ugly hack that's
essentially exploiting a weakness of HTTP - that a network-level
attacker can mess with the content.

> Do you have a solution for this?

You have to access a page that is HTTP and will likely not go HSTS any
time soon.
Several people have suggested using example.com or example.org for
this, but as far as I know it's nowhere state officially that these
will stay HTTP only forever. There's also httpforever.com, but I don't
know who operates it.
Browser and OS vendors sometimes have their own pages to detect captive
portals. But you're up to relying on a vendor who might decide to
enable HSTS at some point in the future. E.g. apple uses
captive.apple.com. (Ideally this shouldn't be run on a subdomain,
because HSTS can include subdomains.)

Ideally someone would create a page designed just for this use case
that pledges to never disable HTTP support or enable HSTS and
preferrably not store any user data. Then OS vendors and browsers could
also use this to automate captive portal detection.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: address@hidden
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

pgpOKL99rLhBG.pgp
Description: OpenPGP digital signature