problem with NTLM and GSS Negotiate
Date: Fri, 28 Oct 2011 10:29:34 +0200
We are currently using libcurl version 7.21.7. But according to the code my
problem still exists in 7.22
I think that I found a bug in the handling of proxy authentication methods.
If a proxy ( in our case a Microsoft ISA ) offers several Authentication
schemes where NTML and Negotiate are offered by the proxy and you tell
libcurl not to use the Negotiate scheme then the request never returns when
the proxy answers with its HTTP 407 reply.
It is reproducible by the following steps:
- Use a proxy that offers NTLM and Negotiate ( CURLOPT_PROXY and
- Tell libcurl NOT to use Negotiate CURL_EASY_SETOPT(CURLOPT_PROXYAUTH,
CURLAUTH_BASIC | CURLAUTH_DIGEST | CURLAUTH_NTLM )
- Start the request
The call to CURL_EASY_PERFORM never returns. If you switch on debug logging
you can see that libcurl issues a new request As soon as it received the 407
reply. Instead it should return and set the response code to 407.
I also think that I already found the bug that’s causing this behavior.
In Curl_http_input_auth(...) of http.c the incoming authentication methods
are handled. If "Negotiate" is recognized then it is checked if the State of
the Negotiate handshake is already GSS_AUTHSENT. If not then there is
already called Curl_input_Negotiate and the "newurl" member of the
Connectionhandle is set by copying the original URL. This causes the issue
of a new request but the GSS-Negotiate headers are never sent because this
authentication method cannot be picked because it is not wished by the user.
So the state is never set to GSS_AUTHSENT. That is the reason why it runs in
an endless loop. This goes on until the proxy tells you that you opened to
I fixed the problem for me by checking if CURLAUTH_GSSNEGOTIATE is picked
before doing anything.
Attached to the email is the patch that works for me in 7.21.7.
pcvisit software AG
Tel: +49 (0)351 796 5930
Fax: +49 (0)351 796 5932
- application/octet-stream attachment: http.c.patch