Shulou(Shulou.com)06/01 Report--

Xiaobian to share with you Tomcat startup SecureRandom is very slow how to do, I believe most people do not know how, so share this article for everyone's reference, I hope you read this article after a lot of harvest, let's go to understand it!

SecureRandom is very slow at Tomcat startup Workaround

Recently, when running Tomcat using Alibaba Cloud's Ubuntu 16.04 ESC server, I found that Tomcat started very slowly. By checking the logs, I found that the time was mainly spent on instantiating SecureRandom objects.

As you can see from the log, instantiating the object took 253 seconds, resulting in the entire application starting for 275 seconds.

Note this entry:

org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [253,251] milliseconds.

The root cause is a problem with SecureRandom, the JRE tool class. So why is SecureRandom generateSeed so slow, even hanging on Linux?

Tomcat 7/8 both use the org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom class to generate an instance of the secure random class SecureRandom as the session ID

Tomcat uses SHA1PRNG algorithm is based on SHA-1 algorithm and strong security pseudo-random number generator.

In SHA1PRNG, there is a seed generator that performs various operations depending on the configuration.

Random numbers in Linux can be generated from two special files: /dev/urrandom and/dev/random. They generate random numbers by using the entropy pool of the current system to compute a fixed number of random bits and then returning those bits as a stream of bytes. Entropy pool is the environmental noise of the current system. Entropy refers to the degree of chaos in a system. System noise can be evaluated by many parameters, such as memory usage, file usage, number of different types of processes, etc. If the current environmental noise is not very violent or the current environmental noise is very small, such as when the power is just turned on, and a large number of random bits are currently required, the random effect of the generated random number is not very good.

This is why there are two different files: /dev/urrandom and/dev/random. The latter blocks the program when it cannot generate new random numbers, while the former does not (ublock). Of course, the random number generated is not very good, which is not a good choice for applications such as encryption and decryption./dev/random dev/random blocks the current program until new random bytes are generated from the entropy pool, so using/dev/random is slower than using/dev/urrandom to generate large numbers of random numbers.

SecureRandom generateSeed uses/dev/random to generate seeds. But/dev/random is a blocking number generator that waits if it doesn't have enough random data to supply, forcing the JVM to wait. Keyboard and mouse input, as well as disk activity, can produce the desired randomness or entropy. But in the absence of such activity on a server, problems can arise.

There are two solutions:

1. Resolving in Tomcat environment:

Non-blocking Entropy Source can be used by configuring JRE:

Add this line to catalina.sh: -Djava.security.egd=file:/dev/./ urandom can.

2. Resolved in JVM environment:

Open the file $JAVA_PATH/jre/lib/security/java.security and find the following:

securerandom.source=file:/dev/random

Replace with:

securerandom.source=file:/dev/./ urandom

Why is there a dot between dev and random? Because of a JDK bug, some people reported that it still uses/dev/random even if the securerandom.source is set to/dev/urrandom. Some people have provided workarounds, one of which is to set the securerandom.source to/dev/./ urandom only. Some people also commented that this is not a bug, it is intentional.

In JDK 7's java.security file, the configuration is:

# Select the source of seed data for SecureRandom. By default an# attempt is made to use the entropy gathering device specified by# the securerandom.source property. If an exception occurs when# accessing the URL then the traditional system/thread activity# algorithm is used.## On Solaris and Linux systems, if file:/dev/urandom is specified and it# exists, a special SecureRandom implementation is activated by default.# This "NativePRNG" reads random bytes directly from /dev/urandom.## On Windows systems, the URLs file:/dev/random and file:/dev/urandom# enables use of the Microsoft CryptoAPI seed functionality.# securerandom.source=file:/dev/urandom

But this/dev/urrandom is also equivalent to/dev/random as stated in the bug report; to use a non-blocking entropy pool, it should be modified to/dev/./ urandom。After testing, JDK 7 does not seem to fix this issue as indicated in the comments.

That's all for "SecureRandom is very slow when Tomcat starts". Thanks for reading! I believe that everyone has a certain understanding, hope to share the content to help everyone, if you still want to learn more knowledge, welcome to pay attention to the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.