cURL / Mailing Lists / curl-library / Single Mail


Re: Problem with NTLM proxy authentication

From: Ulrich Telle <>
Date: Tue, 09 Sep 2014 23:31:19 +0200

thanks for taking the time to further investigate this problem.

> On Fri, 05 Sep 2014, Ulrich Telle wrote:
> > I manually checked the NTLM Type-2 message received from the
> > proxy server - one case where the call to InitializeSecurityContext
> > failed,and one where it was successful.
> Where these on the same proxy server?

No. However, they are both hosted by the same provider.

> 1a) If not, what software was each proxy server running and are they
> on different domains?

They are on different domains. However, as far as I know on both proxy servers the same software, McAfee Web Gateway, is running.

> 1b) If so, what was the difference in the users credentials (domain,
> permission groups, etc...) and were the users from the same machine or
> from different machines?

All different.

> 2a) If they were different machines. are the machines on different
> domains or running different versions of the OS?

Different domains; same OS version.

> > I don't believe that the challenge token was corrupted in transit.
> > So maybe not the proper security package was negotiated.
> Me neither... from my experience Windows SSPI tends to give that
> when it doesn't like something in the message that you give it - it's
> unfortunately a little bit too generic in that sense :(

It is really strange that Windows SSPI doesn't work for my application and the users in that one company. It is even stranger, because the user I'm in contact with to perform the tests has no problem to access the Internet using his FireFox browser. And as far as I know FireFox uses Windows SSPI, too.

I intend to analyze the NTLM handshake of FireFox with the proxy server. I will have an opportunity to do so on Thursday. Maybe this can give additional hints.

At least I already found out within my own company, that the NTLM handshake messages look a bit different if done from FireFox than if done from my own application.

Here are the flags in the Type-1 message:

FireFox:  A2 08 82 07
#define NTLMSSP_NEGOTIATE_OEM 0x00000002
#define NTLMSSP_REQUEST_TARGET 0x00000004
#define NTLMSSP_NEGOTIATE_NTLM 0x00000200
#define NTLMSSP_NEGOTIATE_NTLM2 0x00080000
#define NTLMSSP_NEGOTIATE_128 0x20000000
#define NTLMSSP_NEGOTIATE_56 0x80000000

My application: E2 08 B2 B7
#define NTLMSSP_NEGOTIATE_OEM 0x00000002
#define NTLMSSP_REQUEST_TARGET 0x00000004
#define NTLMSSP_NEGOTIATE_SIGN 0x00000010
#define NTLMSSP_NEGOTIATE_SEAL 0x00000020
#define NTLMSSP_NEGOTIATE_LM_KEY 0x00000080
#define NTLMSSP_NEGOTIATE_NTLM 0x00000200
#define NTLMSSP_NEGOTIATE_NTLM2 0x00080000
#define NTLMSSP_NEGOTIATE_128 0x20000000
#define NTLMSSP_NEGOTIATE_56 0x80000000

No idea, what triggers this different set of flags.

One difference I see in the source code of the SSPI authentication module of FireFox is that SSPI function InitializeSecurityContext is called without any of the flags libcurl is using:


And maybe FireFox sends additonal HTTP headers, which my application does not send, but that are taken into account by the proxy server. (Of course this is just wild guessing.)

> > I'm not an expert for NTLM or Windows security. So I'm still at a loss, what
> > causes the observed authentication problems.
> Me too and apologies for all the questions but I expect Windows SSPI
> just to work.

Me too. And within my own company it does. So there doesn't seem to be an obvious problem in the code of libcurl.

> If there were ONLY problems with the "native" libcurl NTLM code base
> and not the SSPI code then I would say we have something wrong with
> our message encoding level, flags or something else but it seems weird
> that the SSPI code should fail this way.

Maybe we just miss a subtle detail.

> Is there any chance you can try a non-SSPI build of libcurl prior to
> v7.36 (Which is when we added native support for NTLMv2)?

That is, you'd like to see the results if libcurl forces to not use NTLMv2.

Not impossible, but it will take some time.

Is there a way to force SSPI to not use NTLMv2?

> I think Daniel mentioned it in his email but I am wondering if, after
> searching around the web, if the proxy server has issues with NTLMv2
> authentication.

Could be. I hope this will get clearer after I checked the NTLM handshake as done by FireFox in the user's company.


E-Mail privat:
World Wide Web:


List admin:
Received on 2014-09-09