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
_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals
