W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2015

Re: TLS 1.3 and Captive Portals

From: Hodges, Jeff <jeff.hodges@paypal.com>
Date: Thu, 3 Dec 2015 16:40:46 +0000
To: Craig Francis <craig@craigfrancis.co.uk>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>
Message-ID: <D285AC98.492F0%jehodges@paypalcorp.com>
On 12/3/15, 8:19 AM, "Craig Francis" <craig@craigfrancis.co.uk> wrote:

>Not sure where the discussion is happening with TLS 1.3



>When someone first connects to a captive portal

there is a nascent IETF captive portal WG (capport)..

capport: Captive Portals WG
*  capport wg is close to being chartered, ought to be accomplished before


*  this relevant non-WG foundational I-D is already near-RFC..

Captive-Portal Identification in DHCP / RA

The authors note that this draft is "not a complete solution..", thus
implying the need for chartering the capport WG in order to further
specify whatever it is that is missing.



>(e.g. hotel WiFi), they typically redirect any requests to a
>login/terms/payment page.
>If that redirect is done for a HTTPS connection, then the browser
>will/should complain (bad certificate).
>Would it be possible for the TLS 1.3 handshake to support this situation?
>So maybe the browser gets a response which does not attempt to give a
>certificate, but is simply a URL to redirect the user to.
>Then the browser can show a nice and friendly error message, and a link
>for the user to load (if they want to).
Received on Thursday, 3 December 2015 16:41:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:53 UTC