Re: low entropy on linux systems
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
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
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 kevan.mil...@gmail.comwrote: 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=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] 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 0xdaad63e0 (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 0xd3b5a768 (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
On 15.07.2011 04:19, Kevan Miller 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=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] 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 0xdaad63e0 (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 0xd3b5a768 (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... And note that due to a bug in the JDK you really need to use /dev/./urandom or /dev//urandom and not /dev/urandom. Oracle themselves already internally use dev/urandom, but later they switch from /dev/urandom to /dev/random if the setting is trsingwise identical to /dev/random. That's why you need to use some different string that's equivalent to /dev/urandom after path normalization. We had the same problem for Tomcat, mostly when starting two instances in parallel. Regards, Rainer
Re: low entropy on linux systems
On 15.07.2011 15:56, Rainer Jung wrote: On 15.07.2011 04:19, Kevan Miller 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=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] 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 0xdaad63e0 (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 0xd3b5a768 (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... And note that due to a bug in the JDK you really need to use /dev/./urandom or /dev//urandom and not /dev/urandom. Oracle themselves already internally use dev/urandom, but later they switch from /dev/urandom to /dev/random if the setting is trsingwise identical to /dev/random. That's why you need to use some different string that's equivalent to /dev/urandom after path normalization. We had the same problem for Tomcat, mostly when starting two instances in parallel. ... and a bit more detail available at: http://marc.info/?l=tomcat-devm=130182757504685w=2 Regards, Rainer
Re: low entropy on linux systems
On Jul 15, 2011, at 10:03 AM, Rainer Jung wrote: snip And note that due to a bug in the JDK you really need to use /dev/./urandom or /dev//urandom and not /dev/urandom. Oracle themselves already internally use dev/urandom, but later they switch from /dev/urandom to /dev/random if the setting is trsingwise identical to /dev/random. That's why you need to use some different string that's equivalent to /dev/urandom after path normalization. We had the same problem for Tomcat, mostly when starting two instances in parallel. ... and a bit more detail available at: http://marc.info/?l=tomcat-devm=130182757504685w=2 Cool. Thanks for the additional information, Rainer. --kevan
low entropy on linux systems
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=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] 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 0xdaad63e0 (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 0xd3b5a768 (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
Re: low entropy on linux systems
Kevan, thanks for letting us know. I've collected your description into G3.0 doc. https://cwiki.apache.org/GMOxDOC30/runtime-issues.html Jeff On Fri, Jul 15, 2011 at 10:19 AM, Kevan Miller kevan.mil...@gmail.comwrote: 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=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] 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 0xdaad63e0 (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 0xd3b5a768 (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
Re: low entropy on linux systems
Installing rngd/rng-tools also can help fix these sorts of problems. --jason On Jul 14, 2011, at 7:19 PM, Kevan Miller 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=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] 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 0xdaad63e0 (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 0xd3b5a768 (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
