Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Fri, 27 Feb 2015 19:13:05 +0000 (UTC)
From: "Jason Forand (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12778019.1424985728000.36741.1425064385035@Atlassian.JIRA>
In-Reply-To: <JIRA.12778019.1424985728000@Atlassian.JIRA>
References: <JIRA.12778019.1424985728000@Atlassian.JIRA>
 <JIRA.12778019.1424985728663@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1624) NTLMresp in type3message is
 being generated wrong when using NEGOTIATE_NTLM2_KEY
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14340639#comment-14340639 ] 

Jason Forand commented on HTTPCLIENT-1624:
------------------------------------------

Hi Karl,

Let me know how best I can help you. I can tell you that if you are only using NTLM authentication, the code in the NTLMEngineImpl works as is. I have two guesses as to why this might be. The first guess is that the windows host doesn't actually check the contents of the ntlm response. The second guess is that if you have a windows host that requires sealed messages (which at present isn't supported), then that host will send the NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag. 

I have tested on two windows hosts (windows 7 and windows 8), and when the flags 

NEGOTIATE_UNICODE = 1
REQUEST_TARGET = 1 << 2
NEGOTIATE_SIGN = 1 << 4
NEGOTIATE_SEAL = 1 << 5
NEGOTIATE_NTLM = 1 << 9
NEGOTIATE_ALWAYS_SIGN = 1 << 15
TARGET_TYPE_SERVER = 1 << 17 (or TARGET_TYPE_DOMAIN = 1 << 16)
NEGOTIATE_NTLM2_KEY = 1 << 19
NEGOTIATE_TARGET_INFO = 1 << 23
UNKNOWN_4 = 1 << 25
NEGOTIATE_128 = 1 << 29
NEGOTIATE_KEY_EXCHANGE = 1 << 30
NEGOTIATE_56 = 1 << 31

are received in the type 2 message, then the value that is placed in the ntlmresponse field is rejected by the host. Unfortunately I don't have access to a wide variety of windows machines. I'm trying to get my hands on a few more, and I will update you as I get results. At the moment, I can provide you with wireshark files of both successful and unsuccesful connections. 

I think that the ntlmresponse needs to change when

NEGOTIATE_SIGN = 1 << 4
NEGOTIATE_SEAL = 1 << 5
NEGOTIATE_NTLM2_KEY = 1 << 19
NEGOTIATE_KEY_EXCHANGE = 1 << 30

are present. Since you guys don't support sealing, NEGOTIATE_KEY_EXCHANGE would never have appeared in your testing.

> NTLMresp in type3message is being generated wrong when using NEGOTIATE_NTLM2_KEY
> --------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1624
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1624
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpAuth
>    Affects Versions: 4.3.6, 4.4 Final
>         Environment: Running from a linux box, connecting to a windows 7 machine.
>            Reporter: Jason Forand
>            Assignee: Karl Wright
>         Attachments: wireshark_400.pcapng
>
>
> When connecting to a windows host using NTLM authentication, if the windows host passes back the 
> NEGOTIATE_UNICODE
> REQUEST_TARGET
> NEGOTIATE_SIGN
> NEGOTIATE_SEAL
> NEGOTITATE_LAN_MANAGER_KEY
> NEGOTIATE_NTLM
> NEGOTIATE_ALWAYS_SIGN
> TARGET_TYPE_DOMAIN
> NEGOTIATE_NTLM2_KEY
> NEGOTIATE_TARGET_INFO
> UNKNOWN_4
> NEGOTIATE_128
> NEGOTIATE_KEY_EXCHANGE
> NEGOTIATE_56
> flags, (in this case the offending flag is NEGOTIATE_NTLM2_KEY) the type3 message is generating an ntresp using 
> http://davenport.sourceforge.net/ntlm.html#theNtlmv2Response when it should be generating according to http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse 


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org