Replacing securerandom.source=file:/dev/urandom with securerandom.source=file:/dev/./urandom in $JAVA_PATH/jre/lib/security/java.security has solved my problem.
Even when file:/dev/urandom is specified, JRE will still use /dev/random for SHA1PRNG (see bug JDK-4705093):
In SHA1PRNG, there is a SeedGenerator which does various things
depending on the configuration.
If java.security.egd or securerandom.source point to “file:/dev/random” or “file:/dev/urandom”, we will use
NativeSeedGenerator, which calls super() which calls
SeedGenerator.URLSeedGenerator(/dev/random). (A nested class within
SeedGenerator.) The only things that changed in this bug was that
urandom will also trigger use of this code path.If those properties point to another URL that exists, we’ll initialize SeedGenerator.URLSeedGenerator(url). This is why
“file:///dev/urandom”, “file:/./dev/random”, etc. will work.
From Wikipedia on /dev/random:
In this implementation, the generator keeps an estimate of the number
of bits of noise in the entropy pool. From this entropy pool random
numbers are created. When read, the /dev/random device will only
return random bytes within the estimated number of bits of noise in
the entropy pool. /dev/random should be suitable for uses that need
very high quality randomness such as one-time pad or key generation.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.
Environmental noise?
The random number generator gathers environmental noise from device
drivers and other sources into an entropy pool. The generator also
keeps an estimate of the number of bits of noise in the entropy pool.
From this entropy pool random numbers are created.
That means in practice, it’s possible to block tomcat for an unknown amount of time.