Re: Portal authorization

On 10/04/2012 11:03 p.m., 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
>
>>> 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

That perception is plain wrong. HTTP/1 has always had the definition of 
a proxy built-in as much as SMTP has the concept of a relay built-in.

The *T* in TLS does not alter the hop-by-hop nature. That is an 
illusion. Even CONNECT can and does traverse multiple hops from the 
tunnel endpoint to the origin destination.

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

The reality more often than not being:

    A =>B=>C->D

A makes CONNECT through B to "endpoint" C. C relays to D. D responds 
through C to A.

When B requires authentication ... only Basic and Kerberos seem to work 
nicely.
When B requires all inbound requests be made over TLS connections ... 
only Chrome seems to work easily.


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

Your brief summary says it all really. If they dont trust the endpoint 
they are connected to at least signal its own needs and location 
properly, what hope is left? The person using this argument would be 
terrified by ARP spoofing.


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

We are required to maintain semantic compatibility with HTTP/1. 
Proxy-auth headers remain in all proposals. Pity the browser who dont 
implement them for captive portals.

The argument from the captive portal people is simply to get browsers to 
pay attention to portal / proxy signals and act as if the portal 
existed. Stop complicating things by pretending end-to-end for 
everything (including TLS port 443) even when the protocol signals are 
clear and loud that a proxy exists in the middle.

When the nay-sayers can get over that paradigm shift even HTTP/1 will be 
able to work better.

>
> https://code.google.com/p/chromium/issues/detail?id=71736
> https://bugzilla.mozilla.org/show_bug.cgi?id=728658
>
> Best regards,
>


AYJ

Received on Friday, 13 April 2012 04:24:38 UTC