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

From: David Bird <[email-masked]>
Date: Sun, 6 Mar 2016 18:03:03 -0800

Greetings,

Overall a good and much needed document! A few first round comments:

--

I find the terms "captive portal" and "portals" can be confusing in the
doc. It can mean the general feature, from the end-user-perspective, of
being hijacked and being presented a captive portal page. At times, it
means the specific hijacking mechanism within the network - the Network
Access Server (NAS), and at other times it can mean specifically the
captive portal website itself. I was hoping this doc could include some
terminology.

Maybe:

Captive Portal - The feature of forcing users to a specific captive portal
website
CP-Network - A network the employs a captive portal; integrated CP-NAS and
CP-Web (depth of integration varies)
CP-NAS - A feature of the network infrastructure that enforces a captive
portal, redirecting to CP-Web
CP-Web - A website application that authorizes users onto CP-Network

--

In Section 2,

Once the captive portal's goals (see below) are met, the network
"remembers" that the user is allowed network access, usually by MAC
address.

Maybe "Once the CP-Web's requirements (see below) are met, the user is
released from the captive state within the CP-NAS. The implementation
details and degree of integration between CP-Web, CP-NAS, and other network
services (such as DHCP, DNS, etc) will vary between CP-Networks."

--

Regarding:

*Unexpected Configuration* - Some captive portals rely upon DNS
interception to direct users to the portal; however, this doesn't
work when the user has configured their own DNS server in
preference to that provided by DHCP (e.g., 8.8.8.8).

The supporting text seems rather specific to CPs that use forged DNS...
Maybe "Some captive portals do not work with clients using unexpected
configurations, for example clients using static IP, custom DNS servers, or
HTTP proxies."

(If kept, s/doesn't work/may not work/ - the CP-NAS could override with a
DNAT to a specific DNS (not that I ever think faking DNS is a good
solution))

--

Regarding:

*Stealing Access* - because captive portals most often associate a
user with a MAC address, it is possible for an attacker to
impersonate an authenticated client (e.g., one that has paid for
Internet access).

This is an issue with Open WiFi, not necessarily with captive portals. If
you removed the Open WiFi (say the CP is being used on a secure wireless
medium), then this completely doesn't apply. While I agree this is an issue
with (especially paid) access over Open WiFi, not sure it belongs in this
doc, and securing the Open Bss shouldn't be within the scope of the WG.

--

Regarding:

*Access to Privileged Information* - Some captive portals want to
utilise external information about the user, such as social media
account logins and/or advertising tracking/targeting services.
However, because the captive portal is effectively acting as a
man-in-the-middle, providing these capabilities can put the user
at risk.

Not sure I follow this one... True that a CP might require an external
login of some kind, but if done within the walled garden and over HTTPS,
then how does the CP-Network increase exposure here? Or, is this also
talking more about Open WiFi problems?

--

Regarding:

*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
CAN lose network connectivity until the captive portal requirements
are satisfied.

I added the CAN above as not all devices will drop the existing good
connection when connecting to a network with a CP detected.

--

In section 4, it says "Detection aims to minimize the negative effects
caused by captive portals in several ways.  Captive portal detection can
cause issues in some networks; for example: .."

Suggestion: after "several ways, " list a few, or change to something like
"Detection aims to minimize the above negative effects caused by captive
portals, but can cause different issues, including: ..."

--

I don't feel we have explained the reasons for operators wanting to defeat
the CP detection in section 4.1. Perhaps in section 4, under *Sandboxing*
we can explain:

While sandboxing seems a good idea to protect user data (particularly on
Open WiFi), it is implemented differently on various platforms and often
causes a (severely) broken user experience on the operator's CP-Web site
(even when the operator is protecting user data end-to-end with HTTPS). To
offer a consistent and rich experience on the CP-Web, some operators
actively try to defeat OS CP detection.

--

