Nelson, Thanks a lot for your answer.
On Wed, Jun 3, 2009 at 4:25 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: > >> Note: The way Chromium uses NSS to verify SSL server >> certificates has changed since Dan Kegel posted that message. >> Since certificate verification can block indefinitely while >> downloading CRLs or talking to OCSP responders, Chromium >> is verifying certificates on a thread pool (so it won't block the >> message loop of the main thread) after the handshake is completed. >> Chromium now has an auth-certificate callback that always >> returns SECSuccess, and is no longer using a bad-certificate >> callback. > > 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? 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. Thanks, Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
