Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-00

[Lukas RUETZ <l.ruetz@asteas.com>]

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