TLS 1.3 and Captive Portals

[Craig Francis]

Hi,

Not sure where the discussion is happening with TLS 1.3, but just a though...

When someone first connects to a captive portal (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).

Craig

[Richard Barnes]

This would be better for t...@ietf.org

Sent from my iPhone. Please excuse brevity.

[Hodges, Jeff]

On 12/3/15, 8:19 AM, "Craig Francis" <cr...@craigfrancis.co.uk> wrote:


>Not sure where the discussion is happening with TLS 1.3

<t...@ietf.org>

https://www.ietf.org/mailman/listinfo/tls

>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
IETF-95:

https://datatracker.ietf.org/wg/capport/charter/


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

Captive-Portal Identification in DHCP / RA
https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/

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.


hth,


=JeffH

[Craig Francis]

Great, thanks Jeff, really glad to hear that is already being considered (and embarrassing I didn't find these after a quick search).

And Richard, thanks for the quick reply as well.