[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Fri, Mar 11, 2016 at 12:51 AM, Mark Nottingham <[email protected]> wrote:
On 8 Mar 2016, at 8:11 PM, Martin Thomson <[email protected]> wrote:
> On 8 March 2016 at 18:45, Mark Nottingham <[email protected]> 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.
> 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.

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

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

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

Captive-portals mailing list
[email protected]