W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: Portal authorization

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Tue, 10 Apr 2012 13:03:10 +0200
Message-ID: <6fe22d5f627ff564d9c2dc43e6e55a00.squirrel@arekh.dyndns.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "Jamie Lokier" <jamie@shareable.org>, "William Chan (陈智昌)" <willchan@chromium.org>, ietf-http-wg@w3.org

Le Mar 10 avril 2012 12:12, Julian Reschke a écrit :
> On 2012-04-10 09:00, Nicolas Mailhot wrote:
>> Le Mar 10 avril 2012 03:31, "Martin J. Dürst" a écrit :
>>> Hello Jamie, others,
>>> Mark had a draft on this,
>>> http://tools.ietf.org/html/draft-nottingham-http-portal-02. I'm not sure
>>> why it didn't move forward.
>> I think it morphed in http error 511 however:
>> 1. error 511 does not return an url so it can't be handled by dumb web
>> clients
>> such as curl
> Nor did the proposal in draft-nottingham-http-portal-02. Also, handling
> by dumb web clients was never on the agenda for this code, and I'm also
> not sure how it's supposed to work.

As started on the curl or git list dumb clients can not render a complex auth
page. They could give the user the address of this page, so he could open it
in a smarter client, if they had this address available in the HTTP 511


>> 2. browser people do not like it. Gateway auth really needs to be specified
>> once and for all in a document with browser buy-in such as http/2
> Please do not make blanket statements like these unless you can back
> them up.

Right now http/1 is perceived as an end-to-end protocol with no provision for
intermediaries. And the situation is worse with TLS. If http/2 adds
multiplexing, this multiplexing should make it explicit intermediaries exist
and make a channel available for intermediaries to add their signalling

Right now what browser people have written about error 511

| Doing something "useful" with 511-over-MITMed-SSL would mean a huge increase
| in attack surface:
| * We'd have to poke a hole all the way through our TLS stack to even see the
| 511.

| A new HTTP status code won't help this bug because we get the SSL certificate
| name mismatch error before we can send an HTTP request.

(the "end-to-end" only argument)

| 3. We determine, from that error, whether we think we should try to detect
| the captive portal. If so, we issue a request to captive-portal
| test-mozilla.org. If that response comes back as a 511, or with a wispr
| response, or some other indication that we're in a captive portal, then we
| kick into captive portal mode.

(the "let's ignore proxy signalling and try to guess location by our own"

| But, I don't think we should avoid implementing a solution for the most
| common cases just because there are a few (or even many) cases where it
| wouldn't work.

("it's hard, let us do it some other day" argument)

It's a hard problem which had no satisfactory answer so far and which
resolution has been postponed for all of http/1 life. Please do not make the
same mistake with http/2 and provide for intermediaries from the start up.


Best regards,

Nicolas Mailhot
Received on Tuesday, 10 April 2012 11:03:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC