2017-03-13 - Re: [GRASE-Hotspot] Tackle http://www.google.com to https://www.google.com…

Header Data

From: Timothy White <ti***8@gmail.com>
Message Hash: 4a9b6675a6176e2363071cb44d0dbce23fd438e07c587c2f1db3cc2cc6231405
Message ID: <CAESLx0LYjj9g_hRKoBSuM-aZXQEvWcqvewh9_Df=QPDVKp8sRg@mail.gmail.com>
Reply To: <168073db-3cc9-49c5-b86f-d82296bbe3fa@grasehotspot.org>
UTC Datetime: 2017-03-13 14:06:14 UTC
Raw Date: Tue, 14 Mar 2017 07:06:14 +1000

Raw message 

Hi José

The issue isn't a DNS issue. Any HTTP request, to any IP address, is
intercepted by the captive portal. We can't intercept HTTPS requests, as
the user will get a certificate error.
The reason why users have issues with things like Google, is that they use
HSTS (https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). This
basically means that when you first go to a site on HTTP and get redirected
to HTTPS, you get a special cookie that says "Always come to me on HTTPS".
>From then on, if you attempt to go to the non HTTPS version in your
browser, your browser will automatically use the HTTPS version, bypassing
the captive portal.
In particular, browsers things like Chrome have what is called Static HSTS.
This is a preloaded list of sites that have HTTPS even before you go to
them the first time. (Oddly enough, google.com is in the static list, and
not set dynamically with a header).

If you have a browser without the HSTS preload list, then the google.com
redirect to the captive portal will work. If you have a browser with the
HSTS preload list (Chrome, Firefox, Safari I think), no hack will ever
work, because it's all happening on the client side.

The long term solution for captive portals will have to be a captive portal
detection method (which modern OS's already do). As more and more sites
move to HTTPS, it becomes harder and harder for captive portals to redirect
the user. Captive portals existed because OS's didn't provide a nice method
for logging into a "public hotspot". Now they provide better methods, the
captive portals need to ensure we do the right thing to be detected by the
OS, instead of relying on the browser doing a redirect. I try hard to
ensure I'm using all the correct captive portal detection methods, but if
you find any that I don't know about, let me know.

Regards

Tim

On Tue, Mar 14, 2017 at 12:40 AM, José Borges <jo***s@algardata.pt>
wrote:

> Is it possible to use BIND9
> <https://help.ubuntu.com/community/BIND9ServerHowto> to in some way
> "hack"/"redirect" http://www.google.com to our own UAM url?
>
>
> I have read this
> <http://www.mpipks-dresden.mpg.de/~mueller/docs/suse10.1/suselinux-manual_en/manual/sec.dns.bind.html#ex.forward>,
> but lack the linux skills to try it.
>
>
> Can anyone more linux savy try it?
>
>
>
> --
> This mailing list is for the Grase Hotspot Project http://grasehotspot.org
> ---
> You received this message because you are subscribed to the Google Groups
> "Grase Hotspot" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gr***e@grasehotspot.org.
> To post to this group, send email to gr***t@grasehotspot.org.
> Visit this group at https://groups.google.com/a/
> grasehotspot.org/group/grase-hotspot/.
> To view this discussion on the web visit https://groups.google.com/a/
> grasehotspot.org/d/msgid/grase-hotspot/168073db-3cc9-
> 49c5-b86f-d82296bbe3fa%40grasehotspot.org
> <https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/168073db-3cc9-49c5-b86f-d82296bbe3fa%40grasehotspot.org?utm_medium=email&utm_source=footer>
> .
>

Thread