Tomcat需要太多时间才能启动 - Java SecureRandom

Question

请不要将其标记为重复.对于这两个问题,这是一个后续问题.

• Tomcat7在Ubuntu 14.04 x64上启动太晚[Digitalocean]
• /sf/answers/162757661/

我理解,替换

securerandom.source=file:/dev/urandom

同

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

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

我的问题是,在制作中这样做是否可以？这会对安全性产生什么影响(比如会话ID变得可预测)？如果这不太安全,还有其他方法可以更快地提供足够的熵吗？

更新

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

Answer 1

经过一些广泛的谷歌搜索与正确的搜索术语后,我在DigitalOcean上看到了这篇很好的文章.我只是在这里引用相关部分.

Linux上有两个通用的随机设备:/ dev/random和/ dev/urandom.最好的随机性来自/ dev/random,因为它是一个阻塞设备,并将等到有足够的熵可用于继续提供输出.假设你的熵足够,你应该从/ dev/urandom看到相同的随机性质; 但是,由于它是一个非阻塞设备,它将继续产生"随机"数据,即使熵池耗尽也是如此.这可能导致较低质量的随机数据,因为更可能重复先前的数据.当生产服务器上的可用熵不足时,可能会发生很多不好的事情,特别是当此服务器执行加密功能时.

因此,它存在潜在的安全风险.

填充熵池的解决方案

Linux已经从不同的硬件源获得了非常好的随机数据,但由于无头机器通常没有键盘或鼠标,因此产生的熵少得多.磁盘和网络I/O代表这些机器的大部分熵生成源,并且这些生成非常稀疏的熵量.由于很少有像服务器或云服务器/虚拟机这样的无头机器可以使用任何类型的专用硬件RNG解决方案,因此存在多种用户域解决方案,使用比硬盘(如视频卡)更"嘈杂"的设备的硬件中断来生成额外的熵.不幸的是,这再次被证明是服务器的问题,因为它们通常不包含任何一个

解决方案:疯狂

基于HAVEGE原理,并且之前基于其相关联的库,hasged允许基于处理器上的代码执行时间的变化来生成随机性.由于一段代码几乎不可能花费相同的执行时间,即使在同一硬件上的相同环境中,运行单个或多个程序的时间也应该适合种子随机源.在反复执行循环后,使用处理器的时间戳计数器(TSC)中的差异,伪造的实现会使系统的随机源(通常为/ dev/random)变为种子

如何安装hasged

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