slow in containerized environment, timeout for TLS connectivity

ISSUES: 

For TLS connectivity, it is slow in containerized environment that might be blocked on random number generation.

eg: in FIPS env, you must enable TLS for all JDBC connectivity, the JDBC driver may take quite a long time in establishing the JDBC connection to the DB server.

CAUSE:

Refer to this doc on how to use securerandom (https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/) It explains in detail why using /dev/random is horribly on the container-based solution, and the implementation of NativePRNGNonBlocking will rely on /dev/urandom, which is non-blocking.

SHA1PRNG (Initial seeding is currently done via a combination of system attributes and the java.security entropy gathering device) NativePRNG (nextBytes() uses /dev/urandom, generateSeed() uses /dev/random) NativePRNGBlocking (nextBytes() and generateSeed() use /dev/random) NativePRNGNonBlocking (nextBytes() and generateSeed() use /dev/urandom)

SOLUTION:
adding securerandom.strongAlgorithms=NativePRNGNonBlocking:SUN,DRBG:SUN to the fips.security file, which would override the default security file java. security.

https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/

The article discusses generating secure random numbers in JDK 1.8, presenting two methods using SecureRandom. The default method uses /dev/urandom, while the alternative uses /dev/random, potentially blocking the thread. However, there's no advantage in using /dev/random over /dev/urandom.

In a containerized environment like Docker, /dev/random may block, impacting performance. 

It suggests seeding /dev/random with an entropy server or CPU time stamp counter. 

The article delves into SecureRandom implementations, debugging options, and recommends using "NativePRNGNonBlocking" for most cases or "SHA1PRNG" on Windows. It warns about potential randomness issues with "SHA1PRNG" and recommends /dev/urandom for certainty.