Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Inifinite loop during NTLM authentication #435
Our client connects to a proxy which uses NTLM authentication. The destination is a server whose server certificate does not match to the actual hostname. The proxy authentication type is set to CURLAUTH_ANY. The following steps are necessary in order to reproduce the problem:
This call fails since the server certificate doesn't match to the actual hostname. Now we go on:
Problem: The last call to
Yes, using CURLAUTH_ANY is essential to reproduce the error. I think the infinite loop occurs in the probing. libcurl sends the plain CONNECT request over and over although the proxy response always contains the header
in order to initiate the regular NTLM negotiation process.
The Squid configuration contains
so I guess via NTLM and not via negotiate
Whose debug output do you mean? The libcurl's one or the Squid's one? I activated only NTLM-authentication in Squid. The response from the proxy contains only the above mentioned header.
I'm using Ubuntu 15.04 x86_64.
In order to reproduce the error it is essential that libcurl succeeds to connect to the proxy once beforehand. This connection must be torn down due to some SSL validation issue or something else. The second connection attempt to the proxy then fails.
On Sep 15, 2015 11:10 PM, "Philipp Wähnert" firstname.lastname@example.org
Curl debug output
This is the libcurl log:
and so on. I think the essential line here is
which indicates to me that libcurl didn't properly recover from the last successful authentication and following unsuccessful certificate verification.
On Wed, Sep 16, 2015 at 12:28 AM, Philipp Wähnert email@example.com
Your proxy close the connection each time it sends the initial 407 with
I tweaked my apache server to do the same and I think I've reproduced it
Again, same pattern as mentioned above.
What's the above line? it is already set to not verify.. I think this is
This log is issued when libcurl creates a new connection to clear NTLM
added a commit
Sep 16, 2015
Ok, doesn't seem related to the SSL error I mentioned.
I think I see what's happening though (vaguely), since we don't reset authhost->done when we start a fresh connection we might think we are already authenticated and not send authz header.
This might be related to the changes from:
The commit below solves the problem by me:
According to this specification it's an behavior which has to be expected by the client.
It's necessary that the destination server tears down the connection. I observed the same error with libcurl if the server hangs up for some other reason.
I'll take a look at the commit. Thank you!
This solves the issue. The Log looks now like expected - Sorry for the verbose post but for the sake of completeness:
@DarovskikhAndrei Negotiate has several variants so its hard to tell.
@phlipsi I didn't mean to say the proxy was wrong, just tried to explain the difference in behavior.
Ok, here is a better description of what seem to be going on (after playing a little with gdb).
You first need a successful authentication to set 'done' to true.
I still think the patch is correct, and it seem similar to what the code used to do.