On Thu, Jun 4, 2009 at 1:15 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: > > 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.
Yes, I asked the Chromium Linux developer to copy that code from PSM: http://codereview.chromium.org/115700 and we submitted a patch back to PSM: https://bugzilla.mozilla.org/show_bug.cgi?id=495357 > 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. Thanks a lot for telling me about SSL_RestartHandshakeAfterServerCert. I didn't know it existed. Based on your description, I think it should work for Chromium. > 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. Thanks. Chromium will also need SSL_RestartHandshakeAfterCertReq or some other solution when it supports SSL client auth. Another indefinite delay during SSL client auth is the password prompt for the private key. I still need to solve this problem. Some background info on Chromium's current solution: it's partially based on the Schannel API on Windows. If the caller wants to verify the server cert itself, the caller can only get the server cert from the Schannel after the handshake is completed. So IE and Chromium on Windows are forced to verify the server cert after the handshake is done. This definitely affected my thought process when I tried to solve the problem for Chromium on Linux using NSS (when I didn't know about the SSL_RestartHandshakeAfterServerCert function). In fact if you use ssltap to observe how IE handles a server cert error, you will see very different behavior from PSM -- when IE gets a bad server cert, it immediately closes the SSL connection, while the user is looking at the SSL error page. When the user accepts the bad cert, IE does a resumption handshake to open a new connection to the server. Chromium on Windows behaves more like Firefox except that it waits after the handshake is done. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
