Re: low entropy on linux systems

[Shawn Jiang <ge...@gmail.com>]

 This could increase the linux start up speed significantly.   Does anyone
know is it safe to add "-Djava.security.egd=file:/dev/./urandom"  to our
startup script directly.

Don't know if it will break something on other linux/unix platforms.

On Fri, Jul 15, 2011 at 10:19 AM, Kevan Miller <ke...@gmail.com>wrote:

> From time to time I encounter a problem starting a Geronimo server on a
> Linux system (I've always seen it on Ubuntu -- but the problem could exist
> on other distributions). The server start seems to hang. However, if you're
> patient, which I rarely am, the server will eventually start. If you're
> inquisitive, and dump the stack traces of the java process, you'll see
> something like:
>
> "main" prio=10 tid=0x0000000040c0d800 nid=0xa79 runnable
> [0x00007f57a04fb000]
>   java.lang.Thread.State: RUNNABLE
>        at java.io.FileInputStream.readBytes(Native Method)
>        at java.io.FileInputStream.read(FileInputStream.java:220)
>        at
> sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:185)
>        at
> sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(NativePRNG.java:202)
>        - locked <0x00000000daad63e0> (a java.lang.Object)
>        at
> sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:108)
>        at
> sun.security.provider.NativePRNG.engineGenerateSeed(NativePRNG.java:102)
>        at java.security.SecureRandom.generateSeed(SecureRandom.java:495)
>        at
> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.getSalt(PKCS12KeyStore.java:477)
>        at
> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.calculateMac(PKCS12KeyStore.java:834)
>        at
> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineStore(PKCS12KeyStore.java:788)
>        - locked <0x00000000d3b5a768> (a
> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore)
>        at java.security.KeyStore.store(KeyStore.java:1117)
> ...
>
> This problem isn't Geronimo specific. But since I see it from time to time,
> thought it would be worth passing along to the community...
>
> The Sun/Oracle-based JVM is attempting to generate a pseudo-random number
> to be used as a seed for an SSL server socket. To generate the pseudo-random
> number, the JVM is reading from the /dev/random device to obtain some random
> information for the seed. The problem is that reads from the /dev/random
> device will block if the system does not have a good source of random
> events. So, the Geronimo server startup is blocked waiting for enough random
> information to be returned from /dev/random. This article may be help
> understand the basic issue --
> http://en.wikipedia.org/wiki//dev/random#Linux
>
>  I'm no security expert. And I don't know the potential implications, but
> the simplest way that I've found to avoid the problem is to use the
> /dev/urandom device, instead of /dev/random. Do this by specifying the
> following java property '-Djava.security.egd=file:/dev/./urandom'. So, the
> following should work well:
>
> $ GERONIMO_OPTS="-Djava.security.egd=file:/dev/./urandom" ./geronimo run
> --long
>
> Note to self -- would be nice to record this on our Wiki somewhere. Anyway,
> hope this is useful...
>
> --kevan
>
>
>


-- 
Shawn

Re: low entropy on linux systems

[Russell E Glaue <rg...@cait.org>]

Apache HTTPD Server, OpenSSL, and GPG support using EGD as an alternative for 
Unix systems which do not support the /dev/random device.

EGD is written in perl (Entropy Gathering Daemon - http://egd.sourceforge.net/).
PRNGD is written in C (Pseudo Random Number Generator Daemon - 
http://prngd.sourceforge.net/).


The java.security.SecureRandom bundled with the JDK can use PRNG.
http://download.oracle.com/javase/6/docs/api/java/security/SecureRandom.html

See: 
http://stackoverflow.com/questions/137212/how-to-solve-performance-problem-with-java-securerandom


There is a ColdFusion blog about using EGD in the java environment. That is 
using /dev/./urandom instead of /dev/random. See middle section of blog post. 
See a little further down for a production resolution.

ColdFusion hangs or slow on startup due to MessageBrokerServlet
http://www.ghidinelli.com/2011/01/11/cold-fusion-slow-start-messagebrokerservlet

This blog post recommends "-Djava.security.egd=file:/dev/./urandom", but then it 
goes on to suggest how to tune the EGD on your linux system for production.


-RG



On 08/18/2011 10:47 AM, Kevan Miller wrote:
>
> On Aug 18, 2011, at 1:06 AM, Shawn Jiang wrote:
>
>> This could increase the linux start up speed significantly.   Does anyone know is it safe to add "-Djava.security.egd=file:/dev/./urandom"  to our startup script directly.
>>
>> Don't know if it will break something on other linux/unix platforms.
>
> IIRC, some unix variants don't have a /dev/urandom. I don't think these environments are very popular. I would expect these environments would have fairly obvious failures and could be diagnosed, fairly easily.
>
> I suppose that there is some possibility that urandom will generate a less secure seed for the SSL server socket. I've never heard of any concerns about this, but that doesn't mean it doesn't exist.
>
> This is a long standing problem. And Java has not chosen to do anything about it. I know some servers have used a similar approach. Others, e.g. Tomcat, have left it up to users/admins.
>
> Given the number of times we bump into this issue, I'd say that setting "-Djava.security.egd=file:/dev/./urandom" is likely to do more good than harm.
>
> --kevan

Re: low entropy on linux systems

[Kevan Miller <ke...@gmail.com>]

On Aug 18, 2011, at 1:06 AM, Shawn Jiang wrote:

> This could increase the linux start up speed significantly.   Does anyone know is it safe to add "-Djava.security.egd=file:/dev/./urandom"  to our startup script directly.    
> 
> Don't know if it will break something on other linux/unix platforms.

IIRC, some unix variants don't have a /dev/urandom. I don't think these environments are very popular. I would expect these environments would have fairly obvious failures and could be diagnosed, fairly easily. 

I suppose that there is some possibility that urandom will generate a less secure seed for the SSL server socket. I've never heard of any concerns about this, but that doesn't mean it doesn't exist. 

This is a long standing problem. And Java has not chosen to do anything about it. I know some servers have used a similar approach. Others, e.g. Tomcat, have left it up to users/admins.

Given the number of times we bump into this issue, I'd say that setting "-Djava.security.egd=file:/dev/./urandom" is likely to do more good than harm.

--kevan