Tomcat 启动时间过长 - Java SecureRandom

Question

请不要将其标记为重复。这是这两个问题的后续问题。

• Tomcat7 starts too late on Ubuntu 14.04 x64 [Digitalocean]
• https://stackoverflow.com/a/2325109/6785908

我明白，替换

securerandom.source=file:/dev/urandom

与

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

在$JAVA_PATH/jre/lib/security/java.security会解决这个问题。

我的问题是，可以在生产中这样做吗？这会对安全性产生任何影响（例如 Session ID 变得可预测）？如果这不太安全，有没有其他方法可以更快地提供足够的熵？

更新

我使用 openstack 进行部署（或者说，使用 AWS 或 GCP 或任何其他云提供商）。因此，添加声卡等硬件设备对我来说不是一个选择。

Answer 1

在使用正确的搜索词进行大量谷歌搜索后，我在DigitalOcean 上看到了这篇不错的文章。我只是在这里引用相关部分。

Linux 上有两种通用的随机设备：/dev/random 和 /dev/urandom。最好的随机性来自 /dev/random，因为它是 阻塞设备，并将等待直到足够的熵可用 继续提供输出。假设你的熵是足够的，你 应该从 /dev/urandom 看到相同质量的随机性；然而， 因为它是一个非阻塞设备，它会继续产生“随机” 数据，即使熵池用完。这可能导致较低 质量随机数据，因为更可能重复以前的数据。 当可用熵在 生产服务器，尤其是当此服务器执行加密时 功能。

因此，这是一个潜在的安全风险。

填充熵池的解决方案

Linux 已经从 不同的硬件来源，但由于无头机器通常 没有键盘或鼠标，产生的熵要少得多。磁盘 和网络 I/O 代表大部分熵生成源 对于这些机器，它们产生的熵非常少。 由于很少有无头机器，如服务器或云服务器/虚拟 机器有任何可用的专用硬件 RNG 解决方案， 存在几种用户态解决方案来产生额外的熵 使用来自比硬件“更嘈杂”的设备的硬件中断 磁盘，如视频卡、声卡等。这再次证明 不幸的是，这对服务器来说是一个问题，因为它们通常不包含 任何一个

解决方案：已解决

基于 HAVEGE 原则，之前基于其相关的 图书馆，haveged 允许根据变化产生随机性 处理器上的代码执行时间。因为这几乎是不可能的 一段代码花费相同的确切时间来执行，即使在 同环境同硬件，单机运行时序 或多个程序应该适合播种随机源。这 haveged 实现为您系统的随机源提供种子（通常 /dev/random) 使用处理器时间戳计数器的差异 (TSC) 重复执行循环后

如何安装haveged

按照本文中的步骤操作。 https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Answer 2

如果有人遇到这个问题

我刚刚通过删除所有调试器 BREAKPOINTS 解决了我的问题。