140247 - OCSP: Mozilla freezes when trying to view digitaly signed message.

Status: RESOLVED FIXED

(MailNews Core :: Security: S/MIME, defect, P2)

Description

[Tjibbe Steneker]

When trying to view a digitaly signed message on usenet with mailnews, Mozilla
freezes.

I have Mozilla set to use OCSP to validate only messages that specify an OCSP
service URL.

Steps to reproduce

In Preferences: go to Privacy & Security - Validation
set: Use OCSP to validate only messages that specify an OCSP service URL.

Go to news:netscape.public.mozilla.builds
Try to view a digaitaly signed message, a TRUNK tree status message for instance.

Result:
Mozilla now totaly freezes up until it has contacted the OCSP server
(certificates.netscape.com:80 in this case). It is not even possible to go to
another Mozilla windows. After contacting the server, Mozilla returns to normal
operation.

Expected result:
Mozilla should contact the OCSP service in the background, without freezing up
entirely.

Workaround:
Do not use OCSP for certificate validation. (This way you can not see if a
certificate has been revoked!)

Comment 1

[Charles Rosendahl]

See also bug 136459 and bug 136469.

OCSP should probably be disabled for beta and release noted until we can fix
these bugs.  Activating OCSP at the moment causes breakage in the mail client.

Comment 2

[Charles Rosendahl]

I will reconfirm on Win98.  Win2k and XP have some bugs related to OCSP, but the
client is not freezing.  Using the intranet server, all signed messages are
showing up with invalid signatures.

What is even cooler, is the fact that although you cannot set your preferences
to sign newsgroups, you can go through your mail account and change the type
column to 'newsgroup' and then sign the message!

Otherbugs to look at (might be the intranet server does not have OCSP URL
configured properly)
-invalid signature: reason - CA is not trusted (? - the root CA is, as is the
intermediary)
-View cert indicates that the cert has been verified for the following uses, and
then contains a null list of uses.  There is a separate bug for this already (I
think under the client lib component)

Comment 3

[Kai Engert (:KaiE:)]

Is it possible that we only freeze, if the OCSP server is temporarily not
responding?

Another question: What happens if the user is not allowed to connect to the OCSP
server site, like a blocking firewall?

Comment 4

[Stephane Saux]

Only affect the user when OCSP is turned on.

Comment 5

[Julien Pierre]

Kai,

The code that talks to the OCSP server uses PR_Connect with a timeout of 30s. So
it should eventually return if the server is down.

However, it then uses PR_Write to send the OCSP request, which will block
forever if the server isn't reading the data after accepting the connection, or
the network becomes unavailable in the middle of the request. This may be what
the original reporter of this defect was seeing.

The part that reads the OCSP response now uses PR_Recv instead of PR_Send, with
a 30s timeout.

Comment 6

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Mass change "Future" target milestone to "--" on bugs that now are assigned to
nobody.  Those targets reflected the prioritization of past PSM management.
Many of these should be marked invalid or wontfix, I think.

Comment 8

[Kai Engert (:KaiE:)]

I believe this should be fixed now, with the work in bug 111384.

I'm closing this as fixed. Please reopen if you still have this problem.