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 firstname.lastname@example.org for stack trace.
P1 ->Kai cc relyea, nelsonb
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
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.
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).
Created attachment 54929 [details] [diff] [review] patch to mozilla/security/nss/lib/ssl/sslcon.c to fix crashes on ssl2 failures
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
Bob's patch prevents the crash.
When did this failure (crash) first show up?
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.
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
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?
Adding the signature to the summary and KW: crash to help talkback
Updating the summary and cc'ing talkback.
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
Ok, unless you object, I can check it in to NSS_3_3_BRANCH and update the NSS_CLIENT_TAG.
Patch checked in to NSS_3_3_BRANCH, now visible to Mozilla.
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?
I have not checked it in, but the change is already in the trunk, I guess Bob did it. Marking this fixed.
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?
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.
The workaround is release noted. 1.) Disable SSL2 to prevent a crash. 2.) Setup a master password.
removing item for this fixed bug from mozilla 0.9.6 release notes.