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

[Scott Schmit <[e-mail]>]

On Fri, Mar 04, 2016 at 10:29:25AM +0000, Lukas RUETZ wrote:
> 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).

When I first use a captive portal and attempt to connect to
https://mail.example/ and then I get a TLS error from my client, it
doesn't really matter if the error is that the server certificate says
"mail.example" but has an untrusted CA or if it says
"captive-portal.example" instead.  Either way, the captive portal has
intercepted my traffic at an IP & TCP level and responded to it as
though I had intended to talk directly to it.

That's a MITM.

In a perfect world, we'd say that it's blatantly obvious that
"mail.example" doesn't match "captive-portal.example" so anyone can tell
what's going on.  Unfortunately, even without a captive portal, I still
get the occasional certificate mismatch error going to foo.example
because I get a certificate for baz.akamai.net instead...which I
typically click through because I figure that they misconfigured the
akamai node to not include foo.example in their SAN list.

> ------------------------------------------------------------------------------
> 
>    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".

> ------------------------------------------------------------------------------
> 
>    o  *Connectivity Interruption* - For a device with multiple network
>       interfaces (e.g., cellular and WiFi), connecting to a network can
>       require dropping access to alternative network interfaces.  If
>       such a device connects to a network with a captive portal, it
>       loses network connectivity until the captive portal requirements
>       are satisfied.
> 
> (We see an even more complicated version of it - devices with multiple
> interfaces sometimes switch back from WiFi to 3G/4G because the
> "online check" of the device reports that the device is offline. This
> leads to the problem that users with data plans at the location of the
> CP (like a hotel in the same country) have problems to get to the
> login page of the CP or have to try a few times.)

Worse, if the device abandons WiFi to use the data plan, the user may be
incurring significant charges (e.g., because they're in a foreign
country).

> ==============================================================================
> 
> 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?

-- 
Scott Schmit