On Sun, Mar 23, 2003, Lutz Jaenicke wrote about "Re: Valid trick to reduce session
object's size?":
> 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
Right. In my setup, all clients will have to authenticate, and once they
do they will get access to the service, regardless of who they authenticated
as.
If it was important for me to remember whether the client authenticated or
not (had I allowed that), or who the client is, I could have saved a bit
more information before deleting the certificates. The certificates
themselves are pretty big (several kilobytes) relative to the few bytes of
information I will ever need from them again. But so far I don't need to
even save that information.
> 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.
I currently use both (as do most SSL servers, like Apache, by the way).
You're right, the cert_chain is only saved in the internal cache (there are
even nice comments in the OpenSSL code reminding of this fact :)), but the
internal cache can also get quite big. In fact by default it saves 20,000
sessions, which with client authentication comes out huge.
Maybe I've done a judgement error, and I should not be using on a large
internal cache, but instead drop the internal cache completely and use
just the external one (thanks to the new SSL_SESS_CACHE_NO_INTERNAL!).
But for various silly reasons I am temporarily using the internal cache too,
and I wanted my get-rid-of-the-client-certificates hack to be complete.
> > 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...
Since this is just an issue of memory use, and not a new feature, I guess
most people won't even notice that they are missing this feature - they
would just go out and buy more memory.
I really have no idea if anybody else needs this feature - I just thought
it would be nice for my needs and wanted comments if I did it correctly :)
By the way, if other people are interested, but not enough to add this as
an official session option, an alternative could be to add a function
(say, SSL_SESSION_free_certificates) that the programmer would have to call
explicitly (the manual page could explain from where). This will save the
programmer the need to access internal structures and "extern" strange
routines, like I did. But again, if nobody else requested this functionality,
feel free to stick this idea in the "when pigs fly" drawer :)
Thanks,
Nadav.
--
Nadav Har'El | Sunday, Mar 23 2003, 20 Adar II 5763
[EMAIL PROTECTED] |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Take my advice, I don't use it anyway.
http://nadav.harel.org.il |
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
