Funny Baby Card Message

mod_jk and SSL connections

The problem

Several problems with a cause: Connections from Apache via mod_jk to hang a JBoss (more precisely, to the contained Tomcat) and SSL connections do not build up easily. The problem occurs sometimes, an Apache restart or the "+ JkOptions DisableReuse" sometimes seem to help.

The cause

The cause is quite different: a lack of coincidence! Linux provides two devices available, provide the chance: / dev / random and / dev / urandom. This access both to an internal kernel entropy source, which fills in quite unpredictable events in the system, such as hard disk access, network activity, keyboard and mouse input, etc. The difference between the two is that / dev / random only to this events leaves, while / dev / urandom also a pseudo-random number generator (PRNG) is used. In practice this means that / dev / random "hang", if too much coincidence has been accessed, while / dev / urandom always delivers a result.

One can easily view how much chance the kernel has just made available:

cat / proc / sys / kernel / random / entropy_avail

With

cat / dev / random

you can read out the chance. The command is very fast and can be interrupted with Ctrl-C. Eventually, the terminal is then verkonfiguriert what is by typing "reset" corrected. If you try the same with / dev / urandom, you get constantly new values.

Java defaults to / dev / random for java.secure.SecureRandom, which in turn, etc. for SSL connections used. JBoss Seam uses it for his session IDs. Are there not enough random, then waits for Java / dev / random and therefore part of a long time until it goes on.

The solution

Depends on a process to date, thus ensuring you have more chance by example with a

ls-lR /

or

hdparm-t / dev / sda

for HDD provides. Better yet, the trailer does not even occur to leave. For this you have Java instruct only, instead of / to use dev / random single / dev / urandom. This is a simple command-line option for the JVM:

-Djava.security.egd = file: / dev / urandom

or directly in the program code with

System.setProperty ("java.security.egd" "File: / dev / urandom");

The disadvantage of this approach is that the chance of / dev / urandom can be predicted more easily and thus, for example, an attack on SSL connections is possible. Those who want to stay on the safe side, consider the needs of a hardware random number generator. An easy to implement saving approach is a microphone in front of a fan. The recorded samples to edit but something else, but that's another subject.