On Wed, Mar 19, 2003 at 07:40:37PM +0200, Nadav Har'El wrote:
> 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.
As far as I can see, there is no problem with your approach. One obvious
downside is, that you lose the information about the client (but you
already said that you don't care). The other downside is, that you don't
know whether the client authenticated at all. This is no problem as long
as all clients have to authenticate anyway. In a mixed client auth/anonymous
setup, you will no longer be able to distinguish the sessions. Hmm, well,
that could be achieved with the session ID context, if handled carefully...
> 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).
People should not mess around with internal data structures. But there is
now API, so this is the only way to do it, ...
> 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
Hmm. Do you use internal or external session caching? The cert_chain is
not maintained when storing to the external session cache; thus it is
only a problem if you are talking about a large internal cache.
> 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.
There is no such option. And I indeed believe, that it is a more or less
unusual request (typically people are interested in obtaining the
information about the peer, as this is what authentication is about).
That does not mean, that one could not implement it, if there is enough
public interest...
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
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]
