Long connect times...
I'm clearly a stupid fsck, but perhaps this tip will help other stupid fscks out there running Apache and modssl on Linux. I was having trouble with long (really long, sometimes) connect times on SSL connections. Sometimes things would go through immediately, or within a second or two, but often it would be 20 seconds before data started coming back. Well, I'd configured SSL to use the high-quality random data from /dev/random (Linux gurus can stop reading here -- I've just told you what I did wrong) but that device won't give you any more data than it has collected entropy. That is, /dev/random maintains a pool of randomness that is fed by external, presumably unpredictable, events. When the pool runs dry, you have to wait for some random stuff to happen before you'll get the data you tried to read. So Apache was reading from this limited resource, and sometimes (if I was moving the mouse, or typing, or had a lot of disk activity happening) there'd be enough random data to generate a key or whatever modssl needed, but other times it had to wait until "things" happened. Tough to debug if you're thinking it's maybe network problems or something, but a quick strace will show what's really happening. Anyway, the solution is to use /dev/urandom, which never runs dry, as your source for the SSLRandomSeed lines. d. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Long connect times...
On Wed, Nov 10, 1999, dave madden wrote: > I'm clearly a stupid fsck, but perhaps this tip will help other stupid > fscks out there running Apache and modssl on Linux. > > I was having trouble with long (really long, sometimes) connect times > on SSL connections. Sometimes things would go through immediately, or > within a second or two, but often it would be 20 seconds before data > started coming back. Well, I'd configured SSL to use the high-quality > random data from /dev/random (Linux gurus can stop reading here -- > I've just told you what I did wrong) but that device won't give you > any more data than it has collected entropy. That is, /dev/random > maintains a pool of randomness that is fed by external, presumably > unpredictable, events. When the pool runs dry, you have to wait for > some random stuff to happen before you'll get the data you tried to > read. > > So Apache was reading from this limited resource, and sometimes (if I > was moving the mouse, or typing, or had a lot of disk activity > happening) there'd be enough random data to generate a key or whatever > modssl needed, but other times it had to wait until "things" > happened. Tough to debug if you're thinking it's maybe network > problems or something, but a quick strace will show what's really > happening. > > Anyway, the solution is to use /dev/urandom, which never runs dry, as > your source for the SSLRandomSeed lines. Yes, and details about this situation and problem are in the mod_ssl documentation since a long time - directly under the entry for SSLRandomSeed. But people often like it more to waste time instead of reading documentation first... ;) I've now also added an FAQ entry about this topic to increase the chance people find the answer. Thanks for your hint. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Long connect times...
=>From: "Ralf S. Engelschall" <[EMAIL PROTECTED]> =>... =>Yes, and details about this situation and problem are in the mod_ssl =>documentation since a long time - directly under the entry for => SSLRandomSeed. =>But people often like it more to waste time instead of reading documentation =>first... ;) I've now also added an FAQ entry about this topic to increase the =>chance people find the answer. Thanks for your hint. FAQ is good; perhaps also a mention in the comments of the default config file. (That's how I got in trouble: I was just going through the file and tweaking stuff.) Regards, d. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Long connect times...
On Thu, Nov 11, 1999, dave madden wrote: > =>From: "Ralf S. Engelschall" <[EMAIL PROTECTED]> > =>... > =>Yes, and details about this situation and problem are in the mod_ssl > =>documentation since a long time - directly under the entry for > => SSLRandomSeed. > =>But people often like it more to waste time instead of reading documentation > =>first... ;) I've now also added an FAQ entry about this topic to increase the > =>chance people find the answer. Thanks for your hint. > > FAQ is good; perhaps also a mention in the comments of the default > config file. (That's how I got in trouble: I was just going through > the file and tweaking stuff.) Now comitted for mod_ssl 2.4.9: Index: httpd.conf-dist === RCS file: /e/modssl/cvs/mod_ssl/pkg.apache/conf/httpd.conf-dist,v retrieving revision 1.47 diff -u -r1.47 httpd.conf-dist --- httpd.conf-dist 1999/10/01 11:34:21 1.47 +++ httpd.conf-dist 1999/11/11 18:35:52 @@ -904,6 +904,13 @@ # Pseudo Random Number Generator (PRNG): # Configure one or more sources to seed the PRNG of the # SSL library. The seed data should be of good random quality. +# WARNING! On some platforms /dev/random blocks if not enough entropy +# is available. This means you then cannot use the /dev/random device +# because it would lead to very long connection times (as long as +# it requires to make more entropy available). But usually those +# platforms additionally provide a /dev/urandom device which doesn't +# block. So, if available, use this one instead. Read the mod_ssl User +# Manual for more details. SSLRandomSeed startup builtin SSLRandomSeed connect builtin #SSLRandomSeed startup file:/dev/random 512 Thanks for the hint. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
OT: Long connect times...
> # Pseudo Random Number Generator (PRNG): > # Configure one or more sources to seed the PRNG of the > # SSL library. The seed data should be of good random quality. >+# WARNING! On some platforms /dev/random blocks if not enough entropy >+# is available. This means you then cannot use the /dev/random device >+# because it would lead to very long connection times (as long as >+# it requires to make more entropy available). But usually those >+# platforms additionally provide a /dev/urandom device which doesn't >+# block. So, if available, use this one instead. Read the mod_ssl User >+# Manual for more details. AH-HA! I've been fighting miscellaneous pauses on my machine for a while now (RH 6.1 i386). It would pause sometimes when I'd hit my webserver's frontpage (where among other things a random number gets generated), sometimes when I'd login with SSH (where it grabs a random for its encryption, presumably), etc. So I did a simple "more /dev/random", and it sat there pausing until I popped up a menu in Gnome. As I spaced down, it kept pausing until I generated activity. "more /dev/urandom" generated no such pauses. Given that my machine is pausing all over the place (Apache, SSH, Sendmail, etc.), is there a way to generate entropy to prevent random from blocking? Having to change all that sourcecode would be excessive and well beyond my skill. Steve Freitas __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: Long connect times...
On Thu, Nov 11, 1999, Steve Freitas wrote: > > # Pseudo Random Number Generator (PRNG): > > # Configure one or more sources to seed the PRNG of the > > # SSL library. The seed data should be of good random quality. > >+# WARNING! On some platforms /dev/random blocks if not enough entropy > >+# is available. This means you then cannot use the /dev/random device > >+# because it would lead to very long connection times (as long as > >+# it requires to make more entropy available). But usually those > >+# platforms additionally provide a /dev/urandom device which doesn't > >+# block. So, if available, use this one instead. Read the mod_ssl User > >+# Manual for more details. > > AH-HA! > > I've been fighting miscellaneous pauses on my machine for a while now (RH > 6.1 i386). It would pause sometimes when I'd hit my webserver's frontpage > (where among other things a random number gets generated), sometimes when > I'd login with SSH (where it grabs a random for its encryption, > presumably), etc. > > So I did a simple "more /dev/random", and it sat there pausing until I > popped up a menu in Gnome. As I spaced down, it kept pausing until I > generated activity. "more /dev/urandom" generated no such pauses. > > Given that my machine is pausing all over the place (Apache, SSH, > Sendmail, etc.), is there a way to generate entropy to prevent random > from blocking? Having to change all that sourcecode would be excessive > and well beyond my skill. Usually any type of system activity adds entropy, ranging from disk I/O to input on keyboards and other devices. As an easy workaround you perhaps could try to make /dev/random a link to /dev/random ;) Then you don't have your programs to recompile. But be aware that /dev/urandom produces not as good random values as /dev/random, of course... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Generating Entropy [was OT: Long connect times...]
=>From: Steve Freitas <[EMAIL PROTECTED]> =>... =>is there a way to generate entropy to prevent random =>from blocking? Depends on how badly you want it. SGI has a http://lavarand.sgi.com">neat solution. They use Lava Lite(r) lamps and a video digitizer to generate gobs of entropy. On a more human scale, you can probably use a video camera looking at just about anything, as long as it moves a little. (How about FishRand?) I've also seen occasional discussions about using a sound card to digitize noise, but I can't remember whether the Hard Crypto guys think that's a good idea or not. I suspect there's not *that* much entropy in what you get from a sound card. I don't know how hard it'd be to feed that entropy into /dev/random, though. For web server use (bringing this back on-topic) you probably want to use /dev/urandom, because otherwise local users can do a denial-of-service by saying: "dd if=/dev/random of=/dev/null &" d. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
