用于Linux和RandomSource的OracleJava8 x64
我真的认为，在各种平台上安装了大约200或更多的tomcat之后，我已经准备好迎接任何类型的挑战，但这一次是棘手的。
我创建了一个普通的Ubunutu 14_04镜像，并在该系统上安装了oracle的Java8TGZ。此外，我在游戏中添加了Tomcat8。然后，我开始安装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)在更多的google &朋友之后，我发现JDK附带的SeedGenerator是我问题的根源。有趣的是，有时SeedGenerator会在几分钟后返回，有时会挂起(熵耗尽？通过cat /proc/sys/kernel/random/entropy_avail检查)。经过进一步的研究，我发现$JAVA_HOME$/lib/security/java.security中一个名为securerandom.source的配置变量定义了随机数的来源。在我的例子中，或者在用于linux的oracle jdk8安装中，它是/dev/random。我不是Linux专家(我是java开发人员)，但我所理解的是，/dev/random可能会用完熵(不管这意味着什么)，但也许这意味着在某个时候它不能再生成任何随机数了。我切换到/dev/urandom，我的tomcat一切正常。
然后，我检查了其他JDK安装在我的其他不同服务器上的外观，这些服务器是OpenJDK和较早的Oracle JDK安装的混合。至少OpenJDK总是使用/dev/urandom，这可能是答案，为什么我以前从来没有遇到过这个问题。
甲骨文现在来问我的问题：在操作系统无法生成更多数字的情况下，依赖/dev/random是明智的吗？我的意思是像Tomcat这样的服务器和许多其他服务器依赖于JDK中的SeedGenerator，调试这种错误真的很高级。我花了2个小时才走到现在这一步。
回答 2
Stack Overflow用户
发布于 2015-10-10 21:18:21
我认为答案依赖于这个WebLogic支持的链接：https://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html，在那里他们提到“随机”更安全
在Oracle bug评论中(大卫已经提到过)：http://bugs.java.com/view_bug.do?bug_id=4705093
特别是关于这一部分：
因为SHA1PRNG是基于MessageDigest的PRNG，所以如果应用程序没有提供种子数据，它过去总是使用/dev/作为初始种子。由于所有未来的值都取决于MessageDigest的现有状态，因此从一个强大的初始种子开始是很重要的。
改变这一行为对最初的开发人员来说是麻烦的。因此，他创建了一个名为NativePRNG的新SecureRandom实现，它确实尊重java.security.egd的值。
如果你打电话给：
在Linux上使用
- 新的SecureRandom()和默认值，它将从/dev/urandom读取，而不是阻塞。(缺省情况下，在Solaris上使用PKCS11 SecureRandom，也会调用/dev/urandom.)
- SecureRandom.getInstance("SHA1PRNG")和没有指定种子，也没有指定新的SecureRandom()，但指定了“java.security.egd :/dev/urandom”之外的替代文件，它将使用调用/dev/
- SecureRandom.getInstance(“SHA1PRNG”)的SHA1PRNG，并且可能会阻塞。
- SecureRandom.getInstance("NativePRNG")，它将取决于java.security.egd所指向的内容。
Stack Overflow用户
发布于 2015-10-12 21:29:23
我所理解的是，/dev/
可能会用完熵(不管这意味着什么)，但也许这意味着在某个时刻它不能再生成更多的随机数)。
它可能会暂时耗尽熵并阻塞，直到它聚集到足够的量来分配更多的熵。JVM只需要很少的代码就可以作为SecureRandom实例的种子。
需要多长时间取决于你的系统有多嘈杂以及内核是如何收集熵的。
在操作系统无法生成更多数字的情况下，
依赖/dev/random是否明智？
熵的缺乏在嵌入式系统上或首次启动时的VM中可能是有问题的，这些系统具有非常确定的映像，与真实PC相比，几乎没有可获取的熵源，并且没有RDRAND指令或类似指令可供内核获取以用于熵池初始化。
不足的随机性对于密钥生成和其他密码算法，例如DSA is quite sensitive to the quality of your entropy source，可能是灾难性的。
所以，是的，与其让系统受损，不如等待是相当明智的。
引用N.Heninger等人的Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices。
为了了解为什么会出现这些问题，我们手动调查了数百台易受攻击的主机，这些主机代表了最常见的重复密钥以及我们获得的每个私钥( 3.2节)。几乎所有提供的信息都将它们标识为无头系统或嵌入式系统，包括路由器、服务器管理卡、防火墙和其他网络设备。这种设备通常在第一次启动时自动生成密钥，并且与传统PC相比，可能具有有限的熵源。
此外，当我们检查共享关键字或因素的主机群集时，几乎所有情况下，这些群集似乎都与制造商或设备型号相关联。这些观察结果使我们得出结论，这些问题是由特定的有缺陷的实现引起的，这些实现在没有收集足够的熵的情况下生成了键。
如果你有一个外部的熵和根权限来源，你可以使用push additional entropy into the pool and increment its counter (我认为rngd可以帮你做到这一点)。只需写入/dev/random即可将您的熵添加到池中，但不会增加计数器。
对于虚拟机，还可以使用virtualization drivers从主机获取熵。
将jvm指向硬件RNG dev (/dev/hwrng、/dev/misc/hw_random或类似的东西)也可能是一种选择，如果它们可用的话。
https://stackoverflow.com/questions/26227344
复制相似问题