On 2009-06-04 16:55 PDT, Wan-Teh Chang wrote: > On Thu, Jun 4, 2009 at 1:15 PM, Nelson B Bolyard <nel...@bolyard.me> > wrote:
>> 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. How is that event distinct from the user cert selection event? Does the user ever need to enter a private key password except at the time that cert selection for client auth is done? (hmm. maybe for token removal and reinsertion?) > [...] 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. A resumption handshake? I was aware that IE/Schannel terminates the connection for a bad cert, but I thought that the connection was dropped before the handshake was completed. That would necessitate another full handshake after the user "accepts" the bad cert, as no SSL session would have been established by the previous attempt, so no session resumption was possible. BTW, I believe the IE/Schannel handle user cert selection the same way. It drops the connection while the user decides, then starts over when the user has chosen a cert and entered the password for the private key. When we first discovered that IE/Schannel behavior back in the last 1990s, I advocated adopting it. I opined that tying up the connection to the server while the user decided about the bad cert was unfriendly to the server, potentially preventing it from serving other users. moreover, at that time, browser users frequently encountered a situation wherein the server would time out and drop the connection by the time the user had overridden the bad cert. So the user would override the bad cert, and would then need to manually reinitiate contact to the server again. I opined that adopting an IE-like strategy would solve both problems. However, at that time, a number of vociferous browser developers opined even more strongly that the work of transferring the extra packets necessary to terminate the first connection and start a second one was a waste of network resources (e.g. backbone line and router bandwidth). They were concerned about the browser being labeled network unfriendly. So we chose to stay with the present approach. But even today, if the browser folks were willing, I'd revisit that decision. I think it's cleaner than the SSL_RestartHandshake approach. /Nelson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
