Re: Portal authorization

["Nicolas Mailhot" <[e-mail]>]

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

>> 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,

-- 
Nicolas Mailhot