You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/12/29 07:06:09 UTC
random number generation
Well, we talked a week or so ago about trying to get
apr_generate_random_bytes to work on all platforms (i.e. those
without /dev/{u}random). I said I'd take a look into seeing what
is available. Time to report...
For those that don't recall, the problem here is that OpenSSL
refuses to seed itself if it doesn't have /dev/{u}random or an
external random file (which for various nefarious reasons none
of us want to deal with). We're currently doing some magic in
mod_ssl to force the seed generation. Flood (which uses APR) has
similar code to seed OpenSSL. So, it may be best to try to get
apr_generate_random_bytes to work on all platforms so that all
APR-using programs have a consistent source of entropy (and
remove all of the code duplication).
Basically, I see a few choices:
1) Attempt to integrate truerand.c (from mod_ssl)
It uses signals and may be a mess to get working right. I
really dislike its use of signals and longjmps. However, it
may be the best random choice because of that. But, I'm not
sure that we can truly make it portable-enough to merit
inclusion into APR.
2) There are a few in Numerical Recipies and Knuth vol. 2.
The PRNGs here have been around for a while and are tested
(with some known flaws). These implementations are fairly
straightforward.
3) Mersenne Twister - http://www.math.keio.ac.jp/~matumoto/emt.html
This seems an interesting theoretical approach. It is cited
to be faster than most other PRNGs. I haven't used it personally,
but it was recommended by some people I know.
However, #2 and #3 are completely deterministic in that if you
know the seed, you can then predict the sequence. However, is
seeding it with the time value a good enough seed to start with?
This is almost the entire problem with random numbers - what is
good enough?
AIUI, we must also consider that OpenSSL will do some magic to
the seed value on its own, so it *should* make it slightly better.
It'd be nice to get some input from the OpenSSL folks as they've
probably thought about this longer than we have (but, I'm afraid
I'm against a random file on-disk as *no one* wants to deal with
that).
I guess the problem is trying to identify how good we want this to
be. We'd only use this on platforms that don't have a source of
entropy (i.e. Solaris, AIX, etc.). We're currently kind of screwed
on these platforms anyway - are any of these options better than
nothing at all? I'm at a loss as to what we should do. -- justin
Re: random number generation
Posted by Ben Laurie <be...@algroup.co.uk>.
Justin Erenkrantz wrote:
>
> 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
It isn't necessary, but it is certainly a good option to provide.
> 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."
And fail to serve the page. Is this good? I don't know, but its
certainly correct.
> 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?").
I have no comment on BUILTIN (coz I haven't looked at it), but I'll note
that I don't provide it in Apache-SSL. :-)
> 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
OK. I'd also suggest that we want something along these lines:
a) A directive to set the minimum amount of entropy at startup
b) A directive to set the amount of entropy to attempt to add on each
connection
c) A directive to set a timeout on per-connection entropy
If things work out, I'd be inclined to move the improved seeding code
into OpenSSL, but its probably easier to start with it in Apache!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: random number generation
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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
Re: random number generation
Posted by Ben Laurie <be...@algroup.co.uk>.
Justin Erenkrantz wrote:
>
> On Sat, Dec 29, 2001 at 09:25:54PM +0000, Ben Laurie wrote:
> > I'm completely opposed to us subverting the whole entropy question. It
> > is absolutely unacceptable for Apache to ship with anything that will
> > "fix" the problem of insufficient entropy in any way other than
> > providing sufficient entropy. If this means people have to think, well
> > that's just tough.
>
> I hope that the "people have to think" is us - the developers - not
> the end-users. In my experience, the biggest end-user roadblock for
> OpenSSL on Solaris has been its lack of a built-in entropy gatherer.
> I would like to produce a better end-user experience for APR-using
> programs (such as httpd and flood).
>
> > BTW, EGD is a cross-platform entropy gatherer. And Solaris has patches
> > to provide /dev/random.
>
> I notice that EGD's README indicates that its entropy pool may not
> be large enough to deal with OpenSSL directly. Is this true?
> Would we have to be careful if we code apr_generate_random_bytes
> to use EGD? Could we also live with a requirement of perl for
> proper operation on these non-/dev/random platforms?
>
> A slightly better alternative to EGD is PRNGd (C-based):
>
> http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
>
> PRNGd seems to attempt to solve a lot of the issues with EGD.
Right, PRNGd is indeed a better alternative, it slipped my mind.
> I must state that I'm leery on relying on an external program
> that must be started before all other programs in order to ensure
> proper operation. We could certainly have this as another option
> in our fallback arsenal though.
>
> I believe that the /dev/random patch you are talking about for
> Solaris is here: http://www.cosy.sbg.ac.at/~andi/. I would be
> hesistant to recommend a third-party kernel patch for Solaris.
> I've heard rumours of a Sun patch though, but this problem would
> still occur on non-patched systems and other platforms (AIX).
I was talking about the Sun patch, which is part of SUNWski.
> Have you seen how OpenSSH gathers entropy in its portable version?
> They have an essentially in-process portable EGD (see WARNING.RNG).
> Do you have any experience or comments about this approach? Since
> it is BSD-licensed, I imagine that we could easily incorporate
> this code and APR-ize it. -- justin
I agree with the warning: it can take a long time to gather sufficient
entropy and it is difficult to reliably estimate the entropy without
local knowledge.
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).
As is so often the case with security, "easy" and "good" appear to be
incompatible, sadly.
Cheers,
Ben.
[1] By setting your entropy estimates ridiculously low. Even this is a
risk for a small number of cases.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: random number generation
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sat, Dec 29, 2001 at 09:25:54PM +0000, Ben Laurie wrote:
> I'm completely opposed to us subverting the whole entropy question. It
> is absolutely unacceptable for Apache to ship with anything that will
> "fix" the problem of insufficient entropy in any way other than
> providing sufficient entropy. If this means people have to think, well
> that's just tough.
I hope that the "people have to think" is us - the developers - not
the end-users. In my experience, the biggest end-user roadblock for
OpenSSL on Solaris has been its lack of a built-in entropy gatherer.
I would like to produce a better end-user experience for APR-using
programs (such as httpd and flood).
> BTW, EGD is a cross-platform entropy gatherer. And Solaris has patches
> to provide /dev/random.
I notice that EGD's README indicates that its entropy pool may not
be large enough to deal with OpenSSL directly. Is this true?
Would we have to be careful if we code apr_generate_random_bytes
to use EGD? Could we also live with a requirement of perl for
proper operation on these non-/dev/random platforms?
A slightly better alternative to EGD is PRNGd (C-based):
http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
PRNGd seems to attempt to solve a lot of the issues with EGD.
I must state that I'm leery on relying on an external program
that must be started before all other programs in order to ensure
proper operation. We could certainly have this as another option
in our fallback arsenal though.
I believe that the /dev/random patch you are talking about for
Solaris is here: http://www.cosy.sbg.ac.at/~andi/. I would be
hesistant to recommend a third-party kernel patch for Solaris.
I've heard rumours of a Sun patch though, but this problem would
still occur on non-patched systems and other platforms (AIX).
Have you seen how OpenSSH gathers entropy in its portable version?
They have an essentially in-process portable EGD (see WARNING.RNG).
Do you have any experience or comments about this approach? Since
it is BSD-licensed, I imagine that we could easily incorporate
this code and APR-ize it. -- justin
Re: random number generation
Posted by Ben Laurie <be...@algroup.co.uk>.
"William A. Rowe, Jr." wrote:
>
> From: "Ben Laurie" <be...@algroup.co.uk>
> Sent: Saturday, December 29, 2001 3:25 PM
>
> > Justin Erenkrantz wrote:
> >
> > > AIUI, we must also consider that OpenSSL will do some magic to
> > > the seed value on its own, so it *should* make it slightly better.
> > > It'd be nice to get some input from the OpenSSL folks as they've
> > > probably thought about this longer than we have (but, I'm afraid
> > > I'm against a random file on-disk as *no one* wants to deal with
> > > that).
> > >
> > > I guess the problem is trying to identify how good we want this to
> > > be. We'd only use this on platforms that don't have a source of
> > > entropy (i.e. Solaris, AIX, etc.). We're currently kind of screwed
> > > on these platforms anyway - are any of these options better than
> > > nothing at all? I'm at a loss as to what we should do. -- justin
> >
> > I'm completely opposed to us subverting the whole entropy question. It
> > is absolutely unacceptable for Apache to ship with anything that will
> > "fix" the problem of insufficient entropy in any way other than
> > providing sufficient entropy. If this means people have to think, well
> > that's just tough.
>
> Agreed - but perhaps differently. It's something of a political question,
> but if OpenSSL is the solution to crypto ... I rather expect it alone has
> the maintainers and contributors to address cross platform entropy.
>
> My question is --- is it our place to gather entropy; or do we rely upon
> the OpenSSL project to do so across platforms [and fill in the gaps for
> platforms that really offer nothing.]
It would obviously be better to put any improved solutions for entropy
gathering into OpenSSL rather than APR, if that's what you mean.
> I'm not against supplimenting Entropy [in fact, Justin and I were joking,
> well half joking, that a simple output filter that recognizes only gzip
> compressed data - could suppliment the entropy.] I just question if we
> have the resources to address this adaquately, or if it truly belongs in
> the scope of the OpenSSL project itself.
gzip compressed data provides no more entropy than the uncompressed
version of the data - in fact, it provides the same amount. One
advantage of compressed data is that (for certain types of source data)
the compression can give you a better clue as to the amount of entropy
present.
> > BTW, EGD is a cross-platform entropy gatherer. And Solaris has patches
> > to provide /dev/random.
>
> Interesting. At least it's dual-licensed [GPL + MIT]. Note it's perl
> based, however.
>
> http://sourceforge.net/projects/egd/
As noted later in the thread, I should really have pointed at PRNGd.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: random number generation
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Ben Laurie" <be...@algroup.co.uk>
Sent: Saturday, December 29, 2001 3:25 PM
> Justin Erenkrantz wrote:
>
> > AIUI, we must also consider that OpenSSL will do some magic to
> > the seed value on its own, so it *should* make it slightly better.
> > It'd be nice to get some input from the OpenSSL folks as they've
> > probably thought about this longer than we have (but, I'm afraid
> > I'm against a random file on-disk as *no one* wants to deal with
> > that).
> >
> > I guess the problem is trying to identify how good we want this to
> > be. We'd only use this on platforms that don't have a source of
> > entropy (i.e. Solaris, AIX, etc.). We're currently kind of screwed
> > on these platforms anyway - are any of these options better than
> > nothing at all? I'm at a loss as to what we should do. -- justin
>
> I'm completely opposed to us subverting the whole entropy question. It
> is absolutely unacceptable for Apache to ship with anything that will
> "fix" the problem of insufficient entropy in any way other than
> providing sufficient entropy. If this means people have to think, well
> that's just tough.
Agreed - but perhaps differently. It's something of a political question,
but if OpenSSL is the solution to crypto ... I rather expect it alone has
the maintainers and contributors to address cross platform entropy.
My question is --- is it our place to gather entropy; or do we rely upon
the OpenSSL project to do so across platforms [and fill in the gaps for
platforms that really offer nothing.]
I'm not against supplimenting Entropy [in fact, Justin and I were joking,
well half joking, that a simple output filter that recognizes only gzip
compressed data - could suppliment the entropy.] I just question if we
have the resources to address this adaquately, or if it truly belongs in
the scope of the OpenSSL project itself.
> BTW, EGD is a cross-platform entropy gatherer. And Solaris has patches
> to provide /dev/random.
Interesting. At least it's dual-licensed [GPL + MIT]. Note it's perl
based, however.
http://sourceforge.net/projects/egd/
Bill
Re: random number generation
Posted by Ben Laurie <be...@algroup.co.uk>.
"Marc M. Adkins" wrote:
>
> > > This is almost the entire problem with random numbers - what is
> > > good enough?
>
> I was once advised to use crypto functions to generate a "really" random
> number. I may be able to locate the algorithm -- I'm not sure without
> looking -- but it depended on having heavy-duty crypto functions available.
> Like one step was to generate an SHA (MD5?) hash of a block of pseudo-random
> data (I think).
>
> I noticed that APR has MD5 code in it, perhaps the algorithm would be doable
> with the current codebase. I remember it being really slow (due to the
> crypto functions used). Perhaps that could be offset by generating larger
> blocks of numbers at a go and vending them out as needed. Perhaps a thread
> could be dedicated to the purpose. Seems like too much work, but I thought
> I'd mention it.
>
> Does anyone want me to go looking for the algorithm for this discussion?
> I'll understand if the crypto aspect has y'all making a sign against the
> evil algorithm as cold chills travel up your spines. That's what it
> generally does to me...but I'm a programmer, not a mathematician.
The randomness of the output of any algorithm is determined by its input
(because an attacker can simply run the same algorithm with the same
input if it is known, and hence get the same output). Its certainly true
that some algorithms are better than others at not destroying useful
randomness in the input, and that is probably where the advice on using
SHA-1/MD5 on data came from, however, I would strongly question the
value of running them on blocks of pseudo-random data (modulo the
complexities of mixing/random pools).
In any case, OpenSSL already does appropriate mixing/pool maintenance,
so there is really no need to pre-mix your input data - simply feed it
into OpenSSL's pool.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
RE: random number generation
Posted by "Marc M. Adkins" <Ma...@Doorways.org>.
> > This is almost the entire problem with random numbers - what is
> > good enough?
I was once advised to use crypto functions to generate a "really" random
number. I may be able to locate the algorithm -- I'm not sure without
looking -- but it depended on having heavy-duty crypto functions available.
Like one step was to generate an SHA (MD5?) hash of a block of pseudo-random
data (I think).
I noticed that APR has MD5 code in it, perhaps the algorithm would be doable
with the current codebase. I remember it being really slow (due to the
crypto functions used). Perhaps that could be offset by generating larger
blocks of numbers at a go and vending them out as needed. Perhaps a thread
could be dedicated to the purpose. Seems like too much work, but I thought
I'd mention it.
Does anyone want me to go looking for the algorithm for this discussion?
I'll understand if the crypto aspect has y'all making a sign against the
evil algorithm as cold chills travel up your spines. That's what it
generally does to me...but I'm a programmer, not a mathematician.
Marc M. Adkins
Re: random number generation
Posted by Ben Laurie <be...@algroup.co.uk>.
Justin Erenkrantz wrote:
>
> Well, we talked a week or so ago about trying to get
> apr_generate_random_bytes to work on all platforms (i.e. those
> without /dev/{u}random). I said I'd take a look into seeing what
> is available. Time to report...
>
> For those that don't recall, the problem here is that OpenSSL
> refuses to seed itself if it doesn't have /dev/{u}random or an
> external random file (which for various nefarious reasons none
> of us want to deal with). We're currently doing some magic in
> mod_ssl to force the seed generation. Flood (which uses APR) has
> similar code to seed OpenSSL. So, it may be best to try to get
> apr_generate_random_bytes to work on all platforms so that all
> APR-using programs have a consistent source of entropy (and
> remove all of the code duplication).
>
> Basically, I see a few choices:
>
> 1) Attempt to integrate truerand.c (from mod_ssl)
> It uses signals and may be a mess to get working right. I
> really dislike its use of signals and longjmps. However, it
> may be the best random choice because of that. But, I'm not
> sure that we can truly make it portable-enough to merit
> inclusion into APR.
> 2) There are a few in Numerical Recipies and Knuth vol. 2.
> The PRNGs here have been around for a while and are tested
> (with some known flaws). These implementations are fairly
> straightforward.
> 3) Mersenne Twister - http://www.math.keio.ac.jp/~matumoto/emt.html
> This seems an interesting theoretical approach. It is cited
> to be faster than most other PRNGs. I haven't used it personally,
> but it was recommended by some people I know.
>
> However, #2 and #3 are completely deterministic in that if you
> know the seed, you can then predict the sequence. However, is
> seeding it with the time value a good enough seed to start with?
> This is almost the entire problem with random numbers - what is
> good enough?
Seeding with a time value is not good enough - it has almost no entropy.
This is precisely why OpenSSL insists on having a decent amount of
entropy in the first place!
My experience of truerand is that it is bad (in the sense that lack of
entropy is often visible to the naked eye). And signals and longjmps are
not safe. So I'm not keen on 1) either.
> AIUI, we must also consider that OpenSSL will do some magic to
> the seed value on its own, so it *should* make it slightly better.
> It'd be nice to get some input from the OpenSSL folks as they've
> probably thought about this longer than we have (but, I'm afraid
> I'm against a random file on-disk as *no one* wants to deal with
> that).
>
> I guess the problem is trying to identify how good we want this to
> be. We'd only use this on platforms that don't have a source of
> entropy (i.e. Solaris, AIX, etc.). We're currently kind of screwed
> on these platforms anyway - are any of these options better than
> nothing at all? I'm at a loss as to what we should do. -- justin
I'm completely opposed to us subverting the whole entropy question. It
is absolutely unacceptable for Apache to ship with anything that will
"fix" the problem of insufficient entropy in any way other than
providing sufficient entropy. If this means people have to think, well
that's just tough.
BTW, EGD is a cross-platform entropy gatherer. And Solaris has patches
to provide /dev/random.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: random number generation
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
Just to back up what Ben said (but with a little more explanation for those
of us who don't work in bomb shelters for a living), the true randomness of
the initialization function is necessary to maintain the strong encryption
characteristics of SSL. If we make any attempt to reduce the entropy needed,
or replace it with any sort of PRNG (pseudo == NOT), then we reduce the SSL
algorithm to something any cheap PC can crack. That is why OpenSSL refuses
to start without sufficient entropy.
We do not need to support SSL on a system without a true random source.
We should try to make use of all well-known sources of true random numbers,
but there is no need for SSL support to work on every platform. The OS
folks will get around to supporting /dev/[u]random eventually.
....Roy