234135 - Support nonblocking cert validation and revocation in libssl

Status: REOPENED

(NSS :: Libraries, enhancement, P2)

Description

[John G. Myers]

A nonblocking SSL socket should do nonblocking OCSP lookups.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I have recently been informed that there exists at least one NSS-based 
SSL and/or SMIME client that does OCSP, using NSS's code to create the 
request, and NSS's code to parse/analyze the response, but does NOT use 
NSS's built-in OCSP client to do the OCSP check during the NSS cert chain 
validation, hence avoiding the blocking nature of that client.  

Such an approach would obviate the proposal in bug 234130.

Comment 2

[Wan-Teh Chang]

It is an S/MIME client, so it is not doing OCSP in the
middle of an SSL connection setup.

Comment 3

[Julien Pierre]

Nelson, Wan-Teh,

I assume that application in question does the OCSP check separately from
calling CERT_VerifyCertXXX functions .... That's certainly a valid way to do things.

The only catch is that it can only cleanly do so on the leaf cert. Otherwise, it
would have to reconstruct the chain with its own algorithm and check OCSP for
each cert in the chain. That may or may not be the same chain that
CERT_VerifyCertXXX uses.

I think to remedy this problem, we would need some way to pass a full cert chain
around rather than just a leaf cert. There should be some NSS APIs to build the
chain, and other APIs to verify it. The chain could also be retrieved by the
application for any kind of additional checking, such as for OCSP. 

If we want to support nonblocking OCSP checks inside the NSS OCSP client code,
it is a significantly more complicated problem than for an S/MIME client to do
it separately. But there might be a need to also fix this situation for SSL
applications.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Re: Comment 2: IINM, the client in question is also capable of SSL for 
doing IMAPS, SMTP/S, and perhaps even POP3/S, no?  
Does it not do OCSP checking during those operations?

Comment 5

[Julien Pierre]

Nelson,

If OCSP is globally disabled in NSS, as it is by default, and as would need to
be set to prevent the built-in OCSP client from being used, then the SSL client
in question would indeed not do OCSP checking with SSL, unless there was
explicit OCSP code in the server cert verification callback, and not merely a
call to CERT_VerifyCertXXX which wouldn't do OCSP with the setting off.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

comment 5 is certainly true.  The creators of that client would have to add
code in both the CMS/SMIME code and in the SSL cert chain validation callback
for their OCSP client to handle both.  I can scarcely imagine that they would
go to all the effort to add it to one, and then not do the small incremental
effort to add it to the other.

Comment 7

[John G. Myers]

(In reply to comment #1)
> Such an approach would obviate the proposal in bug 234130.

I respectfully disagree.  There is at least one SSL and/or SMIME client that
does not use NSS.  This does not obviate the need for NSS to support SSL and SMIME.

Comment 8

[Wan-Teh Chang]

Re: comment 4: the answer is no, it does not do OCSP checking
during the IMAPS, SMTP/S, and POP3/S operations.

Comment 9

[Kai Engert (:KaiE:)]

The discussion in this bug seems rather hypothetical and it has stopped more than 2 years ago.

The original request was
  "A nonblocking SSL socket should do nonblocking OCSP lookups."

If I understand correctly, this could in theory be implemented within libSSL. When libSSL has a need to verify something while OCSP is enabled, it could do so on a separate worker thread, and signal WOULDBLOCK to the caller of an SSL I/O call.

But is that really necessary at this time?
Does that block OCSP from being enabled by default?
I do not think so.

In PSM, we have implemented such a nonblocking OCSP functionality, by moving the OCSP lookup to a worker thread.

I no longer see a need for this RFE to block bug 110161.

Comment 10

[John G. Myers]

(In reply to comment #9)
> If I understand correctly, this could in theory be implemented within libSSL.
> When libSSL has a need to verify something while OCSP is enabled, it could do
> so on a separate worker thread, and signal WOULDBLOCK to the caller of an SSL
> I/O call.

Then how does the caller know when to retry the I/O call?

Comment 11

[Kai Engert (:KaiE:)]

(In reply to comment #10)
> Then how does the caller know when to retry the I/O call?

For the PSM implementation we used a trick, we replace the lower level NSPR file description with a pollable event, and signal that even when data is finally ready.

Should the environment fail to provide a pollable event (as it happens on local Firewall environments that prevent loopback connections on windows) we actually fall back to a kind of busy loop. Not perfect, but still better as blocking.

If you're curious in implementation details, have a look at mozilla/security/manager/ssl/src/nsSSLThread and nsNSSIOLayer.

Comment 12

[Julien Pierre]

libpkix also has a built-in OCSP client which supports non-blocking operation.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Assigning OCSP bugs to Mr. OCSP. :)

Comment 14

[Julien Pierre]

Nelson,

We have nonblocking support in the cert library with libpkix in 3.12 already. This part is done. It returns a state to the caller that includes a dependent OCSP socket, that the caller can PR_Poll on. This already works in the text-based libpkix test programs, which just do cert verification and don't use libssl. You can for example implement a single-threaded GUI program like PSM that will do nonblocking cert verification and be able to not freeze while the I/O is going on. So there is no longer a need to disable OCSP in the PSM UI if you use the libpkix nonblocking I/O support.

However, what's missing here is a way for libssl to use that nonblocking OCSP support. The problem is described in more detail in bug 324867 .
This is a libssl API deficiency, not an OCSP bug, so I'm changing the description. The very same API deficiency also prevents non-blocking LDAP and HTTP cert/CRL fetching when the cert verification is invoked by a libssl cert auth callback.

I'm marking this problem as dupe of bug 324867 since solving that bug will solve this one also.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

I have split bug 324867 apart into two bugs.  This is one of them.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.