On 2009-06-03 19:16 PDT, Wan-Teh Chang wrote: >> That means that you always put the cert and its chain into the client's >> cache, and cache the negotiated SSL session, where it will be restarted >> by future attempts to connect to the same host/port. This seems >> inadvisable. > > Yes, that's an issue. Chromium handles that by also verifying the cert > after a resumption handshake is completed. Other than the inefficiency > of repeatedly verifying the same cert (which can be addressed by caching > cert verification results), do you see any problem with this approach?
Yes. The SSL client session cache only caches the server cert, not the server cert chain. So, unless you arrange to save the server cert chain, the chain will always be incomplete for a session resumption. At it happens, PSM saves intermediate CA certs from valid chains in the cert DB, not for the purpose of validating certs in resumption handshakes, but to maximize the likelihood that all the certs are present for future cert validations for incorrectly configured servers that send out incomplete cert chains. However, it also has the side effect that it will facilitate validation of server certs on restart handshakes. Chromium would need to do something similar. Perhaps it already does. > Certificate verification with revocation checking is a potentially long > operation, so any app that does non-blocking SSL I/O from a message/ > event loop needs to solve this problem. (The message/event loop is > supposed to run short functions only.) > > PSM solved this problem by moving all of SSL to worker threads. > Chromium is moving just certificate verification to worker threads, and > this requires the trickery described above. For years, going all the way back to NSS 2.0 and maybe farther, libSSL has had provision for another way to solve this problem. Recall that Netscape Navigator also did its SSL processing with non-blocking I/O on the main thread in an event loop. This is how it did that. It's possible to suspend SSL processing on a socket at the point where the the auth cert callback gets called, and resume it later when the auth cert processing is actually done. This avoids all problems associated with caching invalid SSL sessions. The auth cert callback function initiates the actual cert chain processing, and if that processing is unable to complete immediately, it returns SECWouldBlock. Then, later, when the cert chain processing is finished and the outcome was successful (cert is valid), you call the public function SSL_RestartHandshakeAfterServerCert (which, I just noticed, is declared in the wrong header file. The comment in sslimpl.h is incorrect. :( ) This function then does the processing that ssl3_HandleCertificate would have done if the auth cert callback had returned SECSuccess on the first call, and then continues to process the records received on the SSL socket. To be honest, this function has fallen into disuse. PSM stopped using it, and I'm not aware of any other clients that use it. We have no test programs that test it. (tstclnt should do that.) So, it's possible that it has also fallen into disrepair. But I consider it supported, and would work to fix any bugs found in it, if any were reported. There is a similar function for suspending and restarting the SSL handshake processing at another point where there may be long delays, namely, when the user needs to choose a cert with which to perform client authentication. The client auth cert selection callback returns SECWouldBlock, and then when the selection is done, the app calls SSL_RestartHandshakeAfterCertReq to carry on as it would have if the client auth cert selection callback had returned SECSuccess. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
