Bug 474727 - ocsp checking incorrectly attempting to use closed connections?
ocsp checking incorrectly attempting to use closed connections?
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Kai Engert (:kaie)
BaseOS QE Security Team
: Regression
Depends On:
  Show dependency treegraph
Reported: 2008-12-04 19:25 EST by Nalin Dahyabhai
Modified: 2014-01-17 07:33 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-09 16:16:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 470055 None None None Never

  None (edit)
Description Nalin Dahyabhai 2008-12-04 19:25:16 EST
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):

How reproducible:

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 13:16:28 EST
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 14:56:41 EST
Um. So. Regression in nss?
Comment 3 Nalin Dahyabhai 2008-12-12 13:05:13 EST
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) 2008-12-17 14:03:14 EST
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
Comment 5 Nalin Dahyabhai 2008-12-17 14:14:48 EST
Created attachment 327277 [details]
root certificate to match the hard-coded example certificates

Oops, here you go.
Comment 6 Kai Engert (:kaie) 2008-12-17 14:15:14 EST
What output do you get when you run your test tool?
I get:
Verifying "testuser4 (internal copy)" ("UID=testuser4,E=shillman@redhat.com,CN=Test User 4,O=Token Key User"), got error -8179 (NSS 13).
Verifying "testuser5 (internal copy)" ("UID=testuser5,E=jneedle@redhat.com,CN=Test User 5,O=Token Key User"), got error -8179 (NSS 13).
Verifying "testuser6 (internal copy)" ("UID=testuser6,E=rousseau@redhat.com,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) 2008-12-17 14:18:34 EST
thanks, I can reproduce your failure now
Comment 8 Kai Engert (:kaie) 2008-12-17 16:01:18 EST
I reported the failure upstream at:

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) 2008-12-17 16:16:54 EST
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.