cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with NTLM authentication to an HTTPS site

Jump to solution

Hello,

I am trying to connect through the Web Gateway to an https site (using grizzly library). I can see that the ntlm dancing occurs (message type 1, message type 2 and message type 3). But when the target site is an HTTPS I receive a 407 error (authorizationrequired) after message type 3. For what I can tell the NTLM messages are correcty.

This does not occur if the target site is HTTP. The difference is that the NTLM headers are send through the CONNECT http command.

I attach the tcpdumps for a http and https (one is listening to the port 9090 when the target site is an HTTP site and the other one is when the target site is HTTPS).

This issue does not occur when I try to connect to a Https site through an http proxy in an ISA Server.

Thanks in advance for any help.

Fabian

0 Kudos
1 Solution

Accepted Solutions
McAfee Employee

Re: Problem with NTLM authentication to an HTTPS site

Jump to solution

Hi Fabien,

The problem is that in the HTTPS capture, the type 3 (authenticate) is sent in a different connection from the type 2 (challenge).

In the HTTP capture, type 1 (negotiate), type 2 (challenge), type 3 (authenticate) all occur in the same connection. This is how NTLM is supposed to work.

In the screenshots below, I color coded the connections (ctrl+1-9 in wireshark).

If needed you could bypass based on the user-agent (AHC/1.0) or destination (postman-echo.com).

Best Regards,

Jon

0 Kudos
3 Replies
McAfee Employee

Re: Problem with NTLM authentication to an HTTPS site

Jump to solution

Hi Fabien,

The problem is that in the HTTPS capture, the type 3 (authenticate) is sent in a different connection from the type 2 (challenge).

In the HTTP capture, type 1 (negotiate), type 2 (challenge), type 3 (authenticate) all occur in the same connection. This is how NTLM is supposed to work.

In the screenshots below, I color coded the connections (ctrl+1-9 in wireshark).

If needed you could bypass based on the user-agent (AHC/1.0) or destination (postman-echo.com).

Best Regards,

Jon

0 Kudos

Re: Problem with NTLM authentication to an HTTPS site

Jump to solution

Thank you very much, Jon.

That's the problem. Grizzly verifies that the keep-alive is not present in the response so it creates a new connection. Shouldn't the keep-alive be included in the challenge message?

Thanks!

0 Kudos
McAfee Employee

Re: Problem with NTLM authentication to an HTTPS site

Jump to solution

Hi Fabian,

The MWG is sending a Proxy-Connection: Keep-alive header in the Challenge response, despite this, the app still opens a new connection to send the Authenticate step.

Best Regards,

Jon

0 Kudos