NSS crashes when doing an OCSP certificate verification. See bug 173711 for a test case and stack trace.

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

Marking P1. In the stack trace in http://bugzilla.mozilla.org/attachment.cgi?id=102442&action=view it appears at first glance that ocsp_ConnectToHost called PR_Connect with a bogus net address and/or port number. PR_Connect asserts. Maybe it shouldn't do that, but neither should NSS be passing bogus netaddrs.

When OCSP is enabled I do not see a crash, however, I do see the following error when connecting to almost all https servers. Error establishing an encrypted connection to foo.bar.com. Error Code: -5985. Examples of problematic servers include https://commcenter.attbi.com and https://www.novusnet.com. The Yahoo! secure signon option and the EBay secure signon do not trigger the above message. Enable OCSP via Edit menu, Preferences..., Privacy & Security, Validation, "Use OCSP to validate only certificates that specify an OCSP service URL". The -5895 error occurs with Mozilla 1.4beta, rc1, rc3 and 1.4 final. The newest version I've used to reproduce this is (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624). The error number corresponds to PR_ADDRESS_NOT_SUPPORTED as defined in prerr.h (-5895L). Setting the env vars NSPR_LOG_MODULES=all:5 and NSPR_LOG_FILE=/tmp/moz.log provided some additional logging info in moz.log.

Whoops - a couple of typos above. The correct error number is -5985 as in (-5985L) in prerr.h.

Error text is defined in SSLGenericError: http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/resources/locale/en-US/pipnss.properties#189 nsNSSIOLayer.cpp prints SSLGenericError w/ value PR_ADDRESS_NOT_SUPPORTED_ERROR http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSIOLayer.cpp#833 and PR_ADDRESS_NOT_SUPPORTED_ERROR is used in these locations too: http://lxr.mozilla.org/seamonkey/ident?i=PR_ADDRESS_NOT_SUPPORTED_ERROR

Mark, I'm not sure what comment 5 has to do with NSS. Are you proposing PSM changes in addition to NSS changes? If so, please file a PSM bug. Thanks.

The stack trace shows that 'hostIndex' was 0 and 'addr' was all zeros, which was done by the memset(,0,) call in PR_EnumerateHostEnt. I concluded this is what happened. 1. The OCSP responder was down, so PR_Connect to all of its IP addresses failed. 2. Eventually PR_EnumerateHostEnt returned 0, indicating the end of the IP address enumeration. Here is the bug: we should exit the do-while loop when PR_EnumerateHostEnt returns 0, WITHOUT using 'addr'. In other words, a return value of 0 means we have stepped BEYOND the end of the IP address list; it doesn't mean 'addr' is the last IP address on the list. I have seen this bug in some other code before, so I think the documentation of PR_EnumerateHostEnt needs to be more clear about this point. The fix is to exit the loop when PR_EnumerateHostEnt returns 0, without doing the PR_Connect to 'addr'.

Comment on attachment 134041 [details] [diff] [review] Proposed patch This patch does what wan-teh describes.

I've checked in this patch on the NSS trunk for NSS 3.9. Julien, how do I test OCSP using Mozilla? I will mark this bug fixed after I have tested the modified code.

Wan-Teh, 1. Go to Edit/Preferences/Privacy & Security/Validation and select "Use OCSP to validate only certificates that specify an OCSP service URL". Validate out of preferences 2. go to Edit/Preferences/Privacy & Security/Certificates/Manage Certificates 3. double-click on some certs that you know have been revoked (eg. some of your own if you renewed your cert recently with certificates.netscape.com) 4. it should say on top "could not verify this certificate because it has been revoked" Unfortunately, PSM disables OCSP before drawing the "Manage certificates" window for performance reasons, so you can't immediately see which certs are revoked. You have to click on each one. If you had a CRL, you would see <Revoked> under purposes because CRL processing is never disabled.

Wan-Teh, was this bug fixed in NSS 3.9? Your comment 9 suggests so.

Marked the bug fixed. The fix is in NSS 3.9.