I am running into an issue where java is slow when used over SSL. The solution is to add
-Djava.security.egd=file:/dev/./urandomto java at the command line. Since I
This is actually a hack introduced into the JVM back in 1.3 or 1.4 days
http://bugs.sun.com/view_bug.do?bug_id=4705093
http://bugs.sun.com/view_bug.do?bug_id=6202721
The basic issue is that in the native JVM code they hardcoded /dev/urandom
to actually use /dev/random
to attempt to ensure sufficient entropy. Since /dev/urandom
is supposed to be guaranteed not to block, this has the unintended consequence of blocking if not enough entropy is available.
The hardcoding looks specifically for the string /dev/urandom
, so providing something that resolves to the same thing but doesn't match that causes the desired behavior. If you code /dev/./urandom
you bypass the hardcoded aliasing and get to the intended urandom
entropy source.
I wouldn't recommend using urandom for SSL. Your problem is that your machine doesn't have enough entropy and using urandom doesn't solve this problem. Assuming your on Linux you can check the available entropy with:
cat /proc/sys/kernel/random/entropy_avail
If you are on a machine that has a hw random number generator you most probably want to install rngd. You can check if your cpu has one by issuing the command:
cat /proc/cpuinfo
Look for flags called rand. You can also check if the file /dev/hwrng is present. You might have/want to load the corresponding module:
ls /lib/modules/*/kernel/drivers/char/hw_random
For me this is:
sudo modprobe tpm-rng
To make it permanent:
echo tpm-rng | sudo tee -a /etc/modules
If you happen to be on Ubuntu/Debian just install the package rng-tools.
sudo aptitude install rng-tools
If you check your entropy before and after installing rng-tools you should see a significant increase.
The following command should show you available entropy sources:
sudo rngd -f -r /dev/hwrng -v
Note that if you need better security you want to mix multiple entropy sources. Not sure rng-tools supports this.