106526 - N620 Problems with SSL with FIPS enabled. [@ PK11_DestroyContext]

Status: VERIFIED FIXED

(NSS :: Libraries, defect, P1)

Description

[John Unruh]

10/22 Final 6.2 branch build.
1.) Edit>Prefs>Security>Certs>Manage Devices.
2.) Enable FIPS, click OK and OK.
3.) Use the above test page.
What happens: 
Linux and Win2000: Crash when visiting SSL2-only site. Other sites are OK.

Mac OSX and Win98: Crash when visiting SSL2-only site. SSL3-only gives -SSL 
error -12204. Other sites like https://www.verisign.com it cannot reach. 

On http://cyclone, search for [e-mail] for stack trace.

Comment 1

[Stephane Saux]

P1
->Kai
cc relyea, nelsonb

Comment 2

[Stephane Saux]

John,
  I enabled FIPS and was able to visit aka, https://www.verisign.com.
  This is using a special build off the 0.9.4 branch (close to the tip).

  Using win2000

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Sigh.  PSM clearly needs to to a better job of reporting error strings
instead of error numbers for NSS and SSL errors.  

Error -12204 is SSL_ERROR_TOKEN_SLOT_NOT_FOUND.  The English string for 
this error code is 
"No PKCS#11 token could be found to do a required operation."

Remember that when FIPS is enabled, the software token can ONLY do FIPS
algorithms.  It cannot do non-FIPS algorithms, such as RC4 or MD5.  
So, if one visits a web site that can only do SSL ciphersuites that
use non-FIPS algorithms, one would expect failure.  If the SSL protocol
negotiated a non-FIPS ciphersuite between client and server, then it 
would fail at the point that it attempted to use a non-FIPS algorithm.
When the only tokens available are FIPS tokens, then the SSL code should
disable all the non-FIPS ciphersuites.  It is possible that the logic to
do that disabling is not working correctly.

And, a crash is never appropriate.  Since SSL2 has NO FIPS ciphersuites,
SSL2 should be disabled when in FIPS mode.

Comment 4

[Robert Relyea]

1) SSL2 is not supported in FIPs mode. It should not crash, however.

I looks like the problem is in ssl3_CreateSessionCypher() in sslcon.c. If we
don't set up the connection, the routine will free the session contexts, but not
null out the destructor. When we later try to free the sslSecurityInfo, we see
we have the destructor set and think we need to free the contexts, but we can't.

I've included an untested patch which should cause the crash to go away.

2) One of the things FIPs mode was supposed to do is turn on the FIPs only
ciphers and turn off everything else. If that is true, many sites will not be
available, but this should be consistant on all platforms, so the SSL3 issue
still needs to be investigated (the included patch will not help).

Comment 5

[Robert Relyea]

Attachment: patch to mozilla/security/nss/lib/ssl/sslcon.c to fix crashes on ssl2 failures

Comment 6

[Stephane Saux]

stack trace:
PK11_DestroyContext()
ssl_DestroySecurityInfo()
ssl_FreeSocket()
ssl_DefClose()
ssl_SecureClose()
SSL_ImportFD()
nsSSLIOLayerClose
[d:\builds\seamonkey\mozilla\security\manager\ssl\src\nsNSSIOLayer.cpp, line 571]
PR_Close [../../../../pr/src/io/priometh.c, line 132]

talkback numbers:
 37132951
 37132934
 37131521
 37131308
 37131226
 37131096
 37130737

Comment 7

[Kai Engert (:KaiE:)]

Bob's patch prevents the crash.

Comment 8

[lchiang]

When did this failure (crash) first show up?

Comment 9

[John Unruh]

This bug could have existed for a long time. You need a profile without a master 
password setup, and you need to encounter that rare server that is running SSL2 
only. I'll add this to the FIPS test plan.

After discovering that one Win98 profile COULD reach SSL sites with FIPS 
enabled, I found that the difference between the two profiles is that one had 
a master password setup, and the failing profile did not. Mac OSX and Win98 (and 
all other platforms) can now reach most normal SSL sites. The trick is to 
first setup a master password. So the workaround for FIPS users, that should be 
release noted, is to:
1.) Disable SSL2 to prevent a crash.
2.) Setup a master password.

Comment 10

[Robert Relyea]

The code that caused the problem is fairly old. I would not be surprised if you
could get Comm 4.7 to crash under similar conditions. FIPs mode users usually
have SSL2 turned off, so it's not surprising the bug has not surfaced.

bob

Comment 11

[Kai Engert (:KaiE:)]

We have created PSM bug 106587 for the "force master password set" issue.

We have created PSM bug 106604 to disabled SSL2 ciphers.

I'm changing the component of this bug to NSS. Will you land it on the NSS
client branch?

Comment 12

[greer]

Adding the signature to the summary and KW: crash to help talkback

Comment 13

[greer]

Updating the summary and cc'ing talkback.

Comment 14

[Robert Relyea]

No, We don't mess with the client branches. We can land it into any standard NSS
branch, though I only intend to land it in the NSS tip for NSS 3.4.

bob

Comment 15

[Kai Engert (:KaiE:)]

Ok, unless you object, I can check it in to NSS_3_3_BRANCH and update the
NSS_CLIENT_TAG.

Comment 16

[Kai Engert (:KaiE:)]

Patch checked in to NSS_3_3_BRANCH, now visible to Mozilla.

Comment 17

[Wan-Teh Chang]

Kai, if the fix for this bug has been checked in,
could you mark it fixed?

I assume you also checked in the fix on the tip of
NSS?

Comment 18

[Kai Engert (:KaiE:)]

I have not checked it in, but the change is already in the trunk, I guess Bob
did it.

Marking this fixed.

Comment 19

[John Unruh]

Verified.

Comment 20

[Jay Patel [:jay]]

Where exactly was this fixed?  I still see crashes with the official Netscape
6.20 release...so I'm guessing the fix didn't make it into the final release
bits, right?

Comment 21

[Kai Engert (:KaiE:)]

The bug was discovered after 6.2 final was shipped.

The fix is in the tip of NSS and also in the NSS version used by the tip of Mozilla.

Comment 22

[John Unruh]

The workaround is release noted.
1.) Disable SSL2 to prevent a crash.
2.) Setup a master password.

Comment 23

[Dawn Endico]

removing item for this fixed bug from mozilla 0.9.6 release notes.