Tomcat 5.0.28 and /dev/urandom

[Tim Full <tf...@sdsusa.com>]

Most implementations work fine with using /dev/urandom as a seed for the
sessionid generator for Tomcat (class ManagerBase), but I have 2 instances
that seem to cause Tomcat to hang on open of /dev/urandom. I have been
unsuccessful in finding any overrides that would get the session manager to
use something else for a seed. Do you know of any ways to get around this
problem without having to modify Tomcat classes? It appears that I should be
able to use an alternative class. The default is java.security.SecureRandom.
With Tomcat 3.3, I was able circumvent the problem by having Tomcat use
java.util.Random instead, but that does not seem to work on Tomcat 5.0.28.
Are you aware of any configuration options that would be suitable to
workaround the /dev/urandom hang?  

 

RE: Tomcat 5.0.28 and /dev/urandom

["Caldarale, Charles R" <Ch...@unisys.com>]

> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: Tomcat 5.0.28 and /dev/urandom
> 
> However, I'm using JDK 1.5.0_08, and my configuration appears 
> to use it: securerandom.source=file:/dev/urandom

Yes, that's the default setting.

> Your statement is contrary to the documentation within the 
> java.security file (which may be wrong for all I know):

It's not really wrong, but it is incomplete.

> # This "NativePRNG" reads random bytes directly from /dev/urandom.

That part is somewhat incorrect; if it's available, NativePRNG will use
both /dev/urandom and /dev/random, depending on the API being used.  If
NativePRNG is not available (for any of a variety of reasons),
SecureRandom is typically used instead, which uses only /dev/random (if
available).  Any references to the default SeedGenerator also use
/dev/random.  It appears that the above is only guaranteed to apply when
the Sun security provider is selected; other providers may behave
differently.

> Chuck, can you point us to any official documentation that
> describes this behavior? Or, are you looking at the source
> code or something like that?

I read code, since the JVM doesn't actually run the documentation
(pity).  Look in:
    j2se/src/share/classes/sun/security/provider/Sun.java
    j2se/src/share/classes/sun/security/provider/SeedGenerator.java
    j2se/src/share/classes/sun/security/provider/SecureRandom.java
 
j2se/src/solaris/classes/sun/security/provider/NativeSeedGenerator.java
    j2se/src/solaris/classes/sun/security/provider/NativePRNG.java

Note that the Windows implementation is somewhat different.
Unfortunately, there is no public API doc for any of this, since these
are all sun.* classes.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Tomcat 5.0.28 and /dev/urandom

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
>> Subject: Re: Tomcat 5.0.28 and /dev/urandom
>>
>> Yeah, if you are using Linux, the /dev/urandom device 
>> sometimes stalls.
> 
> Actually, /dev/urandom is defined never to block, but the JRE doesn't
> use it.

Oh, hey, you're right: reading the man page is always helpful ;)

However, I'm using JDK 1.5.0_08, and my configuration appears to use it:
securerandom.source=file:/dev/urandom

> If either file:/dev/random or file:/dev/urandom is configured
> as the securerandom.source in java.security, the URLSeedGenerator class
> (inside sun/security/provider/SeedGenerator.java) uses /dev/random,
> which can block.

Your statement is contrary to the documentation within the java.security
file (which may be wrong for all I know):

#
# Select the source of seed data for SecureRandom. By default an
# attempt is made to use the entropy gathering device specified by
# the securerandom.source property. If an exception occurs when
# accessing the URL then the traditional system/thread activity
# algorithm is used.
#
# On Solaris and Linux systems, if file:/dev/urandom is specified and it
# exists, a special SecureRandom implementation is activated by default.
# This "NativePRNG" reads random bytes directly from /dev/urandom.
#
# On Windows systems, the URLs file:/dev/random and file:/dev/urandom
# enables use of the Microsoft CryptoAPI seed functionality.
#
securerandom.source=file:/dev/urandom

I'm troubled by the statement "a special SecureRandom implementation is
activated by default", which doesn't say anything about that
implementation (like, whether it actually respects the /dev/urandom
preference).

Chuck, can you point us to any official documentation that describes
this behavior? Or, are you looking at the source code or something like
that?

Thanks,
- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFYd4f9CaO5/Lv0PARAn4VAKCC2/h38QzodYfrh2rwfbDeIAcaaACfW6Kl
0zlZmWh4A9IDWMBApTxnct8=
=HzA8
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Tomcat 5.0.28 and /dev/urandom

["Caldarale, Charles R" <Ch...@unisys.com>]

> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: Tomcat 5.0.28 and /dev/urandom
> 
> Yeah, if you are using Linux, the /dev/urandom device 
> sometimes stalls.

Actually, /dev/urandom is defined never to block, but the JRE doesn't
use it.  If either file:/dev/random or file:/dev/urandom is configured
as the securerandom.source in java.security, the URLSeedGenerator class
(inside sun/security/provider/SeedGenerator.java) uses /dev/random,
which can block.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Tomcat 5.0.28 and /dev/urandom

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim,

Tim Full wrote:
> Most implementations work fine with using /dev/urandom as a seed for the
> sessionid generator for Tomcat (class ManagerBase), but I have 2 instances
> that seem to cause Tomcat to hang on open of /dev/urandom.

Yeah, if you are using Linux, the /dev/urandom device sometimes stalls.
the best way to re-fill the buffers is to pound on the keyboard at the
console (which is usually inaccessible). :(

Anyhow, this isn't a Tomcat thing... it's a JRE thing. Google really is
your friend, here
(http://www.google.com/search?q=securerandom+change+random+source). You
can change the device that SecureRandom uses for gathering entropy by
modifying the "securerandom.source" property of your
JAVA_HOME/jre/lib/security/java.security file.

The comments in that file also suggest that you can use the system
property java.security.egd=[url] to override that property if you feel
like modifying your installation is a bad idea (which it probably is).

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFYbM19CaO5/Lv0PARAnwJAJ4vBZq/HDXrE9pfc3u0ES6HfoKpIACeKXhw
kA/tOt5oDDQ7Jqmfo83QDlw=
=3UPU
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org