W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 01 Mar 2012 13:13:01 +1300
Message-ID: <4F4EBF0D.3010002@qbik.com>
To: Henrik Nordström <henrik@henriknordstrom.net>
CC: ietf-http-wg@w3.org


NTLM could be made non-connection-oriented if http auth had some sort of 
context attribute that identified the auth conversation (in both 
challenges and responses), instead of having to associate it with the 
connection.

Adrien


On 1/03/2012 1:07 p.m., Adrien de Croy wrote:
>
>
> On 1/03/2012 12:21 p.m., Henrik Nordström wrote:
>> tor 2012-03-01 klockan 11:57 +1300 skrev Adrien de Croy:
>>
>>> that depends on proxy design.  If the challenges and responses are 
>>> going
>>> over the same TCP connection it's pretty simple.
>> I won't go into this. HTTP is message oriented, not connection oriented.
>
> I'm not 100% convinced.  Esp with auth.  Even disregarding NTLM, any 
> time you have a challenge and response, if the response comes to a 
> server over a different TCP connection, then I think a lot of 
> implementations will break.  Maybe therefore they are poorly designed.
>
> If for instance multiple proxy clients are multiplexed over a pool of 
> connections between the proxy and a server, so that subsequent 
> requests on a connection to a server can be for any proxy client, then 
> the server's job of maintaining association of credentials, or 
> deciding when to issue a challenge is made much more difficult than if 
> it assumes the connection is for only 1 user.
>
> Maybe if assuming 1 connection = 1 user is broken, it should be 
> explicitly warned about in the spec.  The alternative though is either 
> the server has to challenge every request, or the auth tokens 
> submitted by clients can be used without round-trips, or some other 
> token needs to be stored and looked up by the server in global (i.e. 
> non-connection-oriented) memory.  Basic fits there, but does Digest?  
> NTLM certainly doesn't of course.
>
>>
>>> the main area we see the problem is actually not in proxy auth, but 
>>> when
>>> a proxy intercepts the connection, requires auth and then the website
>>> requires auth as well.
>>>
>>> It's hard for the proxy to know whether an auth response should be
>>> processed by itself, or upstream.
>> Are you talking of transparent intercepting proxies doing NTLM here? If
>> you do then please stop, that's just happens to work because the
>> security model of NTLM is plain broken broken allowing it to be abused
>> in mitm attacks in completely insecure manners. end of discussion.
>
> actually any sort of auth when you intercept you no longer know who 
> the target is.
>
>> Please let NTLM die a painful death.
>
> It's going to be a very long death.  It's just not going away.  I 
> think we will still see significant use of it in 10 years from now.
>
> I'm not even sure how to implement Digest on windows (I've only 
> briefly looked), but it looks quite difficult.
>
> Even Negotiate is still connection-oriented?
>
>>> In most cases though where this happens, wouldn't the upstream proxies
>>> be within the same administrative domain?  e.g. so creds should work,
>>> and leakage shouldn't be a problem.
>> Even that assumption only holds for basic auth. With anything else it
>> breaks.
>
> ok
>
> So basically the answer remain: "use Digest".
>
> Adrien
>
>
>>
>> Regards
>> Henrik
>>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
Received on Thursday, 1 March 2012 00:13:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT