You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <jw...@virginia.edu> on 2002/05/25 23:21:29 UTC
/dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on startup]
On Wed, 22 May 2002, Aaron Bannert wrote:
> On Wed, May 22, 2002 at 08:24:04PM -0700, Justin Erenkrantz wrote:
> > IIRC, /dev/random is a "better" source of entropy than /dev/urandom
> > because /dev/random can block waiting for good enough bits gathered
> > from the system while /dev/urandom must always spit out something, so
> > its entropy isn't guaranteed to be as good.
>
> You're correct, but it's the blocking part that's the problem here.
> I'm not sure how much entropy is required by mod_auth_digest, but
> something tells me that we need to do one of the following:
>
> 1) prefer /dev/urandom over /dev/random
> 2) disable mod_auth_digest by default [in binbuilds]
> 3) open /dev/random in non-blocking mode and defer EAGAIN reads
> until later (read it at startup; if it would block, try again when
> the entropy is actually needed, failing if it isn't ready by then
> -- no idea if this would even work).
Can we come to a consensus on this? For those just joining the
conversation, the problem is that APR's apr_generate_random_bytes()
currently prefers /dev/random over /dev/urandom, which causes Apache's
mod_auth_digest to hang at startup if there's not enough entropy available
from /dev/random. I proposed the following patch:
Index: configure.in
===================================================================
RCS file: /home/cvs/apr/configure.in,v
retrieving revision 1.449
diff -u -d -r1.449 configure.in
--- configure.in 14 May 2002 07:38:16 -0000 1.449
+++ configure.in 25 May 2002 21:22:39 -0000
@@ -1527,13 +1527,13 @@
dnl #----------------------------- Checking for /dev/random
AC_MSG_CHECKING(for /dev/random)
-if test -r "/dev/random"; then
- AC_DEFINE(DEV_RANDOM, [/dev/random])
- AC_MSG_RESULT(/dev/random)
- rand="1"
-elif test -r "/dev/urandom"; then
+if test -r "/dev/urandom"; then
AC_DEFINE(DEV_RANDOM, [/dev/urandom])
AC_MSG_RESULT(/dev/urandom)
+ rand="1"
+elif test -r "/dev/random"; then
+ AC_DEFINE(DEV_RANDOM, [/dev/random])
+ AC_MSG_RESULT(/dev/random)
rand="1"
else
case $host in
Thanks,
Cliff
Re: /dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on
startup]
Posted by Ben Laurie <be...@algroup.co.uk>.
Cliff Woolley wrote:
> On Sun, 26 May 2002, Ben Laurie wrote:
>
>
>>>>3) open /dev/random in non-blocking mode and defer EAGAIN reads
>>>> until later (read it at startup; if it would block, try again when
>>>> the entropy is actually needed, failing if it isn't ready by then
>>>> -- no idea if this would even work).
>>>
>>Grr. We keep going around this loop - there isn't a "one size fits all"
>>answer to the problem.
>
>
> Okay, fair enough. Patch withdrawn. What do you think of option #3?
> Perhaps not fail, but defer the blocking read?
BTW, it only blocks under Linux, FreeBSD just returns short, so you need
to be careful you haven't assumed blocking (and that you handle short
reads correctly).
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: /dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on
startup]
Posted by Ben Laurie <be...@algroup.co.uk>.
Cliff Woolley wrote:
> On Mon, 27 May 2002, Ben Laurie wrote:
>
>
>>Hmmm. Well, IMO it should be configurable at runtime, especially since
>>some other OSes have yet more sources of entropy (/dev/arandom for
>>example).
>
>
> Oh good, that matches the patch I've been working on. I'll post it in a
> little while. PS: is /dev/arandom common enough for us to add it to the
> list of devices we search for automatically without having to specify
> --with-devrandom=<device> [that's a new configure flag my patch will add,
> btw]? If so, how should the search be ordered?
>
> /dev/random
> /dev/arandom
> /dev/urandom
I believe this is correct (however, I believe if you have /dev/arandom
you are sure to have /dev/random, so...)
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: /dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on
startup]
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 27 May 2002, Ben Laurie wrote:
> Hmmm. Well, IMO it should be configurable at runtime, especially since
> some other OSes have yet more sources of entropy (/dev/arandom for
> example).
Oh good, that matches the patch I've been working on. I'll post it in a
little while. PS: is /dev/arandom common enough for us to add it to the
list of devices we search for automatically without having to specify
--with-devrandom=<device> [that's a new configure flag my patch will add,
btw]? If so, how should the search be ordered?
/dev/random
/dev/arandom
/dev/urandom
?? Or should /dev/arandom go before /dev/random or what?
--Cliff
Re: /dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on
startup]
Posted by Ben Laurie <be...@algroup.co.uk>.
Cliff Woolley wrote:
> On Sun, 26 May 2002, Ben Laurie wrote:
>
>
>>>What about a --with-devrandom=<path> option for people who do want to go
>>>the /dev/urandom route?
>>
>
> I'm starting to prefer this option I think.
>
>
>>Surely its configurable anyway? Changing the default strikes me as
>>something that will bite you if you aren't careful!
>
>
> Nope. Currently /dev/random is strictly preferred over /dev/urandom which
> is strictly preferred over EGD over truerand. I'd think if the user asks
> for EGD, we should ignore /dev/random even if it exists. And if the user
> asks for /dev/urandom or /some/other/device, we should prefer that over
> /dev/random even if it exists. I'm not sure how truerand should fit in,
> since it's currently just tested for as a last resort and not specifically
> requested by the user.
Hmmm. Well, IMO it should be configurable at runtime, especially since
some other OSes have yet more sources of entropy (/dev/arandom for example).
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: /dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on
startup]
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 26 May 2002, Ben Laurie wrote:
> > What about a --with-devrandom=<path> option for people who do want to go
> > the /dev/urandom route?
I'm starting to prefer this option I think.
> Surely its configurable anyway? Changing the default strikes me as
> something that will bite you if you aren't careful!
Nope. Currently /dev/random is strictly preferred over /dev/urandom which
is strictly preferred over EGD over truerand. I'd think if the user asks
for EGD, we should ignore /dev/random even if it exists. And if the user
asks for /dev/urandom or /some/other/device, we should prefer that over
/dev/random even if it exists. I'm not sure how truerand should fit in,
since it's currently just tested for as a last resort and not specifically
requested by the user.
--Cliff
Re: /dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on
startup]
Posted by Ben Laurie <be...@algroup.co.uk>.
Cliff Woolley wrote:
> On Sun, 26 May 2002, Ben Laurie wrote:
>
>
>>>>3) open /dev/random in non-blocking mode and defer EAGAIN reads
>>>> until later (read it at startup; if it would block, try again when
>>>> the entropy is actually needed, failing if it isn't ready by then
>>>> -- no idea if this would even work).
>>>
>>Grr. We keep going around this loop - there isn't a "one size fits all"
>>answer to the problem.
>
>
> Okay, fair enough. Patch withdrawn. What do you think of option #3?
> Perhaps not fail, but defer the blocking read?
Sounds better to me.
> What about a --with-devrandom=<path> option for people who do want to go
> the /dev/urandom route?
Surely its configurable anyway? Changing the default strikes me as
something that will bite you if you aren't careful!
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: /dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on
startup]
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 26 May 2002, Ben Laurie wrote:
> >>3) open /dev/random in non-blocking mode and defer EAGAIN reads
> >> until later (read it at startup; if it would block, try again when
> >> the entropy is actually needed, failing if it isn't ready by then
> >> -- no idea if this would even work).
>
> Grr. We keep going around this loop - there isn't a "one size fits all"
> answer to the problem.
Okay, fair enough. Patch withdrawn. What do you think of option #3?
Perhaps not fail, but defer the blocking read?
What about a --with-devrandom=<path> option for people who do want to go
the /dev/urandom route?
--Cliff
Re: /dev/urandom vs /dev/random [was Re: 2.0.36 hangs on linux on
startup]
Posted by Ben Laurie <be...@algroup.co.uk>.
Cliff Woolley wrote:
> On Wed, 22 May 2002, Aaron Bannert wrote:
>
>
>>On Wed, May 22, 2002 at 08:24:04PM -0700, Justin Erenkrantz wrote:
>>
>>>IIRC, /dev/random is a "better" source of entropy than /dev/urandom
>>>because /dev/random can block waiting for good enough bits gathered
>>>from the system while /dev/urandom must always spit out something, so
>>>its entropy isn't guaranteed to be as good.
>>
>>You're correct, but it's the blocking part that's the problem here.
>>I'm not sure how much entropy is required by mod_auth_digest, but
>>something tells me that we need to do one of the following:
>>
>>1) prefer /dev/urandom over /dev/random
>>2) disable mod_auth_digest by default [in binbuilds]
>>3) open /dev/random in non-blocking mode and defer EAGAIN reads
>> until later (read it at startup; if it would block, try again when
>> the entropy is actually needed, failing if it isn't ready by then
>> -- no idea if this would even work).
>
>
> Can we come to a consensus on this? For those just joining the
> conversation, the problem is that APR's apr_generate_random_bytes()
> currently prefers /dev/random over /dev/urandom, which causes Apache's
> mod_auth_digest to hang at startup if there's not enough entropy available
> from /dev/random. I proposed the following patch:
>
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr/configure.in,v
> retrieving revision 1.449
> diff -u -d -r1.449 configure.in
> --- configure.in 14 May 2002 07:38:16 -0000 1.449
> +++ configure.in 25 May 2002 21:22:39 -0000
> @@ -1527,13 +1527,13 @@
> dnl #----------------------------- Checking for /dev/random
> AC_MSG_CHECKING(for /dev/random)
>
> -if test -r "/dev/random"; then
> - AC_DEFINE(DEV_RANDOM, [/dev/random])
> - AC_MSG_RESULT(/dev/random)
> - rand="1"
> -elif test -r "/dev/urandom"; then
> +if test -r "/dev/urandom"; then
> AC_DEFINE(DEV_RANDOM, [/dev/urandom])
> AC_MSG_RESULT(/dev/urandom)
> + rand="1"
> +elif test -r "/dev/random"; then
> + AC_DEFINE(DEV_RANDOM, [/dev/random])
> + AC_MSG_RESULT(/dev/random)
> rand="1"
> else
> case $host in
Grr. We keep going around this loop - there isn't a "one size fits all"
answer to the problem. It is my view that defaulting to the least secure
option is not doing anyone any favours (except people who don't care
about security at all - and we have an answer for them - basic auth) -
if people want to reduce their security they should do so manually and
not have it thrust upon them.
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