> I have therefore committed code that now will make the seeding before the
> first connection and then never again. Never in the sense of an application's
> life-time. The 'ssl is seeded' variable is a global variable, so it'll
> survive the comings and goings of easy handles etc.

I think that ideally, the software would make an estimate of the entropy 'used
up' in each request, and then gather some more when the amount of tru entropy
drops below some threshold. (/dev/random already does this). In effect, the
'randomness' is buffered up, and when the buffer is empty, the application needs
to get some more.

I think really that openssl should handle this - it's doing the encryption, after
all, and knows what ciphers have been used, how many bites/bytes transferred,
keys generated etc. It's been given the entropy source name, so it should be able
to just go off and get some.

Certainly re-seeding per-request can get pretty expensive - mod_ssl has global
and per-request (actually, per negotiation) parameters for how much entropy
should be used, and where from - normally /dev/urandom is used for global, then
some internal function is used for actual requests.
  
> Ok, I lied. I can think of one reason why one could possibly want to re-seed,
> and that is if the initial seeding was done based on a not-good-enough random
> source and another better one pops up for a subsequent operation.

You could always have a setopt option to force a re-seed, or perhaps if the ssl
random filename is reset...

If you really want to improve the SSL situation, you should probably have a look
at SSL cafile loading as well - quick traces look to me like these are done on
every request as well, when they should only be necessary once per ssl context
(or once per handle). Even better would be to support the SSL CAdir option -
instead of loading all of the root CA certs for every request, this option allows
you to only read the CA chain that is actually required (into the cache)...

Cris