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

[Lukas RUETZ <[e-mail]>]

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