Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-00
Lukas RUETZ <l.ruetz@asteas.com> Fri, 04 March 2016 15:43 UTC
Return-Path: <l.ruetz@asteas.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2761A219B for <captive-portals@ietfa.amsl.com>; Fri, 4 Mar 2016 07:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 9z4I5B2rypEG for <captive-portals@ietfa.amsl.com>; Fri, 4 Mar 2016 07:43:45 -0800 (PST)
Received: from mx1.asteas.com (mx1.asteas.com [83.218.160.135]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1E61A1EEE for <captive-portals@ietf.org>; Fri, 4 Mar 2016 07:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at frozentux.org
Received: from EXCHANGE.mbox.local (EXCHANGE.mbox.local [192.168.101.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.asteas.com (on Asteas-Business-Server) with ESMTPS id C33411860239 for <captive-portals@ietf.org>; Fri, 4 Mar 2016 16:43:40 +0100 (CET)
From: Lukas RUETZ <l.ruetz@asteas.com>
To: "captive-portals@ietf.org" <captive-portals@ietf.org>
Thread-Topic: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-00
Thread-Index: AdF1/WQqxigydv5zQoWQHYB2MGlz2wAHP6uAAANtNFM=
Date: Fri, 04 Mar 2016 15:43:40 +0000
Message-ID: <04FC2BF6CA29744989A8227EB45685C6019D21DA@EXCHANGE.mbox.local>
References: <04FC2BF6CA29744989A8227EB45685C6019D1162@EXCHANGE.mbox.local>, <20160304143307.GA17578@odin.ulthar.us>
In-Reply-To: <20160304143307.GA17578@odin.ulthar.us>
Accept-Language: de-AT, en-US
Content-Language: de-AT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.3.3.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/captive-portals/IE4tkoOdk3iNeY2WonNxkY4DYME>
Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-00
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Mar 2016 15:43:48 -0000
Hey Scott, thanks for your comments - I'm answering inline > > 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. > > I disagree. A MITM attack occurs when Alice sends traffic to Bob, but > Mallory replies in Bob's place and makes some effort to speak as though > Mallory is Bob. > > What you're quibbling about is the quality of the impersonation (and > maybe a lack of malicious intent). Because a CP does not/should not have this malicious intent, I wasn't happy with the word "attack". Of course the client can't see the difference. > > ------------------------------------------------------------------------------ > > > > 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. > > For now. I'm imagining a dark world where most of the web has migrated > to HTTPS & browsers do HTTPS with HSTS/HPKP by default but captive > portals stubbornly continue to try to MITM the connections, so users > complain to browsers that they can't click through the errors to satisfy > the captive portal and let them get to the real site...and the *browsers* > relent. :-/ > > Also, it doesn't help anything if users attempt to connect to the HTTP version > of the site instead -- that's just as much of a "click through". With the addition I tried to make clear in the document what happens if HSTS and HPKP are used, nothing else. Calling an http:// URL is the only working way at the moment to get a valid redirect until there is a real solution to this. Sadly people don't read, so the URL to the login-page printed on the tickets is almost never used. QR-Codes already helped a bit, but only a few users have QR-code readers installed. > > ============================================================================== > > > > 5. Security Considerations > > > > 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. > > I don't want CPs to just stop messing with TLS connections, because MITM > of unsecured traffic isn't really any better, it's just less visible > to software that something is wrong. > > I think the ideal future state is that: > > CPs don't falsify or redirect *ANY* traffic. DNS reports honest > answers, with DNSSEC if requested. ARP/IPv6-ND is answered honestly. > IP traffic to anything but the CP login server is blackholed (not > redirected) until the login server has whitelisted the user. > > Then, once the user is whitelisted, all the information previously > learned is still valid (no cache flushes required) and the user can go > on with life until their session with the login server times out (if > ever). > > I too think RFC 7710 is a sensible first step, and then it looks like > capport's job is to come up with protocols/mechanisms for software to > discover connectivity status, time remaining, access limitations. > > Maybe the way we get captive portals to start stepping in this direction > is to give the client some way of reporting "I understand RFC 7710 > (etc), so if you just level with me, I'll make this easy for both of us > to get what we want and move on."? In response, the CP would rely on > RFC 7710 (etc) and disable all the hacks used to funnel users to the > login server. > > The important question is why don't CPs (or OSs) use RFC 7710 now? Or > are they? Well we completely agree in this point - it just sounds a bit like you think CPs are doing this for fun. Most of this hacks are made to get the user to the login-page. We hope that this WG pushes things further. And by the way ... we ship RFC-7710 since this year, but AFAIK no device supports it. We're waiting for the OS vendors to implement it. BR Lukas -- Lukas RUETZ www.iacbox.com
- [Captive-portals] Thoughts/comments on draft-nott… Lukas RUETZ
- Re: [Captive-portals] Thoughts/comments on draft-… Scott Schmit
- Re: [Captive-portals] Thoughts/comments on draft-… Lukas RUETZ