IETF Logo Mail Archive

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

Mark Nottingham <mnot@mnot.net> Fri, 11 March 2016 00:12 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 BF03512DF0F for <captive-portals@ietfa.amsl.com>; Thu, 10 Mar 2016 16:12:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 WV0LZFXJ6j4E for <captive-portals@ietfa.amsl.com>; Thu, 10 Mar 2016 16:12:22 -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 C5DBE12DF0E for <captive-portals@ietf.org>; Thu, 10 Mar 2016 16:12:21 -0800 (PST)
Received: from [192.168.2.11] (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 4A73422E255; Thu, 10 Mar 2016 19:12:20 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail-113C8235-E208-47C9-A2F8-C7B472167E86"
Mime-Version: 1.0 (1.0)
From: Mark Nottingham <mnot@mnot.net>
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <CADo9JyUcxA8aaAhkOQDpA9BMMvL0EGEasx0HQA6BY9Ewbqyr+g@mail.gmail.com>
Date: Fri, 11 Mar 2016 11:12:16 +1100
Content-Transfer-Encoding: 7bit
Message-Id: <455D0008-E6E5-42C7-8C61-81CEA6916445@mnot.net>
References: <CADo9JyVXUR=bgueHW1wWk4PhCJEvs0R-p9ya5wGVEmtYjtoFJQ@mail.gmail.com> <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> <CABkgnnWTfGsbktCHGGygE=Cva4JsA6_mBuBhN2KwrwNSKVQwLQ@mail.gmail.com> <16287DD0-2408-4164-A945-F10A0D9BF22D@mnot.net> <CADo9JyUcxA8aaAhkOQDpA9BMMvL0EGEasx0HQA6BY9Ewbqyr+g@mail.gmail.com>
To: David Bird <dbird@google.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/captive-portals/IXTyZnMyEKP3Z6O127MYxl8r5y4>
Cc: captive-portals@ietf.org, Martin Thomson <martin.thomson@gmail.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: Fri, 11 Mar 2016 00:12:25 -0000

Good point. 

Sent from my iPhone

> On 11 Mar 2016, at 11:09 AM, David Bird <dbird@google.com> 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
> 
> 
>> On Thu, Mar 10, 2016 at 3:51 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> 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/
>

v2.23.0 | Report a Bug | By Email