If I may rant a bit... OS vendors and others doing CP detection are
conflating security issues around Open WiFi and Public Access Networks, and
the need to protect user data in such networks, with CP detection. While CP
detection is perhaps a good signal for designating a network as Public
Access, it does not inherently mean the underlying network is "insecure".
Nor does the absence of a CP in an Open WiFi network mean the underlying
network is in anyway "secure" (and therefore not Sandboxed). The reasons
for vendors being extra suspicious of CP networks is because of the
similarities with mitm attacks - which is understandable. However, as CP
networks are more common place and the mechanisms for signaling become more
formalized (thanks to this WG), vendors need to work with, not against,
operators who utilize TLS to protect user-data even in Open WiFi public
access networks, to offer a full browser CP-Web experience.

--

David

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Mar 2016 18:45:19 +1100

Hi David,

Thanks for the feedback. Some responses below, and changes at:
  https://github.com/mnot/I-D/commit/165bc6744e04380757d

> On 7 Mar 2016, at 1:03 PM, David Bird <[email-masked]> wrote:
> 
> Greetings,
> 
> I find the terms "captive portal" and "portals" can be confusing in the doc. It can mean the general feature, from the end-user-perspective, of being hijacked and being presented a captive portal page. At times, it means the specific hijacking mechanism within the network - the Network Access Server (NAS), and at other times it can mean specifically the captive portal website itself. I was hoping this doc could include some terminology. 
> 
> Maybe:
> Captive Portal - The feature of forcing users to a specific captive portal website
> CP-Network - A network the employs a captive portal; integrated CP-NAS and CP-Web (depth of integration varies)
> CP-NAS - A feature of the network infrastructure that enforces a captive portal, redirecting to CP-Web
> Maybe "Once the CP-Web's requirements (see below) are met, the user is released from the captive state within the CP-NAS. The implementation details and degree of integration between CP-Web, CP-NAS, and other network services (such as DHCP, DNS, etc) will vary between CP-Networks."

I *think* we can get away with defining just "captive portal" and "captive network" for now; see rewrite.

