Re: #177: Realm required on challenges

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


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

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.

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.

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

Note that NTLM does not authenticate HTTP. But only authenticates the 
client end of the TCP link, sometimes the machine rather than user. So 
when the DC trusts the proxy the actual source of the credentials become 
irrelevant. NTLM and Kerberos credentials can be (and often are) 
injected by the middleware without the browser actually sending any 
credentials at all.

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

AYJ

Received on Monday, 25 July 2011 06:21:43 UTC