java - 适用于 Linux 和 RandomSource 的 Oracle Java 8 x64

Question

我真的认为在各种平台上安装了大约 200 次或更多的 Tomcat 之后，我已经准备好迎接任何挑战，但这个挑战很棘手。

我创建了一个普通的 Ubunutu 14_04 镜像，并在该系统上从 oracle 安装了 Java 8 TGZ。此外，我在游戏中添加了一个 tomcat 8。然后我开始安装 Vanilla 服务器。

在部署tomcat附带的默认应用程序后不久，我想知道那里发生了什么并做了一些线程转储。这是阻止tomcat启动的糟糕线程:

"localhost-startStop-1" #15 daemon prio=5 os_prio=0 tid=0x00007f37c8004800 nid=0x4d6 runnable [0x00007f37b38b3000]
   java.lang.Thread.State: RUNNABLE
    at java.io.FileInputStream.readBytes(Native Method)
    at java.io.FileInputStream.read(FileInputStream.java:246)
    at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539)
    at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
    at sun.security.provider.SecureRandom$SeederHolder.<clinit>(SecureRandom.java:192)
    at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:210)
    - locked <0x00000000f06e6ce8> (a sun.security.provider.SecureRandom)
    at java.security.SecureRandom.nextBytes(SecureRandom.java:457)
    - locked <0x00000000f06e71c0> (a java.security.SecureRandom)
    at java.security.SecureRandom.next(SecureRandom.java:480)
    at java.util.Random.nextInt(Random.java:329)
    at org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom(SessionIdGeneratorBase.java:234)

经过更多的谷歌和 friend 之后，我发现 JDK 附带的 SeedGenerator 是我问题的根源。有趣的是，有时 SeedGenerator 会在几分钟后回来，有时它只是挂起(用完熵？...通过 cat/proc/sys/kernel/random/entropy_avail 检查)。经过更多研究，我发现 $JAVA_HOME$/lib/security/java.security 中名为 securerandom.source 的配置变量定义了 Random 的来源。在我的情况下，或者更好的是为 linux 安装的 oracle JDK 8，它是 /dev/random。我不是 Linux 专家(我是 Java 开发人员)，但我的理解是 /dev/random 可能会耗尽熵(无论这意味着什么)，但也许这意味着它在某些时候无法生成任何更多的随机数)。我切换到 /dev/urandom 并且我的 tomcat 一切正常。

然后我检查了其他 JDK 安装在我的其他各种服务器上的样子，这些服务器是 OpenJDK 和较旧的 Oracle JDK 安装的狂野组合。至少 OpenJDK 总是使用 /dev/urandom 这可能是答案，为什么我以前从未遇到过问题。

现在我的问题:当存在操作系统无法生成更多数字的极端情况时，Oracle 依赖 /dev/random 是否明智？我的意思是像 Tomcat 和许多其他服务器这样的服务器依赖于 JDK 中的 SeedGenerator 并且调试这种错误非常先进。我花了 2 个小时才到达现在的位置。

Answer 1

我认为答案取决于此链接以获得 WebLogic 支持:https://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html他们提到“随机”更安全

以及 Oracle 错误评论(David 已经提到):http://bugs.java.com/view_bug.do?bug_id=4705093

特别注意这部分:

Because SHA1PRNG is a MessageDigest-based PRNG, it historically has always used /dev/random for initial seeding if seed data has not been provided by the application. Since all future values depend on the existing state of the MessageDigest, it's important to start with a strong initial seed.

Changing that behavior was troubling to the original developer. So he did created a new SecureRandom impl called NativePRNG, which does respect the java.security.egd value.

If you call:

• new SecureRandom() on Linux and the default values are used, it will read from /dev/urandom and not block. (By default on Solaris, the PKCS11 SecureRandom is used, and also calls into /dev/urandom.)

• SecureRandom.getInstance("SHA1PRNG") and do not specify a seed, OR new SecureRandom() but have specified an alternate java.security.egd besides "file:/dev/urandom", it will use the SHA1PRNG which calls into /dev/random and may potentially block.

• SecureRandom.getInstance("NativePRNG"), it will depend on what java.security.egd is pointing to.