> The supporting text seems rather specific to CPs that use forged DNS... Maybe "Some captive portals do not work with clients using unexpected configurations, for example clients using static IP, custom DNS servers, or HTTP proxies."
> 
> (If kept, s/doesn't work/may not work/ - the CP-NAS could override with a DNAT to a specific DNS (not that I ever think faking DNS is a good solution))

Done.

> This is an issue with Open WiFi, not necessarily with captive portals. If you removed the Open WiFi (say the CP is being used on a secure wireless medium), then this completely doesn't apply. While I agree this is an issue with (especially paid) access over Open WiFi, not sure it belongs in this doc, and securing the Open Bss shouldn't be within the scope of the WG.

I've added:

"""
Note that this is specific to open Wifi, and can be prevented by using a secure wireless medium. However, configuration of secure wireless is often deemed to be too complex for captive networks.
"""

> Not sure I follow this one... True that a CP might require an external login of some kind, but if done within the walled garden and over HTTPS, then how does the CP-Network increase exposure here? Or, is this also talking more about Open WiFi problems?

I've seen CPs that ask for Facebook username and password, but NOT over HTTPS, and not to a Facebook domain (IIRC); it's more of a user education / security UX problem than anything.

Still, that's probably out of scope here (even if it is scary). I'll remove the section unless someone else wants to keep it.

> I added the CAN above as not all devices will drop the existing good connection when connecting to a network with a CP detected. 

Fixed.

> In section 4, it says "Detection aims to minimize the negative effects caused by captive portals in several ways.  Captive portal detection can cause issues in some networks; for example: .."
> 
> Suggestion: after "several ways, " list a few, or change to something like "Detection aims to minimize the above negative effects caused by captive portals, but can cause different issues, including: ..."

Done, thanks.

> I don't feel we have explained the reasons for operators wanting to defeat the CP detection in section 4.1. Perhaps in section 4, under *Sandboxing* we can explain:
> 
> While sandboxing seems a good idea to protect user data (particularly on Open WiFi), it is implemented differently on various platforms and often causes a (severely) broken user experience on the operator's CP-Web site (even when the operator is protecting user data end-to-end with HTTPS). To offer a consistent and rich experience on the CP-Web, some operators actively try to defeat OS CP detection.

Done.

> If I may rant a bit... OS vendors and others doing CP detection are conflating security issues around Open WiFi and Public Access Networks, and the need to protect user data in such networks, with CP detection. While CP detection is perhaps a good signal for designating a network as Public Access, it does not inherently mean the underlying network is "insecure". Nor does the absence of a CP in an Open WiFi network mean the underlying network is in anyway "secure" (and therefore not Sandboxed). The reasons for vendors being extra suspicious of CP networks is because of the similarities with mitm attacks - which is understandable. However, as CP networks are more common place and the mechanisms for signaling become more formalized (thanks to this WG), vendors need to work with, not against, operators who utilize TLS to protect user-data even in Open WiFi public access networks, to offer a full browser CP-Web experience.

Has anyone looked at exactly what the sandbox restrictions are in current OSs?

Thanks again!

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Mar 2016 20:11:26 +1100

> I've seen CPs that ask for Facebook username and password, but NOT over HTTPS, and not to a Facebook domain (IIRC); it's more of a user education / security UX problem than anything.

That's perhaps an extreme - and horrific - example of what I thought
you intended here.

Loading a real browser allows a CP to close the loop with tracking
bugs.  That is less offensive, though to what degree might depend on
where you sit.

There are probably plenty of potentially relevant reasons too.  For
example, a network operator might simply want to authorize one set of
users (their paying customers) over others.  A sandbox in that context
represents a hurdle for their users, who can't rely on cookies or
other preexisting state.  The sandbox then has security drawbacks in
that it encourages users to pick less secure passwords.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Mar 2016 10:51:21 +1100

> that it encourages users to pick less secure passwords.

One aspect that's potentially different is that current CP detection implementations (going to add a term for that :) can be automatically triggered; if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop up a window.

Without sandboxing, that means the network gets tracking data without any user intent in a very common case. An attacker can also spoof a common SSID to gather such data.

Of course, OSs could stop automatically joining Wifi networks, but that would make for a lot of unhappy users...

---

From: David Bird <[email-masked]>
Date: Thu, 10 Mar 2016 16:09:57 -0800

I'm not aware of any CP detection being triggered only based on the SSID.
(What does it do if there actually isn't a CP?) ...

An attacker gets a LOT more mileage out of a Open SSID evil twin with NO
captive portal if the desire is to capture cookies... Any attacker that
gets tripped up by clients doing a Sandboxed browser isn't a very good
attacker :)

David

On Thu, Mar 10, 2016 at 3:51 PM, Mark Nottingham <[email-masked]> wrote:

> >> I've seen CPs that ask for Facebook username and password, but NOT over
> HTTPS, and not to a Facebook domain (IIRC); it's more of a user education /
> security UX problem than anything.
> >
> >
> One aspect that's potentially different is that current CP detection
> implementations (going to add a term for that :) can be automatically
> triggered; if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop up a
> window.
>
> Without sandboxing, that means the network gets tracking data without any
> user intent in a very common case. An attacker can also spoof a common SSID
> to gather such data.
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Mar 2016 11:12:16 +1100

Good point. 

Sent from my iPhone

> On 11 Mar 2016, at 11:09 AM, David Bird <[email-masked]> wrote:
> 
> I'm not aware of any CP detection being triggered only based on the SSID. (What does it do if there actually isn't a CP?) ...
> 
> An attacker gets a LOT more mileage out of a Open SSID evil twin with NO captive portal if the desire is to capture cookies... Any attacker that gets tripped up by clients doing a Sandboxed browser isn't a very good attacker :)
> 
> David
> 
>

---

From: Alexis La Goutte <[email-masked]>
Date: Fri, 11 Mar 2016 16:57:53 +0100

> triggered; if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop up a
Hi,
it is the idea of HotSpot 2.0 from WiFi Alliance ? Add on SSID announce
frame (Beacon Frame), It is a SSID with Captif Portal....
HotSpot 2.0 is already supported by WiFi Vendor (Like Aruba / Cisco)...

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>