hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Forand (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1624) NTLMresp in type3message is being generated wrong when using NEGOTIATE_NTLM2_KEY
Date Fri, 27 Feb 2015 19:13:05 GMT

    [ 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


Mime
View raw message