Today we had a problem after enabling client certificate authentication in JBoss 4.2.3. At first, I googled the problem and found that a potential JBoss speedup was to specify a different SSLRandomSeed option to point to /dev/urandom instead of the default “builtin”. Basically since the SSL parts were using /dev/random, which depended on entropy to generate “uniquely random” output. By pointing to /dev/urandom, which weren’t blocked by a lack of entropy (such as mouse movement, keyboard input, etc), the thought was that the initial SSL client handshake would be quicker.
When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. The intent is to serve as a cryptographically secure pseudorandom number generator, delivering output with entropy as large as possible. This is suggested for use in generating cryptographic keys for high-value or long-term protection.
Slightly problematic was the fact that /dev/random should be used for more “secure” applications, as opposed to /dev/urandom.
Anyway, long story short, the /dev/random thing didn’t fix our issue. The actual problem was that DNS lookups from the server to the outside world were blocked (the server was probably trying to do name lookups for the FQDNs of the certs/etc), and this was causing the initial connection to go VERY slowly (8 seconds or so until the DNS lookup timed out).
The simple(r) fix was to open up the firewall from that server to the world, and all was right. In the end, I did end up learning a bit more about entropy and JBoss, so I consider it a win.