provide cross-platform NTLM auth implementation

RESOLVED FIXED in mozilla1.6beta



16 years ago
16 years ago


(Reporter: darin.moz, Assigned: darin.moz)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment, 1 obsolete attachment)



16 years ago
this bug is about providing a cross-platform NTLM auth implementation that will
live in PSM (it leverages NSS) and can be used to provide NTLM auth for HTTP,

the implementation is based on

i filed this bug in an attempt to avoid the massive cc list of bug 23679... 
please do not mark this bug as a duplicate.  i'm hoping to get this in before
folks on that cc list get a chance to spam this bug.

Comment 1

16 years ago
Posted patch v1.0 patch (obsolete) — Splinter Review

Comment 2

16 years ago
to summarize:

  o  this patch moves the NTLM authentication behind a new interface, called
     nsIAuthModule.  that interface defines a simple contract for challenge/
     response based authenticator.  the NTLM authenticator is implemented in
     PSM so that it can leverage NSS crypto functions (DES_ECB and MD5).

  o  the NTLM hash requires the MD4 algorithm.  since NSS does not provide MD4,
     the patch includes a clean (from spec) MPL'd MD4 implementation.  the code
     for MD4 is pretty small and straightforward (if you have the spec in front
     of you!).

  o  this patch adds support for sending either: LMv1 + NTLMv1 _or_ the NTLM2 
     session response.  there is no support for LMv2 or NTLMv2 since those modes
     cannot be negotiated (they must be manually configured on the client and
     server).  i will implement those modes if we discover cases where those are 
     required.  in all cases, the NTLM2 session response, if negotiated 
     successfully, is preferred over even LMv2 or NTLMv2, so i feel that it is 
     most useful to have NTLM2 session response supported and less useful to 
     support LMv2 and/or NTLMv2.
  o  i have discarded the NTLM SSPI code.  i think we are better off using our
     own code for NTLM authentication.  the reason for this is simple.  on older
     clients, like Win9x, only the LMv1 response is generated by SSPI.  that is
     the least secure way of encrypting the user's password.  it is definitely a
     good idea to use our code on Win9x since it gives us the opportunity to
     authenticate the user w/ a NTLM2 session response.  also, SSPI has been a
     source of mysterious crashes on Win9x (see bug 222849 for example).  
     moreover, older versions of WinNT do not support the NTLM2 session 
     response, so we are better off on some versions of WinNT if we use our 
     code.  ah!  but, the tradeoff is that we may need to implement LMv2/NTLMv2
     if a site is configured to only allow those modes of authentication.

  o  i've added netwerk/test/ReadNTLM.cpp, which is a simple little program that
     decodes the NTLM messages.  this is useful for debugging a NTLM session,
     and for figuring out what IE and SSPI are doing ;-)

  o  i've decided to keep the base64 encoding/decoding in nsHttpNTLMAuth.cpp. 
     i was tempted to put it inside the NTLM auth module (since all of the 4
     protocols i previously mentioned need the NTLM messages to be base64 
     encoded).  but, i think the base64 encoding belongs closer to the protocol
     implementations since the encoding is a protocol dependent aspect.  plus,
     i can eliminate a buffer copy by keeping the base64 encoding in HTTP land.
     for the mail protocols, we can try to share the code for base64 encoding/

  o  i removed the remnants of the LanManager single singon code since we 
     weren't using it anyways.  (i.e., we always prompt the user at least once 
     for their username and password.)

lastly, i've tested this against 1) a Win2k server and 2) a Squid proxy
configured to use winbindd to authenticate with a NT domain server (Samba in my
testcase).  and, i've tested this code under Win2k and Linux.  there may be
issues on big-endian platforms (such as OSX).  i have not yet tested this code
on OSX.  that's next on my list ;-)


16 years ago
Severity: normal → enhancement
Target Milestone: --- → mozilla1.6beta


16 years ago
Blocks: 200436
Comment on attachment 134744 [details] [diff] [review]
v1.0 patch

r=kaie on the changes to existing files in security/manager/ssl

I'm giving a general moa=kaie on adding the new nsNTLMAuth* and md4* files to
security/manager/ssl, because the new service you are adding is self contained.

Please note that NTLM authentication will remain to be active in the session,
if the user activates FIPS mode. A restart is required to disable NTLM. You
should make sure this is compliant with FIPS requirements, or find a way to
disable NTLM at the same time FIPS gets activated.

Regarding the use of PK11_ functions, please make sure that you are cleaning up
NSS resources correctly, in order to not break the "switch profile at runtime"

For example, I do not see a call to PK11_FreeSlot, but I think you need to.

Comment 4

16 years ago
thanks for catching those mistakes kai!

  o  i'll add a PK11_IsFIPS() check in GetNextToken to have it fail if FIPS mode 
     has been enabled.

  o  and thanks for noticing the missing PK11_FreeSlot

Comment 5

16 years ago
Attachment #134744 - Attachment is obsolete: true


16 years ago
Attachment #135210 - Flags: superreview?(bryner)
Comment on attachment 135210 [details] [diff] [review]
v1.1 patch - revised per comments from kai

r/sr=bryner with the changes we discussed.
Attachment #135210 - Flags: superreview?(bryner) → superreview+
Thanks for the new patch, Darin!
My r=kaie/moa=kaie still stands.

Comment 8

16 years ago
patch checked in for 1.6 beta :)
Last Resolved: 16 years ago
Resolution: --- → FIXED


16 years ago
Blocks: 152883


16 years ago
Blocks: 23679

Comment 9

16 years ago
According to brad TBox, there are two "might be uised uninitialized" warnings in
the new code:

+ `PRUint32 inBufLen' might be used uninitialized in this function

+ `SECItem*param' might be used uninitialized in this function

Comment 10

16 years ago
aleksey: thanks for the notice!


16 years ago
Blocks: 222849

Comment 11

16 years ago
i applied a fix for those warnings.  thanks again aleksey!

Comment 12

16 years ago
Hi, which CVS branch are these fixes in?  Would they have been built into the
latest nightlies?

Manik: only on HEAD. yes, nightlies contain it.

Comment 14

16 years ago
I know this one is resolved, but is there a reason why this couldn't be extended
to NNTP authentication in addition to HTTP, SMTP, IMAP and POP3?
You need to log in before you can comment on or make changes to this bug.