(In reply to Paul Ling from comment #0)
> The connection of NTLM authenticated request shouldn't be reuse in libcurl
> multi interface because it includes authentication context, after reuse with
> other plain requests to the same server, the context will be messed up and
> then next request with the same user's NTLM authentication will get 401
> always until this connection get closed by HTTP server, and new connection
> to be established for the NTLM request.

Which bug do you refer to above?  Has it been already reported?  How are you confirming that libcurl is used correctly in the above scenario?

Please provide a minimal example.

Here is the information copied from curl known bugs in the link I gave in this bug additional info section.

-77. CURLOPT_FORBID_REUSE on a handle prevents NTLM from working since it
-  "abuses" the underlying connection re-use system and if connections are
-  forced to close they break the NTLM support.
-

That is actually not what I was asking about.  I meant what is the reason you need to use CURLOPT_FORBID_REUSE at all?

Steps to Reproduce:
1. Create curl multi handle with most default options, I only set CURLMOPT_SOCKETFUNCTION/CURLMOPT_SOCKETDATA for libevent integration
2. Create and add easy handle for NTLM authentication HTTPS request with AD user A credentials. One connection will be established this time
3. Create and add one HTTPS request to the same web server but doesn't require NTLM authentication afterward, libcurl will reuse the connection which send NTLM authentication request.
4. Create and add the third request as same as the first NTLM requests with the same user. libcurl still want to reuse the same connection for this new NTLM request. But IIS will return 401 always as below unless the old connection break down and new connection established.


 * Re-using existing connection! (#0) with host hhh.xxx.com
 * Connected to hhh.xxx.com (10.26.0.100) port 443 (#0)
 * Server auth using NTLM with user 'ppp'
 > POST /auth/useradauth HTTP/1.1^M
 User-Agent: libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2^M
 Host: hhh.xxx.com^M
 Accept: */*^M
 Content-Type: application/json^M
 Content-Length: 67^M
 ^M
 < HTTP/1.1 401 Unauthorized^M
 < Server: Microsoft-IIS/7.5^M
 * gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_0' not found< WWW-Authenticate: Negotiate^M
 * Authentication problem. Ignoring this.
 < WWW-Authenticate: NTLM^M
 < X-Powered-By: ASP.NET^M
 < Date: Wed, 22 Oct 2014 18:40:44 GMT^M
 < Content-Length: 0^M
 < ^M
 * Connection #0 to host hhh.xxx.com left intact

This looks like CVE-2014-0015, which is fixed since curl-7.19.7-37.el6_5.3.  Please have a look at bug #1053903 for details.

I noticed bug #1053903 as well, but it only happened when use multiple auth options together. To avoid this issue, I already specified only CURLAUTH_NTLM as HTTP_AUTH option in my app.

The point is that, if the authentication credentials (at least user name?) differ, the connection cannot be reused (even if CURLOPT_FORBID_REUSE is not set).  So the request for a minimal example is still valid.

But in my case, it is the same user to make NTLM http request twice in two minutes. If it is another user to make NTLM HTTP request, there is no problem.

As I understand it, you give libcurl user name and password to authenticate on sites that do not require (more precisely deny) authentication, which causes a problem later on.

Let me explain little bit more about my case.
My web server has two web apps, one is authenticator which takes IWA authentication and issue my special ticket to client. The second web app is that takes this ticket inside of HTTP body to provide discovery service, this web app does not request NTLM authentication.

The client process is that sending authentication HTTPS request with user/password to the first webapp, following by the second NON-NTLM HTTPS request without user/password. Once my client repeat this process, only the first authentication HTTPS request got succeeded, the second time authentication and later will always got 401 failure because of the connection re-use.

(In reply to Paul Ling from comment #11)
> The client process is that sending authentication HTTPS request with
> user/password to the first webapp, following by the second NON-NTLM HTTPS
> request without user/password. Once my client repeat this process, only the
> first authentication HTTPS request got succeeded, the second time
> authentication and later will always got 401 failure because of the
> connection re-use.

That ^^^ is the part that I still do not understand.  If your first request has user/password set and the second request does not have user/password set, the connection cannot be re-used for them.

Are you sure you have upgraded to curl-7.19.7-37.el6_5.3 or later?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-1254.html