cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: External NTLM authentication

From: Michael König <plasm_at_plasm.de>
Date: Wed, 15 Jun 2016 13:47:20 +0200 (CEST)

> Michael Kaufmann <mail_at_michael-kaufmann.ch> hat am 15. Juni 2016 um 12:04
> geschrieben:
>
>
> Hi,
Hi!
>
> in my company, we use libcurl to forward requests in a reverse proxy
> setup. We want to forward requests that use NTLM authentication. These
> requests already have "Authentication: NTLM ..." headers, so libcurl's
> CURLAUTH_NTLM feature is not suitable for such requests.
Do you want to authenticate against the reverse proxy or some server beyond
that? The latter case will never work with NTLM afaik unless the reverse proxy
is transparent.
>
> The problem is this: When libcurl is sending a request with a body,
> and libcurl gets an early "401 Unauthorized" response from the server,
> then libcurl stops sending the body and closes the connection. The
> code is in http.c, about line 3150 and starts with "if(k->httpcode >=
> 300) ...".
You are getting a 401 and not a 407 so i assume you try to use NTLM against a
server beyond the reverse proxy. In my understanding that will not work, because
the server will create a CHALLENGE packet that is meant for the reverse proxy
and not your client. Your client will not be able to properly respond to that
... if the data reaches it at all.
If you intended to get a 407 instead, check if you properly setup a proxy
authentication request vs. normal authentication.
>
> Usually this is a reasonable thing to do, but for NTLM, the connection
> must not be closed because NTLM authenticates connections, not
> requests. Note that if the built-in NTLM authentication is enabled,
> libcurl does not close the connection in this case.
>
To my knowledge NTLM does not care if the connection is closed between the 2nd
and 3rd authentication stage and libcurl should properly handle that. The answer
to the CHALLENGE packet is just sent in a different connection and *that* one is
the one getting authenticated and is later used for the data transfer.

> As a workaround, I have tried to call "curl_easy_pause(handle,
> CURLPAUSE_RECV)" in the read function, and then call
> "curl_easy_pause(handle, CURLPAUSE_CONT)" when the body has been read
> completely. But there is a race condition: libcurl may get the
> response code from the server before the read function is called for
> the first time.
>
> It seems to me that I need a new option for libcurl that disables the
> handling of early 401 responses from the server. I can write a patch,
> but I'm not sure what name would fit. IGNORE_EARLY_401, or
> HTTP_EXTERNAL_CONN_AUTH, or ...?
>
> What do you think?

I am not entirely sure what you are trying to do here and if that is possible
with NTLM.

>
> Regards,
> Michael
>
> -------------------------------------------------------------------
> List admin: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html

Greeting,
  Michael
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-06-15