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 


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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC