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

From: Lukas RUETZ <[email-masked]>
Date: Fri, 4 Mar 2016 10:29:25 +0000

Hi everyone,

we found some time now to think about the current draft. Please find some minor additions
and some discussion below:

==============================================================================

2.  Defining Captive Portals
   This is achieved by directing requests for "normal" Web access to the
   nominated server, through variety of techniques, including DNS
   poisoning, TCP interception, and/or HTTP redirection.

You could add "ARP spoofing" here too.

------------------------------------------------------------------------------

2.1.  Why Captive Portals Are Used

This may be added as separate point to the list:

*Collect user data* - Some CP operators want to collect user data in exchange
for free internet (email addresses, time/location information, ...).

==============================================================================

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.
Maybe there are other CPs out there which are doing that. I'm only aware of big
firewalls that are able to break up TLS, but of course they have their CA installed
on the clients and (hopefully) their employees informed.

------------------------------------------------------------------------------

   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.

------------------------------------------------------------------------------

   o  *Non-Browser Clients* - It is becoming more common for Internet
      devices without the ability to run a browser to be used, thanks to
      the "Internet of Things."  These devices cannot easily use most
      networks that interpose a captive portal.

To get such devices online they are often whitelisted on the CP with their MAC address
what opens up an uncontrolled hole in the CP.

(Examples usages: different kind of internet radio players, printers, network-devices
(due to bad network design))

------------------------------------------------------------------------------

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

------------------------------------------------------------------------------

You may consider to add another point to 3. - because it's not specific to CPs I'm not sure if
you want to add that:

    *NAT* - (Network Address Translation) Because most of the CPs are masquerading the
    client traffic, they also inherit all kind of problems known to NAT. Most notably
    VPNs that can't be masqueraded like some IPSec based VPNs.

Another point would be:
    *Problematic client settings* - Some devices and/or software make certain assumptions
    or have settings that work in an unrestricted network but are actually bad/questionable practice
    and fail behind CPs. For example some clients with fixed proxy settings have problems
    to establish connections. Intranet applications doing unknown tests to find out if they
    are on the intranet. Mobile apps that flood the CP as soon as the WiFi interface is up,
    not waiting after a connection reset.

(We have a long list of examples - not sure how concrete/general the statement should be)

==============================================================================

5.  Security Considerations

The current situation for our customers looks usually like this. The clients are
connecting via unencrypted WiFi to the CP.

* WPA(2) with a pre-shared key is almost never used because
    - it does not add real security if everyone who asks gets the pre-shared key
    - especially CP operators (I'm talking about hotels here) don't want the guest to ask anything - it should just work
    - it's another step that many users would not be able to deal with

* Although 802.1x would be possible too (different credentials per user, one login) it's not very widespread because
    - most CP operators (often without inhouse IT staff) find it too complex to setup/operate
    - it's incompatible with many access methods like a login via social platforms

Many CP operators are moving from username+password to password only, because the error-rate
of mistyped credentials on mobile devices is quite high. So nobody wants to add another password (for WiFi).

Security considerations for the client using a CP:
One could argue that the client is always in a risky situation when connecting via a CP. But the risk is actually not
different than by connecting over any other network device like routers or firewalls.

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.

Looking forward to your comments,
Lukas

--
  Lukas RUETZ
  www.iacbox.com

---

From: Scott Schmit <[email-masked]>
Date: Fri, 4 Mar 2016 09:33:07 -0500

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

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

> (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).

> 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

---

From: Lukas RUETZ <[email-masked]>
Date: Fri, 4 Mar 2016 15:43:40 +0000

Hey Scott,

thanks for your comments - I'm answering inline

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

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

> The important question is why don't CPs (or OSs) use RFC 7710 now?  Or

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