Hey Scott, thanks for your comments - I'm answering inline
> > 3. Issues Caused by Captive Portals > > > > o *Confusion* - Because captive portals are effectively a man-in- > > the-middle attack, they can confuse users as well as user agents > > (e.g., caches). For example, when the portal's TLS certificate > > doesn't match that of the requested site, or the captive portal's > > /favicon.ico gets used as that of the originally requested site. > > > > I would not call it man-in-the-middle "attack" - it's more a MITM > > "constellation". The sent and expected certificate are different, but > > not forged. If the CP would send a fake certificate for example.com > > that would be a real MITM attack. > > I disagree. A MITM attack occurs when Alice sends traffic to Bob, but > Mallory replies in Bob's place and makes some effort to speak as though > Mallory is Bob. > > What you're quibbling about is the quality of the impersonation (and > maybe a lack of malicious intent). Because a CP does not/should not have this malicious intent, I wasn't happy with the word "attack". Of course the client can't see the difference. > > ------------------------------------------------------------------------------ > > > > o *TLS* - Portals that attempt to intercept TLS sessions (HTTPS, > > IMAPS, or other) can cause certificate error messages on clients, > > encouraging bad practice to click through such errors. > > > > You may consider adding something like: > > This bad practice is now avoided by many web sites that are sending an > > HSTS HTTP header, in which case the user can't add an exception for > > that certifcate if the browser was on the wanted page before. Same for > > HPKP headers. The user is stuck until s/he opens an http:// URL. > > For now. I'm imagining a dark world where most of the web has migrated > to HTTPS & browsers do HTTPS with HSTS/HPKP by default but captive > portals stubbornly continue to try to MITM the connections, so users > complain to browsers that they can't click through the errors to satisfy > the captive portal and let them get to the real site...and the *browsers* > relent. :-/ > > Also, it doesn't help anything if users attempt to connect to the HTTP version > of the site instead -- that's just as much of a "click through". With the addition I tried to make clear in the document what happens if HSTS and HPKP are used, nothing else. Calling an http:// URL is the only working way at the moment to get a valid redirect until there is a real solution to this. Sadly people don't read, so the URL to the login-page printed on the tickets is almost never used. QR-Codes already helped a bit, but only a few users have QR-code readers installed. > > ============================================================================== > > > > 5. Security Considerations > > > > We think regarding security the most important point is not to mess > > with TLS connections. If we can get rid of this redirect-to-login > > situation this would increase the security of end-users a lot because > > they don't "lear" to click through certificate warnings. RFC-7710 > > would be a first important step. > > I don't want CPs to just stop messing with TLS connections, because MITM > of unsecured traffic isn't really any better, it's just less visible > to software that something is wrong. > > I think the ideal future state is that: > > CPs don't falsify or redirect *ANY* traffic. DNS reports honest > answers, with DNSSEC if requested. ARP/IPv6-ND is answered honestly. > IP traffic to anything but the CP login server is blackholed (not > redirected) until the login server has whitelisted the user. > > Then, once the user is whitelisted, all the information previously > learned is still valid (no cache flushes required) and the user can go > on with life until their session with the login server times out (if > ever). > > I too think RFC 7710 is a sensible first step, and then it looks like > capport's job is to come up with protocols/mechanisms for software to > discover connectivity status, time remaining, access limitations. > > Maybe the way we get captive portals to start stepping in this direction > is to give the client some way of reporting "I understand RFC 7710 > (etc), so if you just level with me, I'll make this easy for both of us > to get what we want and move on."? In response, the CP would rely on > RFC 7710 (etc) and disable all the hacks used to funnel users to the > login server. > > The important question is why don't CPs (or OSs) use RFC 7710 now? Or > are they? Well we completely agree in this point - it just sounds a bit like you think CPs are doing this for fun. Most of this hacks are made to get the user to the login-page. We hope that this WG pushes things further. And by the way ... we ship RFC-7710 since this year, but AFAIK no device supports it. We're waiting for the OS vendors to implement it. BR Lukas -- Lukas RUETZ www.iacbox.com _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
