apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: random number generation
Date Mon, 31 Dec 2001 19:46:24 GMT
On Mon, Dec 31, 2001 at 03:02:47PM +0000, Ben Laurie wrote:
> I know you'd like to wave a magic APR entropy wand and instantly have
> enough entropy for SSL (or whatever), but I'm afraid it just isn't
> generally possible. Being sure that you have provided sufficient
> entropy[1] will get you, I guarantee, a zillion queries along the lines
> of "I started httpd, but it hangs forever when I try to access secure
> pages, why?" - in fact, unless you jump through hoops, it'll hang
> forever for all pages on some systems (coz you'll have to gather the
> entropy before forking).

A few comments:

1) I believe we would only use apr_generate_random_bytes in the
initialization of mod_ssl.  So, the time delays will only occur
on startup or restart.  I believe this delay will be minimum (it
would be similar to the delay of OpenSSH on these platforms).
I see that mod_ssl tries to seed the PRNG in the pre_connection
hook?  Is it really necessary to reseed it each time?  (Or, does
OpenSSL require constant reseeding?  I haven't seen any notes to
that effect in the documentation.)  The OpenSSH code has timeouts
(~200msec per command) to ensure that the entropy gathering does 
not take an infinite amount of time.  If the entropy is not enough,
it will error out with: "not enough entropy in RNG."

2) I believe the OpenSSH approach would provide infinitely better 
entropy than the current BUILTIN model that mod_ssl uses.  Ideally,
the user may have an EGD-compatible program, but that is not 
normally the case.  I am also hesitant to rely on PRNGd as I believe
that may give us *more* problems than doing it internally ("what?  I
have to start this program first?").

3) My apr_generate_random_bytes preference would be:
1) /dev/[u]random
2) PRNGd / EGD (they are socket-compatible)
3) Fallback internal (on the model of OpenSSH)

> As is so often the case with security, "easy" and "good" appear to be
> incompatible, sadly.

Other projects such as OpenSSH seem to have attempted to solve this
problem.  There is only a certain amount of entropy that can be
gathered without kernel support.  However, I believe that having
an internal entropy gathering would provide better entropy than is
currently achieved by the haphazard BUILTIN code.  I am not suggesting
that it is better than having a true /dev/[u]random or even PRNGd -
in the ideal world, all systems have /dev/[u]random.  That isn't the
case.  APR should be dealing with the real world.

As OtherBill mentioned, it would be nice if OpenSSL could handle 
this, but it doesn't.  So, I believe we need to address this problem
in APR.  Since httpd and flood both have this issue (and to some 
extent SVN), it seems best to address it at the portability layer 
instead of in each program (otherwise, we'll have a tremendous amount
of code duplication).  

At this point, I'll translate their code over and see how it works
in practice.  I would be curious to see how Covalent's SSL engine
(based on RSA) handles non-/dev/[u]random platforms.  -- justin

View raw message