Re: #177: Realm required on challenges

On 25/07/2011 6:21 p.m., Amos Jeffries wrote:
> On 25/07/11 15:30, Adrien de Croy wrote:
>>
>>
>> On 25/07/2011 3:00 p.m., Amos Jeffries wrote:
>>> On 25/07/11 13:39, Adrien de Croy wrote:
>>>>
>>> AIUI, WWW-Auth and Proxy-Auth are defined explicitly with distinct
>>> end-to-end and hop-by-hop requirements to prevent exactly that
>>> leakage. There is no leak problem unless the implementation is
>>> non-compliant or misconfigured.
>>>
>>> There is the edge case we hit occasionally. Where two chained proxies
>>> require unique Proxy-Auth credentials from the client. Admin obsession
>>> with end-to-end single-signon appears to be avoiding this problem for
>>> now on most networks. But these per-user chaining configurations are
>>> still being asked about in our user base occasionally. It is
>>> reasonable to assume they are being implemented ... somehow.
>>>
>>
>> How does a proxy state (using Realm)
>>
>> "use those creds for any site you access through me"
>
> Your argument appears to assume the credentials are going to a "site" 
> itself. Which is only true for origins. Proxy-auth are stripped by the 
> proxy.
>
> The proxy relevant version of your statement is:
>  "use those creds for any access through me"
>
>   Proxy-Authenticate: Foo realm="e"
>
> The 'm' part of "me" is built into the browsers knowledge of what 
> proxy IP:port or FQDN:port it is contacting.
>
> To form two-part combo distinguishing "m"+"e" from "m"+"y landlords" 
> and "m"+"r joe blogs" proxies. All chained and accessed through the 
> proxy gateway "m".
>
sorry, what I meant was

"use these creds to auth to me (your proxy for today) for any site you 
access through me".

The creds I'm talking about aren't the site creds, but the proxy creds.

Nowhere in RFC2616 or the proposed amendmend does it state that in the 
case of authenticating TO a proxy the client should do something 
different in terms of deriving values for the Authority


>
>>
>> if the base URL must be combined with the realm. Unless you can say
>> realm ="../../*" or something.
>
> You are thinking the base URL has to be inside the realm string? I 
> don't read the RFC that way. It makes no statement at all of _how_ 
> things have to be combined. Merely that they need to be. (Though it 
> does not say MUST).

nope, it's appended to the base URI.

>
> As Yvnge mentioned, when talking to a proxy the service site and scope 
> is proxy-IP:port. Adding the particular scheme realm= value to that 
> generates a scope for the credentials.

that's not in the spec

>
> ie three-factor authentication (TCP data, realm, credentials). With 
> two factors beyond the browsers ability to forge.
>
>>
>> The problem is
>>
>> a) the proxy MUST provide a realm
>> b) the realm must be combined with the base URI
>>
>> Yet another reason why intercepting connections is a bad idea.
>>>>
>>>
>>> What has that got to do with this topic? any halfway sane interceptor
>>> won't touch auth at all. The insane ones break things regardless of
>>> what gets specified.
>>
>> Therefore there are a lot of insane network admins out there who insist
>> on the ability to
>>
>> a) intercept connections (so they don't need to configure a proxy in the
>> client); AND
>> b) authenticate those connections at the intercepting proxy
>
> Yes there are. Fortunately they can be educated. All it takes is a 
> clear explanation of the security leak introduced by handing your 
> private credentials to unknown third-parties. I've ended this email 
> with the effective example I usually use.

most countries spend a significant portion of GDP on educating their 
populace.  It's not cheap.  So, saying we can simply educate clients 
about things isn't correct, it's not simple or cheap.

>
>>
>> sure it sucks, but when you turn on automatic logon in IE, it actually
>> kinda works.
>
> Really? what browsers respond to Proxy-Auth challenges when they 
> explicitly contacted the origin directly?

all of them do.  They don't know they are being intercepted by a proxy.  
They just think the site challenged them.

There's a setting in IE that allows it to try authing to all and sundry 
with current windows credentials.  This then bypasses the logon dialog 
(which otherwise clients pop many times for a page - 1 for each 
different site)

>
> Note that NTLM does not authenticate HTTP. But only authenticates the 
> client end of the TCP link, 

???  It's used to associate credentials with the connection between 
client and the other end of the NTLM handshake, whether that's a proxy 
or O-S.

> sometimes the machine rather than user. So when the DC trusts the 
> proxy the actual source of the credentials become irrelevant. 

It's still quite useful to be able to identify who made a request.

The source of the credentials is the human who typed in their password 
when they logged into windows / their domain.

> NTLM and Kerberos credentials can be (and often are) injected by the 
> middleware without the browser actually sending any credentials at all.

sure.

>
>> Sure it's less work to just configure the browser to use
>> the proxy and you get a better experience.
>>
>> Problem is there are a bunch of proxy vendors (ourselves included) who
>> support intercepted connections, because that's what users think they
>> want. We no longer recommend it, but others do, and on the face of it,
>> the benefits seem worth-while, and therefore often form part of a
>> purchasing decision.
>>
>
> I share that hat. Yet my view here apparently varies.
>
> "intercepted connections" or "intercepted connections _by_ an 
> authenticating proxy"?

the latter.

>  Lets be clear on that before I ask you for your credit card pin 
> number. Would you give it to me on demand? or would I have to try 
> asking your bank?
>  The same security mechanisms are in play here. With the same 
> categories of possible checks and loopholes.
>
>  I could intercept your phone line and hear you telling it to someone 
> you trusted. Or you could talk about ponies all day and I'd know 
> squat. Or you could pass the phone to a friend halfway and I get 
> theirs by mistake.

who told you about the ponies!!?!!?

>  Even so, Would you answer my voice if I interrupted and asked halfway 
> through your conversation with someone else?
>
> So I restate; no halfway sane interceptor touches auth. The half-sane 
> ones might try and log it, might even background verify it. But not 
> challenge or depend on it.

judge not lest ye be judged.  There are plenty of people intercepting to 
an authenticating proxy.

>
> AYJ
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Monday, 25 July 2011 07:35:22 UTC