[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 13/06/13 09:23, Gordon Henderson wrote: > > But you're right - there are no standard for captive portals, but in all > the ones I've used, I've only seen 2 ways it's accomplished - one uses > DNS to direct all web requests to an internal page and the other force > re-directs web traffic. I'm curious how this fits with the evolving Internet security landscape (HSTS and DNSSEC). Firefox doesn't play if you visit an HSTS site by the looks of it (think "www.paypal.com"). https://bugzilla.mozilla.org/show_bug.cgi?id=816866 Chrome allegedly detects such errors and assumes a captive portal and opens a different tab to be redirected to the captive portal - although this opens more opportunities for attacks - opening a new browser window with less security in response to detecting a Man in the Middle attack is what keeps security folk in business! I shall have to give it a go, and see how obvious it is what is happening, and whether it is exploitable should be interesting. DNSSEC will make DNS redirect fail on my desktop if the domain uses DNSSEC (e.g. all of ".GOV" plus quite a but more), as and when I acquire a laptop it is unlikely to be less securely configured. My Android phone - well the less said the better on that point. Presumably HTTP is better than DNS currently because people have hibernated laptops, or phones switching from the mobile network, which already have cached the correct DNS response? I noted the last time I connected to a captive portal "accidentally" (it implied it was free of charge and wasn't) it cached for a short period incorrect DNS data for Google (thanks BT subsidiary that was really helpful NOT, I have nothing better to do than reboot mobile phones). Google don't do DNSSEC widely yet, but when they do that'll fix that particular problem on some of my devices. Clearly the DHCP standard needs modification to flag captive portal, rather than different vendors hacking in different methods at unrelated layers above, which sounds like a recipe for ever more broken service. Unlikely to be an original idea that... So a google gave this... http://revk.www.me.uk/2012/12/damn-wifi-captive-portals.html There is a load of Radius stuff for this sort of stuff, but it seems to be concerned with the wrong layer (e.g. authorising DHCP when people have connected their modem over a serial link and authenticated correctly, not quite the WIFI scenario). The DHCP "welcome" attribute makes sense, in that when you connect to a captive portal you can offer authentication immediately rather than silently failing automated Internet requests (such as checks by the phone which typically go on silently in the background). Also might allow vendors to identify themselves, to simplify automated sign-on (another bugbear of such systems). Surely someone has done this already? If you decide to write the RFC please mandate a suitably secure mechanism for the authentication server, and for vendors identifying themselves to clients for automatic login. RFC3118 lays the ground work but solves a problem of less interest to most users if I read it right. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq