Re: [Captive-portals] practicality of 511 HTTP status code

Vincent van Dam <VvanDam@sandvine.com> Sun, 07 May 2017 19:09 UTC

Return-Path: <VvanDam@sandvine.com>
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 3920F127698 for <captive-portals@ietfa.amsl.com>; Sun, 7 May 2017 12:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Ag74d6WyiYvP for <captive-portals@ietfa.amsl.com>; Sun, 7 May 2017 12:09:30 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C96124234 for <captive-portals@ietf.org>; Sun, 7 May 2017 12:09:30 -0700 (PDT)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0319.002; Sun, 7 May 2017 15:09:28 -0400
From: Vincent van Dam <VvanDam@sandvine.com>
To: David Bird <dbird@google.com>, Erik Kline <ek@google.com>
CC: "captive-portals@ietf.org" <captive-portals@ietf.org>
Thread-Topic: [Captive-portals] practicality of 511 HTTP status code
Thread-Index: AQHSxwjTJeG0HSprU02ArwB2QAXM4qHpdqUA//+/gBM=
Date: Sun, 07 May 2017 19:09:27 +0000
Message-ID: <D2A19ABBC0147C40BFBB83D1CF3E95F03FEB4A22@wtl-exchp-2.sandvine.com>
References: <CAAedzxrPo+qSBWP23=fpwG0ZzBrdOMgs0gykAxOPSFbojeR79A@mail.gmail.com>, <CADo9JyVrO6fcOtYXc=VtrfmhFsYdHY=3t4nM2xLG3CBnzizWJQ@mail.gmail.com>
In-Reply-To: <CADo9JyVrO6fcOtYXc=VtrfmhFsYdHY=3t4nM2xLG3CBnzizWJQ@mail.gmail.com>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.131.1]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_D2A19ABBC0147C40BFBB83D1CF3E95F03FEB4A22wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/1qxF8sOZZ2fJa0dgKlzDjRa3ZD0>
Subject: Re: [Captive-portals] practicality of 511 HTTP status code
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 07 May 2017 19:09:32 -0000

- A legacy 30X response will still be needed for some user-agents

Is that because you don't expect all user-agents (webbrowsers specifically) to support it?

- The response contains HTML that should contain the login URL (or a meta refresh, etc), which isn't a very well structured way to get the URL

I agree, it makes more sense that the url would be in a response header instead (like the 30x status).


   It is not intended to

   encourage deployment of captive portals -- only to limit the damage

   caused by them.


Damage? Hm...


In terms of non-browsers accessing apis, they should be using TLS! And perhaps not follow redirects or otherwise add some integrity to their api.

I agree, apis should use tls. Not every developer might agree though (a rest api containing weather predictions?).
But also, I don't think we can fix the world, fix every api/client that is ever made. We can only at least identify mitm 30x scenarios are implemented, and try to regulate that scenario a bit more, which has been done by introducing the 511.


________________________________
Van: Captive-portals [captive-portals-bounces@ietf.org] namens David Bird [dbird@google.com]
Verzonden: zondag 7 mei 2017 20:36
Aan: Erik Kline
CC: captive-portals@ietf.org
Onderwerp: Re: [Captive-portals] practicality of 511 HTTP status code

I personally do not find it very useful in public access networks, because:
- A legacy 30X response will still be needed for some user-agents
- Returning 511 is still a man-in-the-middle response (nothing changed there)
- The response contains HTML that should contain the login URL (or a meta refresh, etc), which isn't a very well structured way to get the URL
- differences in how browsers handle the 'error' and the associated user experience

There are a couple other oddities:


   Note that the 511 response SHOULD NOT contain a challenge or the
   login interface itself, because browsers would show the login
   interface as being associated with the originally requested URL,
   which may cause confusion.


Why shouldn't it contain a challenge? (the reason given only relates to the 'login interface itself').


   It is not intended to
   encourage deployment of captive portals -- only to limit the damage
   caused by them.


Damage? Hm...

In terms of non-browsers accessing apis, they should be using TLS! And perhaps not follow redirects or otherwise add some integrity to their api.

On Sun, May 7, 2017 at 1:05 AM, Erik Kline <ek@google.com<mailto:ek@google.com>> wrote:
I wanted to poll the group's thoughts on the usefulness of the rfc6585#section-6 511 HTTP status code.

Has anybody tried to serve 511s to clients, and if so what were the results?

Might it be useful to serve an API endpoint (rather than the full-blown HTML UI)?

I'm trying to get a sense of whether this will be a useful tool to use in assembling a recommended portal interaction.  If we determine it's not really going to be a workable component, then that's useful to know too.

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals