Re: Portal authorization

On 2012-04-10 13:03, Nicolas Mailhot wrote:
>
> 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
> headers.
>
> http://lists-archives.com/git/763532-handle-http-error-511-network-authentication-required-standard-secure-proxy-authentification-captive-portal-detection.html

The URI is the request URI.

>>> 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"
> argument)
>
> | 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.
>
> https://code.google.com/p/chromium/issues/detail?id=71736
> https://bugzilla.mozilla.org/show_bug.cgi?id=728658
>
> Best regards,

It seems that you are looking for a solution for a complex problem. 511 
is just a simple building block that is supposed to make it more obvious 
for captive portals to return an HTTP response with a status code other 
than 2xx. As such, it can be deployed right away, and browsers *can* 
make use of it as well.

Best regards, Julian

Received on Tuesday, 10 April 2012 11:42:48 UTC