[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 13/06/13 22:37, Simon Waters wrote: > 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. > Is the "radius stuff" you mention WISPr by any chance? http://en.wikipedia.org/wiki/WISPr Think you're mostly right about the DHCP 'solution' probably being the way forward, but although I see mention of security measures like reply attack prevention in RFC3118 I'm still really struggling to think how authentication is going to work securely (properly, that is: I can see a hell of a lot of ways to royally screw it up). Even distributing certs in advance, as they're obviously going to have to do, is going to ultimately fall to the same issues which make vendor included SSL certs vulnerable/untrustworthy. Regards -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq