Hello,

I wrote an SSL tunnel application, which works with client-autentication:
clients must present a certificate signed by an approved CA to use this tunnel.

The number of clients using system could be quite large, and session-resumption
is obviously important to support.

One thing that has been bothering me about the session cache is that when
client-authentication is enabled, a session object takes a much larger
amount of memory - as much as 10 times more than a session without client
authentication. I did a little research and found that the problem is that
the client certificate (whose size is as much as 1K) is kept in the session
object, and therefore also in the session cache.

I can understand why a general-purpose server might want to keep those
certificate around for session resumptions, but for my purposes (and probably
for the purposes of many other people), this is completely unnecessary: once
the client is verified to be authorized to use the tunnel, I no longer care
to remember any details of who this specific client is.

I think I found a solution for this, but I'm not sure how safe is what I've
done so I'd appreciate comments, or ideas on how to do this better.

My idea is that after the handshake completes successfully (and the client
is authenticated) we can free the peer certificates. We must do it before
a copy of the session is saved in the external session cache, so the proper
place to do it is in the new-session callback (see SSL_CTX_sess_set_get_cb(3))
which is called right after a handshake completes and when the session is
ready to be put in the external session cache.

But how do I free the peer certificate? One thing was farely obvious - I did

    if(s->session->peer){
        X509_free(s->session->peer);
        s->session->peer=0;
    }

Which frees the client's certificate. I believe this is safe to do from the
new-session callback (but I'd appreciate any comments), and it makes the
memory use of the external session cache much smaller (in my case).

However, I noticed there's another field that contains certificates coming
from the clients: s->session->sess_cert->cert_chain. I thought it contains
the rest of the certificate chain (all except the last one, which is put
in s->session->peer), and that it could be freed safely as well. But
unfortunately, I did not find a clean way to do that - I only found how
to free s->session->sess_cert (relatively) cleanly, by doing

    /* eek, this function is defined in ssl_locl.h, not ssl.h... */
    extern void ssl_sess_cert_free(void *);

    if (s->session->sess_cert){
        ssl_sess_cert_free(s->session->sess_cert);
        s->session->sess_cert=0;
    }

But I was wondering, is it safe to do (again, assuming I will not be
interested in the client's identity for the rest of the session)?
Or does the s->session_sess_cert contain any important data that I
shouldn't free like that?

I verified that freeing both the session->peer and session->sess_cert
actually does works (and session resumes, etc., continue to work) but
what I would like is some reassurance that what I did is "safe", and
that there isn't a simpler or cleaner way to do this.

In fact, it would have been nice if it were possible to turn on a flag
for OpenSSL, which will tell it that it can discard the client certificate
(and everything related to it) immediately after its verification.
I didn't see such an option existing.

Thanks for any ideas or thoughts,
        Nadav.

-- 
Nadav Har'El                        |  Wednesday, Mar 19 2003, 16 Adar II 5763
[EMAIL PROTECTED]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |I couldn't afford a cool signature, so I
http://nadav.harel.org.il           |just got this one.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to