RE: cvs commit: httpd-2.0/modules/ssl mod_ssl.h ssl_engine_dh.c ....

["MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <ma...@hp.com>]

I agree with Justin - the scoreboard data may not be random enough (and easy
to affect it).. What I've been trying to do something similar to Doug's
suggestion - have a thread in each process that acts as a random data
gatherer (that's what I believe zeus does), and I expect it to give better
performance..

-Madhu

-----Original Message-----
From: Doug MacEachern [mailto:dougm@covalent.net]
Sent: Tuesday, February 26, 2002 7:56 PM
To: dev@httpd.apache.org
Cc: Ralf S. Engelschall; Justin Erenkrantz; William Rowe
Subject: Re: cvs commit: httpd-2.0/modules/ssl mod_ssl.h ssl_engine_dh.c
ssl_engine_init.c ssl_engine_kernel.c ssl_engine_rand.c ssl_scache_dbm.c
ssl_scache_shmcb.c ssl_scache_shmht.c


On Mon, 25 Feb 2002, Cliff Woolley wrote:
 
> ssl_rand_seed() runs on every request if you configure it that way.

this is true, when 'SSLRandomSeed connect builtin' is configured, which is 
the default.  not sure how much the scoreboard image changes between 
requests.  though somewhat related, i still have on my ssl performance 
todo-list, optimizing 'SSLRandomSeed connect builtin'.  first problem is 
that RAND_seed() mutex locks in a threaded MPM.  and there's three calls 
to it at connect time:

1st - adds pid (already happened at startup) and time() (which RAND_seed 
already does everytime you call it).  i'm no random number expert, but 
would be surprised if seed with the same values is useful.

2nd - stackdata (from unsigned char stackdata[256]), no idea how random 
that'll be.

3rd - scoreboard data

better sources can be configured, but require reading from a file, running 
an external program or talking to an EGD.  i think builtin could be 
improved.  how about if threads are available, spawn a low priority thread 
to gather entropy using apr_generate_random_bytes() which mod_ssl can grab
as 
needed without blocking?