Bugs item #768275, was opened at 2003-07-09 07:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=768275&group_id=976

Category: http
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Submitted By: Cris Bailiff (crisb)
Assigned to: Daniel Stenberg (bagder)
Summary: Bug in NTLM logic in 7.10.6-pre (4?)/CVS

Initial Comment:
Hi Daniel,

I'm fiddling with the 7.10.6 pre-release NTLM support
in CVS, and have a minor issue. I'll try and debug it
and provide a fix, but I thought I should log the issue
first:

Problem:

* Once NTLM has negotiated authentication on a
particular connection (type1, type2, type3 -> content),
there is no need to send any more 'Authenticate'
headers on that connection for future requests (for
the same user id).

* libcurl does this 'correctly' for a sequence of ntlm
requests for the same host and user credentials (the
little patch I submitted to drop the auth header after
the type-3 message make this work).

* The bug appears when subsequent requests on the same
curl handle are not destined to the same host (tcp
connection). If the new request also requires
authentication, libcurl doesn't send it, so the request
fails.

I found this with some perl scripts calling libcurl
directly, but it wasn't too hard to create a command
line example:

curl --ntlm --user test1:test123
http://ntlmhost-a/protected.htm
http://ntlmhost-b/otherpage.htm

The second request fails. Using the library, you can
make the second request be to a host using Basic (or, I
suppose, Digest) auth, and see that that request also
fails.

It even fails when the request is to the same host, but
needs a new tcp connection and authentication handshake
- for example, to the http and https versions of the
same content:

curl --ntlm --user test1:test123
http://host/protected.htm https://host/protected.htm

Cause:

* I'm pretty sure this is a fundemental ntlm 'logical'
bug which my last patch just highlights. The basic
issue is that NTLM is a stupid protocol which breaks
the HTTP stateless model - NTLM authenticates the tcp
connection, not each HTTP request.

It's correct for libcurl not to send further auth
headers on an already connected NTLM connection, but
libcurl (correctly) keeps the authentication state in
the curl_handle, not on a per-tcp-connection basis.
This breaks when using NTLM. The state we get the
curl-handle into after an NTLM handshake (not sending
auth headers) persists for subsequent requests on
different tcp connections, even though they
should/could require new WWW-Authenticate: handshakes.

* A quick fix might be to drop the NTLM optimisation
for multiple requests (by re-negotiating NTLM for every
request, either using the existing or a new tcp
socket), but this would make libcurl much less
efficient for multiple requests from an NTLM server.

* A better fix seems to require storing some additional
authentication state per-socket, to mark what authtype
and credentials were last used on that socket, and to
optimise away the authentication header only where the
per-socket info shows that the username/password
haven't changed and that the type is NTLM (or the
Negotiate type in future?).

I'll have a look at fixing this up, but I didn't want
to mess with the socket structures or socket-caching
too much without your agreement that this is where the
problem really is, and that it's an appropriate route
to fixing it.

Hope you've had a good holiday!

Cheers,
Cris

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=768275&group_id=976

-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
Received on 2003-07-09