Openssl 1.0.1e is not clearing the session ticket upon handshake 
failure, contrary to the recommendation in RFC 5077 section 3.2 paragraph 4.

I am seeing that after some sort of event, Amazon ELB will respond to a 
TLS 1.0 handshake containing a session ticket that it had handed out 
prior to the event by closing the connection. When my client application 
tries to reconnect, openssl will once again send the session ticket, 
causing Amazon ELB to once again close the connection. This leads to an 
hours-long inability to reconnect, until my client application is 
manually restarted, removing knowledge of the now-poison ticket.

Attached is a patch which causes SSL3 to clear the session upon any 
handshake failure. I have not attempted to do the corresponding fix to 
DTLS. Also included is a change to s_client I used for testing, 
extending the -reconnect option to also act upon handshake failure.



diff -ru ../openssl-1.0.1e-orig/apps/s_client.c ./apps/s_client.c
--- ../openssl-1.0.1e-orig/apps/s_client.c      2013-02-11 07:26:04.000000000 
-0800
+++ ./apps/s_client.c   2013-09-16 10:43:51.589324000 -0700
@@ -1891,6 +1891,12 @@
                print_stuff(bio_c_out,con,full_log);
        SSL_shutdown(con);
        SHUTDOWN(SSL_get_fd(con));
+       if (reconnect)
+               {
+               reconnect--;
+               BIO_printf(bio_c_out,"reconnect\n");
+               goto re_start;
+               }
 end:
        if (con != NULL)
                {
diff -ru ../openssl-1.0.1e-orig/ssl/s3_clnt.c ./ssl/s3_clnt.c
--- ../openssl-1.0.1e-orig/ssl/s3_clnt.c        2013-02-11 07:26:04.000000000 
-0800
+++ ./ssl/s3_clnt.c     2013-09-16 10:35:05.808437000 -0700
@@ -646,6 +646,12 @@
                BUF_MEM_free(buf);
        if (cb != NULL)
                cb(s,SSL_CB_CONNECT_EXIT,ret);
+       if (ret < 0 && s->session != NULL)
+               {
+               SSL_CTX_remove_session(s->ctx,s->session);
+               SSL_SESSION_free(s->session);
+               s->session=NULL;
+               }
        return(ret);
        }
 

Reply via email to