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

Header Data

From: José Borges <jo***s@algardata.pt>
Message Hash: e2cf5c5e543af05dfb762165dac4765a09016f5d864c9873fce6a0a1cfef43a8
Message ID: <0315a659-ae82-41b4-88c8-f6fc9ff958d9@grasehotspot.org>
Reply To: <CAESLx0LYjj9g_hRKoBSuM-aZXQEvWcqvewh9_Df=QPDVKp8sRg@mail.gmail.com>
UTC Datetime: 2017-03-14 02:18:32 UTC
Raw Date: Tue, 14 Mar 2017 02:18:32 -0700

Raw message 

So... it's a lost battle?

Grrrr I'm starting to hate HSTS.... And particulary Google Chrome, because 
i tried safari, firefox and they all worked well. Just Google Chrome doesnt.


segunda-feira, 13 de Março de 2017 às 21:06:16 UTC, timwhite88 escreveu:
>
> 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***.@algardata.pt 
> <javascript:>> 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***.@grasehotspot.org <javascript:>.
>> To post to this group, send email to gr***.@grasehotspot.org 
>> <javascript:>.
>> 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