Occasionally (1% of the time), my SSL client throws a "digest check failed" when connecting to the server. The server gets the alert "decrypt error". The scenario is this:
1. The client and server establish a successful handshake and dump the remote side's SSL information (including the session ID). 2. After about a minute or so, a successful renegotiation happens. Once again they dump the SSL information. This time, the session ID is different as one would expect. 3. The server goes down (as in shuts down gracefully). 4. The server comes back up again. The client is set for session reuse. So, it reuses an older session (the one renegotiated in Step 2). At this point, the server seems to have successfully completed the SSL_accept as I can see the dump of the SSL information. But, the client fails with SSL3_GET_FINISHED:digest check failed. I've Google'd for this and this has been faced by other software like nginx and apache. But, the solution seems to be to disable session reuse. So, the questions are: (a) Is this an OpenSSL problem for which there is no work around and so the application has to disable session reuse? (b) Is this an application bug, if so how? (c) My understanding is that a session reuse automatically takes care of the case where the server shuts down and reconnects at which point the session ID/ticket that the client sends won't be in the server's OpenSSL cache and so should be treated as a fresh handshake. Right? If so, what does this bug has to do with SSL session reuse (as others claim)? FWIW, my custom client and server uses blocking sockets. Thanks, Karthik ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
