Thanks for the notes, it has been quite some time since I worked on the actual NTLM protocol details so my memory of how it all works is very foggy. Your suggestions sound good but it is going to take me quite a while to turn them into a patch. If you would be so kind as to look into making up a patch yourself that would be hugely appreciated, otherwise I'll leave it on my list of things to do for HttpClient and hopefully get to it in the not too distant future.
Sorry it's taken me so long to get back to you on this. Very hectic few weeks around here. :)
Regards,
Adrian Sutton.
On Friday, July 4, 2003, at 01:57 PM, Eric wrote:
Hello,
I had a couple of notes on the HttpClient NTLM implementation that might be useful to you guys (I posted a message a couple weeks back about the NTLM documentation I put together, and have since had a chance to look over the HttpClient code):
There are a few streamlining items you could apply to the Type-1 message. The flags currently specified (big-endianized, so these are backwards from the as-coded representation) are:
0x00000002 Negotiate OEM (ASCII, basically) 0x00000004 Request Target 0x00000200 Negotiate NTLM 0x00008000 Negotiate Always Sign
Request Target is used for NTLMv2 authentication (to request the target's authentication realm). Negotiate Always Sign is used to request dummy signatures on the established secure session; HTTP only uses NTLM for authentication, not session security. The only flags you really need to set are Negotiate OEM (or, alternatively, Negotiate Unicode, 0x00000001) and Negotiate NTLM (which is always set).
Also, you don't have to include the hostname and domain in the Type-1; in fact, the server won't know that you sent them unless you also set:
0x00001000 Negotiate Domain Supplied 0x00002000 Negotiate Workstation Supplied
The host and domain in the Type-1 message are used by the server to determine if local authentication is available (which would require native code to implement). If you factor those out, and just set the basic flags, the Type-1 message becomes a constant:
4e 54 4c 4d 53 53 50 00 // NTLMSSP\0 01 00 00 00 // Type 1 02 02 00 00 // Flags
The same flags would apply in the Type-3 message, but you don't have to send them; the flags in the Type-3 aren't used in connection-oriented NTLM authentication, and older clients omit both the flags and the "session key" field (starting the field data at offset 52 instead of 64). Also, you might want to add a "convertLong" method to output a 4-byte little-endian value; while the length elements are 16-bit, the offsets are actually 32-bit values (instead of a 16-bit value padded with 2 zero bytes).
Anyhow, just some thoughts; feel free to consider or ignore them as you see fit ;)
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
