202326 - Unable to Use my client cert to authenticate

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: GRE Core, defect)

Description

[Chandrasekar Kannan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

I used to have my client certificate - that has both
sigining and encryption enabled. this cert has been with me for the last
couple of years.

I upgraded from mozilla 1.3 rtm build to mozilla 1.4 alpha build. 
I could never logon to the web-site mentioned above. 

I was getting an error -5998. 

I then downgraded from mozilla 1.4 alpha to mozilla 1.3.
everything works fine. 

is ssl client auth broken in mozilla 1.4 alpha ?????


Reproducible: Always

Steps to Reproduce:
I used to have my client certificate - that has both
sigining and encryption enabled. this cert has been with me for the last
couple of years.

I upgraded from mozilla 1.3 rtm build to mozilla 1.4 alpha build. 
I could never logon to the web-site mentioned above. 

I was getting an error -5998. 

I then downgraded from mozilla 1.4 alpha to mozilla 1.3.
everything works fine. 

is ssl client auth broken in mozilla 1.4 alpha ?????


Actual Results:  
-5598 nspr error

Expected Results:  
allow ssl client auth to proceed.

Comment 1

[timeless]

this bug doesn't contain anything confidential so i'm clearing the flag.

http://lxr.mozilla.org/nspr/source/nsprpub/pr/include/prerr.h#51
 50 /* The operation would have blocked */
 51 #define PR_WOULD_BLOCK_ERROR                     (-5998L)

Comment 2

[Julien Pierre]

Client auth works for me in moz1.4alpha.
Most of the possible issues you are seeing relate to the internal security
infrastructure of Netscape, and cannot be discussed in a public bug. This is
likely why the bug was opened as confidential. I will send the reporter an email
about it.

Comment 3

[Matthias Versen [:Matti]]

-> PSM

Comment 4

[Julien Pierre]

I discussed the problem with Kannan in person.
Here is the story :
- there were some bogus nss DLLs installed by some (I believe beta) Directory
Server in \windows\system32
- Apparently, mozilla 1.4a is no longer loading NSS from the same location as
mozilla.exe . Instead, the NSS DLLs now live in a separate path . On my machine,
it is 
C:\Program Files\Common Files\mozilla.org\GRE\1.4a_2003040105 .

As a result of this recent mozilla change, the PATH priority went to the NSS
DLLs in SYSTEM32 . For some reason, they were incompatible with Mozilla
1.4alpha, and that caused the failure.

In mozilla 1.3 and earlier, MOZILLA.EXE and the NSS DLLs lived in the same
directory, and therefore Windows was smart enough to load that version rather
than the one from SYSTEM32.

Basically the implicit PATH for DLLs in Windows is :
.;\WINDOWS\SYSTEM32;%PATH%

So the problem here was introduced by moving the NSS DLLs away from MOZILLA.EXE .
Also, Directory Server or other products should not have copied their version of
NSS to \WINDOWS\SYSTEM32 as it is sure to create compatibility problems between
applications, as it did in this case.

I'm not sure if this is something to fix in the Mozilla installer, DS, or both.
If we want to change things in Mozilla and move the NSS DLLs back to were they
were, the component is probably not PSM, but I don't know what it is.

Comment 5

[Matthias Versen [:Matti]]

possible : Browser/Embedding: GRE Core

Comment 6

[Wan-Teh Chang]

Changed product to Browser, component Embedding: GRE Core.

If there are NSS DLLs (nss3.dll, softokn3.dll, ssl3.dll, and
smime3.dll in the Windows "system32" directory, those rather
than the NSS DLLs in GRE will be loaded by Mozilla.

Comment 7

[Chak Nanga]

Cc:ing Doung, Samir and Sean....

Comment 8

[Rich Megginson]

The next version of Netscape Directory Server (6.2) will NOT copy DLLs to the
system32 directory, it will keep copies in the directories where the executables
are.

Comment 9

[Matthias Versen [:Matti]]

*** Bug 202870 has been marked as a duplicate of this bug. ***

Comment 10

[Wan-Teh Chang]

NSPR and NSS are used by products other than the Mozilla
client.  Unfortunately some of them install their NSPR and
NSS DLLs in the system directory (C:\WINDOWS\System32).

Windows searches for DLLs in the following order:
(see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp)
1. The directory from which the application loaded. 
2. The current directory. 
3. The system directory. 
4. The 16-bit system directory.
5. The Windows directory.
6. The directories that are listed in the PATH environment
variable.

The Mozilla client is currently using the PATH environment
variable for loading the GRE.  As you can see from the list
above, the directories listed in the PATH environment
variable is searched *last*, after the system directory.
If there are NSPR or NSS DLLs in the system directory, they
could be loaded instead of the NSPR or NSS DLLs in GRE.

The only ways for GRE users to protect themselves from the
NSPR or NSS DLLs in the system directory are:
1. Put duplicate copies of the NSPR and NSS DLLs in the
application directory.  This wastes disk space and we need
to keep the duplicate copies in sync with the GRE, but it
is the safest solution because the application directory is
always searched first.  Note that there are already duplicate
copies of NSPR DLLs in Mozilla's application directory, which
is why we have only seen reports of the wrong NSS DLLs being
loaded.
2. Change its current directory to the GRE directory before
it loads GRE.  This solution requires that the application
not change its current directory later because the NSS
DLLs are not loaded until they are needed.
3. GRE installs the NSPR and NSS DLLs in the system directory.
This solution will open its own can of worms and should only
be considered as the last resort.

I think this bug should block Mozilla 1.4 final.

Comment 11

[Doug Turner (:dougt)]

I am not sure which solution is the best.  

Which apps are putting nspr and nss in the system directory?  I thought that
this was generally frowned on. 

Comment 12

[Matthias Versen [:Matti]]

Dougt: see comment#8...

Comment 13

[Doug Turner (:dougt)]

so, if you are running old versions of "Netscape Directory Server" on windows,
there is a problem?  i didn't know that there was a windows version of "Netscape
Directory Server".

We could have an option for customers with these kind of applications such that
the mozilla installer will not use a "GRE" directory and instead copy all dll's
into the application's directory.

Comment 14

[Wan-Teh Chang]

We have no control of all the current and future
NSPR and NSS users.  If any of them puts NSPR or
NSS DLLs in the system directory (which seems to
be a common practice on Windows), GRE users are
screwed.  GRE users need to implement a self
defense against this problem.  Otherwise, it'll
be a source of bug reports and support costs.

Comment 15

[Doug Turner (:dougt)]

I added experimental support for XPCOM components to declare what libraries it
depends on.  The notion would be that these "required" libraries would be opened
prior to the xpcom component library being loaded.  An another approach would be
to leverage this work such that if a xpcom component required a dll, xpcom could
load (LoadLibarry) before loading the xpcom component.

In our example, prior to the nss-xpcom-component being loaded, xpcom would load
the NSS library from the proper place (namely the GRE or application directory).

Comment 16

[Doug Turner (:dougt)]

note that most of this "dependent libarary" functionality is in 1.4a.  The
remaining steps would be to modify the generic module implementations and to
hook up the DEPENDENT_LIBS build define again.

See 193442.

Comment 17

[Asa Dotzler [:asa]]

Is this likely to affect any significant number of users? If it's just folks
that installed directory server on windows, that seems like a pretty small
group. What kind of timeframe would we be looking at to implement self defense?
Could it be done in a way that was low enough risk to take into final (but not
beta)? If not and if we must have this for 1.4 then we need to get it
prioritized and fixed ASAP. 

Comment 18

[Doug Turner (:dougt)]

This is a major problem.  If 1.4 is going to be a long lived branch, the
likelyhood of a user running into this problem is high.  I think that we can fix
this problem by fixing 193442.

Comment 19

[Asa Dotzler [:asa]]

Doug, 193442 (or part of it) has landed. Does this bug need more for 1.4 or does
193442 still need more?

Comment 20

[Doug Turner (:dougt)]

only part of 193442 has landed.  working on the last part today.  if it goes
well, i will seek checkin permission.

Comment 21

[Doug Turner (:dougt)]

I checked in a fix for this bug.  Can you please verify with tomorrow's mozilla
build?

Comment 22

[Wan-Teh Chang]

Doug, this bug isn't fixed by your checkin.

You can reproduce this bug by copying nss3.dll, ssl3.dll,
and smime3.dll from /share/builds/components/nss/NSS_3_3_2_RTM/WIN954.0_OPT.OBJ/lib
(on the Netscape network) to C:\Windows\System32 on your PC.

Comment 23

[Doug Turner (:dougt)]

It looks like passing the PR_LD_GLOBAL flag to PR_LoadLibraryWithFlags is
ingored on windows.  Does windows support something like RTLD_GLOBAL?

Comment 24

[Doug Turner (:dougt)]

looks like there was a windows 98 regression so I am going to back out my
attempt to fix this bug.  Maybe we can use a variation on 202363 and set the cwd
to not the application directory, but the gre dir?  hmm... i don't like it at all.

Comment 25

[Doug Turner (:dougt)]

i guess one way to fix this now is to use the AppPath registry.  Using this key
modifies the dll search order [1].  

Sean, how hard would be be to poke the AppKey registry key?

[1] http://codeguru.earthweb.com/dll/AppPath.shtml

Comment 26

[Doug Turner (:dougt)]

nevermind that comment about AppKey.  I don't think it will work for us since
AppKey is per application name, not application name+path.

Comment 27

[Asa Dotzler [:asa]]

moving nomination forward.

Comment 28

[Doug Turner (:dougt)]

*** Bug 204888 has been marked as a duplicate of this bug. ***

Comment 29

[Michael Buckland]

Discussed in edt bug triage.  Plussing.

Comment 30

[Matthias Versen [:Matti]]

*** Bug 206592 has been marked as a duplicate of this bug. ***

Comment 31

[Doug Turner (:dougt)]

Wan-Teh and I discussed the possible fixes for this bug.  We have proved the
more graceful solutions to fail to fix the problem.  

The current solutions are as follows:

1.  

Embedding applcation must ship their own copy of NSS and NSPR.  That is, NSS and
NSPR are outside of the GRE.  Currently NSPR is already in the application
directory since the default GRE bootstrap code requires NSPR.  This fix would
require that the install copy the NSS dll's into the applications directory
instead of the GRE directory (or in both places to allow a client to copy these
dll's into their own applications directory)

2.

Ignore the problem on anything but XP SP1 and use SetDLLDirectory to ensure the
correct search path is being used.  

2a. 

We could ship a simple tool along with mozilla that could find the GRE and copy
the NSS dlls into the application directory.

Comments?

Comment 32

[Rich Megginson]

We took approach 1) for Netscape Directory Server 6.2.  It increases the size of
the package because we need as many as 4 copies of each DLL depending on where
the executables are that need them.  But as plentiful as disk space is for
server products, this does not affect our customers much, if at all.

Comment 33

[Wan-Teh Chang]

I think solution 1 is the best solution.  On Windows an
embedding application's installer can copy the NSS and
NSPR DLLs from the GRE directory to the application
directory.

Comment 34

[Doug Turner (:dougt)]

this is now an installer issue.

Comment 35

[Sean Su]

Attachment: patch v1.0

This patch will have mfcembed and mozilla all copy the following files:
  nss3.dll
  softokn3.dll
  ssl3.dll
  smime3.dll

from the GRE's installation path.  This copy is done *after* the products
finished installing, which means that if each of the products contained their
own copies of those files, they would be overwritten by the ones in the GRE
dir.

These files will also be cleaned up at uninstall time.

Comment 36

[Doug Turner (:dougt)]

Comment on attachment 124505 [details] [diff] [review]
patch v1.0

The comment in win_mfcembed/config.it is wrong.

This "looks" right.

Comment 37

[Sean Su]

Attachment: patch v1.1

fixed comment in mfcembed.

Comment 38

[Sean Su]

Comment on attachment 124511 [details] [diff] [review]
patch v1.1

got r=dougt
seeking sr= now

Comment 39

[Daniel Veditz [:dveditz]]

Comment on attachment 124511 [details] [diff] [review]
patch v1.1

sr=dveditz if you include softokn3.chk as well (per wtc).

We don't need nssckbi.dll because that's explicitly loaded by path and should
come from the GRE directory.

Comment 40

[Sean Su]

Attachment: patch v1.2

added softokn3.chk to the list of files needing to be copied over.

Comment 41

[Sean Su]

Comment on attachment 124517 [details] [diff] [review]
patch v1.2

moving r=,sr= to this patch.
seeking a=
The patch is trivial, and already verified that it works on win32.

Comment 42

[(not reading, please use [e-mail] instead)]

Comment on attachment 124517 [details] [diff] [review]
patch v1.2

a=sspitzer

ssu tells me that users who hit this can't hit https sites, that's blocker
worthy for 1.4

Comment 43

[(not reading, please use [e-mail] instead)]

wanted for trunk and branch.

when you land on branch, please add fixed1.4 keyword, so QA knows about it.

Comment 44

[Sean Su]

I should clerify that what works about the patch is the copying of the files.

Comment 45

[Sean Su]

patch checked in to:
 mozilla trunk
 mozilla branch
 ns trunk
 ns branch