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

Mark Nottingham <mnot@mnot.net> Thu, 10 March 2016 23:51 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467D912DEEA for <captive-portals@ietfa.amsl.com>; Thu, 10 Mar 2016 15:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e8TL5oC5eOZ for <captive-portals@ietfa.amsl.com>; Thu, 10 Mar 2016 15:51:33 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B81912DEE4 for <captive-portals@ietf.org>; Thu, 10 Mar 2016 15:51:32 -0800 (PST)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6A63D22E253; Thu, 10 Mar 2016 18:51:25 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CABkgnnWTfGsbktCHGGygE=Cva4JsA6_mBuBhN2KwrwNSKVQwLQ@mail.gmail.com>
Date: Fri, 11 Mar 2016 10:51:21 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <16287DD0-2408-4164-A945-F10A0D9BF22D@mnot.net>
References: <CADo9JyVXUR=bgueHW1wWk4PhCJEvs0R-p9ya5wGVEmtYjtoFJQ@mail.gmail.com> <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> <CABkgnnWTfGsbktCHGGygE=Cva4JsA6_mBuBhN2KwrwNSKVQwLQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/captive-portals/i7TkbfgEc9wD4-gDHPzL-9rIo58>
Cc: captive-portals@ietf.org, David Bird <dbird@google.com>
Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2016 23:51:37 -0000

On 8 Mar 2016, at 8:11 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On 8 March 2016 at 18:45, Mark Nottingham <mnot@mnot.net> 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.

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/