Bug 474727 - ocsp checking incorrectly attempting to use closed connections?
Summary: ocsp checking incorrectly attempting to use closed connections?
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss
Version: 5.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-05 00:25 UTC by Nalin Dahyabhai
Modified: 2014-01-17 12:33 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-09 21:16:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
a cut-down reproducer (10.16 KB, text/plain)
2008-12-05 00:25 UTC, Nalin Dahyabhai
no flags Details
root certificate to match the hard-coded example certificates (1.26 KB, text/plain)
2008-12-17 19:14 UTC, Nalin Dahyabhai
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 470055 0 None None None Never

Description Nalin Dahyabhai 2008-12-05 00:25:16 UTC
Created attachment 325765 [details]
a cut-down reproducer

Description of problem:
When pkinit-nss goes to validate client certificates, it only seems to be able to correctly check the OCSP status for one certificate per responder.  This appears to be happening because NSS's ocsp client code doesn't notice that the responder's closed its end of the socket, causing the client code to try sending the request over the already-closed connection.

Version-Release number of selected component (if applicable):
nss-3.12.1.1-3.el5

How reproducible:
Always

Steps to Reproduce:
Call CERT_VerifyCertificate() for two certificates which feature the same OCSP responder.



Actual results:
The second verification (even if both certificates are valid) will fail.  If you change the order in which you're checking them, the second one is still the one that fails.

Expected results:
Everything's happy.

Additional info:  This may well be a bug in pkinit-nss.  If it is, then I'll be quite happy to bugger off.

Comment 1 Nalin Dahyabhai 2008-12-11 18:16:28 UTC
Hmm, commenting out the call to control whether or not PKIX validation is used, the reproducer compiles and works correctly when built and run against 3.11.7 packages, but it begins failing again when I upgrade the NSS package to 3.12.1.

Comment 2 Suzanne Hillman 2008-12-11 19:56:41 UTC
Um. So. Regression in nss?

Comment 3 Nalin Dahyabhai 2008-12-12 18:05:13 UTC
It sure looks that way, but I'm holding out hope that it's a bug in the reproducer and thus in my code.

Comment 4 Kai Engert (:kaie) (inactive account) 2008-12-17 19:03:14 UTC
In order to reproduce your test, I would require the chain of issuer certs.
I don't have the 
  Issuer: O=Red Hat Westford CA XVI, CN=Certificate Authority
cert.

Comment 5 Nalin Dahyabhai 2008-12-17 19:14:48 UTC
Created attachment 327277 [details]
root certificate to match the hard-coded example certificates

Oops, here you go.

Comment 6 Kai Engert (:kaie) (inactive account) 2008-12-17 19:15:14 UTC
What output do you get when you run your test tool?
I get:
Verifying "testuser4 (internal copy)" ("UID=testuser4,E=shillman,CN=Test User 4,O=Token Key User"), got error -8179 (NSS 13).
Verifying "testuser5 (internal copy)" ("UID=testuser5,E=jneedle,CN=Test User 5,O=Token Key User"), got error -8179 (NSS 13).
Verifying "testuser6 (internal copy)" ("UID=testuser6,E=rousseau,CN=Test User 6,O=Token Key User"), got error -8179 (NSS 13).

I just tried to use certs from some popular websites (paypal, verisign, gmx) and I have the intermediate and I still get the same error, so something else may be wrong on my testing side, still looking.

Comment 7 Kai Engert (:kaie) (inactive account) 2008-12-17 19:18:34 UTC
thanks, I can reproduce your failure now

Comment 8 Kai Engert (:kaie) (inactive account) 2008-12-17 21:01:18 UTC
I reported the failure upstream at:
  https://bugzilla.mozilla.org/show_bug.cgi?id=470055

The cause is indeed that NSS internal HTTP client for OCSP connection attempts to reuse the socket, despite the fact that the socket has already been closed.

Comment 9 Kai Engert (:kaie) (inactive account) 2008-12-17 21:16:54 UTC
I've posted a workaround patch in the upstream bug.
That workaround completely disables NSS attempt to cache HTTP socket connections.
It fixes the problem reported in this bug.
Depending on how urgent this problem is, we can build the workaround patch or wait for a better upstream patch.
Please let me know your opinion.


Note You need to log in before you can comment on or make changes to this bug.