Tomcat7 Starts Too Late on Ubuntu 14.04 X64 [Digitalocean]

Tomcat7 starts too late on Ubuntu 14.04 x64 [Digitalocean]

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.

1. 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.

2. 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.

Tomcat takes too much time to start - Java SecureRandom

After some extensive Googling with the right search terms, I came across this nice article on DigitalOcean. I am merely quoting the relevant part here.

There are two general random devices on Linux: /dev/random and
/dev/urandom. The best randomness comes from /dev/random, since it's a
blocking device, and will wait until sufficient entropy is available
to continue providing output. Assuming your entropy is sufficient, you
should see the same quality of randomness from /dev/urandom; however,
since it's a non-blocking device, it will continue producing “random”
data, even when the entropy pool runs out. This can result in lower
quality random data, as repeats of previous data are much more likely.
Lots of bad things can happen when the available entropy runs low on a
production server, especially when this server performs cryptographic
functions.

So, its a potential security risk.

Solution for Populating Entropy Pools

Linux already gets very good quality random data from the
different hardware sources, but since a headless machine usually
has no keyboard or mouse, there is much less entropy generated. Disk
and network I/O represent the majority of entropy generation sources
for these machines, and these produce very sparse amounts of entropy.
Since very few headless machines like servers or cloud servers/virtual
machines have any sort of dedicated hardware RNG solution available,
there exist several userland solutions to generate additional entropy
using hardware interrupts from devices that are “noisier” than hard
disks, like video cards, sound cards, etc. This once again proves to
be an issue for servers unfortunately, as they do not commonly contain
either one

Solution: haveged

Based on the HAVEGE principle, and previously based on its associated
library, haveged allows generating randomness based on variations in
code execution time on a processor. Since it's nearly impossible for
one piece of code to take the same exact time to execute, even in the
same environment on the same hardware, the timing of running a single
or multiple programs should be suitable to seed a random source. The
haveged implementation seeds your system's random source (usually
/dev/random) using differences in your processor's time stamp counter
(TSC) after executing a loop repeatedly

How to install haveged

Follow the steps in this article. https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Slow startup on Tomcat 7.0.57 because of SecureRandom

The secure random calls may be blocking as there is not enough entropy to feed them in /dev/random.

If you have the line

securerandom.source=file:/dev/random

in /jre/lib/security/java.security, changing this to urandom may improve things (although this is probably already the default).

Alternatively there are some suggestions on how to feed the pool here

https://security.stackexchange.com/questions/89/feeding-dev-random-entropy-pool

Can't hit Springboot endpoint on droplet

I am using digital ocean to host my personal toy website built with spring boot and embedded tomcat without a problem.

Multiple things can happen:

• The http port 8080 is not opened to public. (This solved my issue)
• Firewall is preventing port 8080 from being visited.

Assuming your app is on port 8080. Change accordingly.

---

Related Topics