Tomcat 启动时间过长 - Java SecureRandom [英] Tomcat takes too much time to start - Java SecureRandom

问题描述

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

• Tomcat7 在 Ubuntu 14.04 x64 上启动太晚 [数字海洋]
• https://stackoverflow.com/a/2325109/6785908

我明白了，替换

securerandom.source=file:/dev/urandom

与

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

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

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

更新

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

解决方案

在使用正确的搜索词进行广泛的谷歌搜索后，我在 DigitalOcean.我这里只是引用相关部分.

<块引用>

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

所以，这是一个潜在的安全风险.

填充熵池的解决方案

<块引用>

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

解决方案:已经过

<块引用>

基于 HAVEGE 原理，之前基于其关联库，haged 允许根据变化生成随机性处理器上的代码执行时间.因为这几乎是不可能的一段代码需要相同的确切时间来执行，即使在相同硬件上相同环境，运行单个的时序或者多个程序应该适合随机源.这hasged 实现种子你的系统的随机源(通常/dev/random) 使用处理器时间戳计数器的差异(TSC) 重复执行一个循环后

如何安装haged

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

Please don't mark it as duplicate. It is a follow up question for both these questions.

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

I understand that, replacing

securerandom.source=file:/dev/urandom

with

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

in $JAVA_PATH/jre/lib/security/java.security will solve this problem.

My question is, is it ok to do so in production? Will this have any impact on security (like Session ID becoming predictable)? If this is less secure, is there any other way to give enough entropy quicker?

Update

I use openstack for deployment (or let's just say, uses AWS or GCP or any other cloud provider). So, adding a hardware device such as soundcard is not an option for me.

解决方案

After some extensive Googling with the right search terms, I came across this nice article on DigitalOcean. I am merely quoting the relevant part here.

There are two general random devices on Linux: /dev/random and /dev/urandom. The best randomness comes from /dev/random, since it's a blocking device, and will wait until sufficient entropy is available to continue providing output. Assuming your entropy is sufficient, you should see the same quality of randomness from /dev/urandom; however, since it's a non-blocking device, it will continue producing "random" data, even when the entropy pool runs out. This can result in lower quality random data, as repeats of previous data are much more likely. Lots of bad things can happen when the available entropy runs low on a production server, especially when this server performs cryptographic functions.

So, its a potential security risk.

Solution for Populating Entropy Pools

Linux already gets very good quality random data from the different hardware sources, but since a headless machine usually has no keyboard or mouse, there is much less entropy generated. Disk and network I/O represent the majority of entropy generation sources for these machines, and these produce very sparse amounts of entropy. Since very few headless machines like servers or cloud servers/virtual machines have any sort of dedicated hardware RNG solution available, there exist several userland solutions to generate additional entropy using hardware interrupts from devices that are "noisier" than hard disks, like video cards, sound cards, etc. This once again proves to be an issue for servers unfortunately, as they do not commonly contain either one

Solution: haveged

Based on the HAVEGE principle, and previously based on its associated library, haveged allows generating randomness based on variations in code execution time on a processor. Since it's nearly impossible for one piece of code to take the same exact time to execute, even in the same environment on the same hardware, the timing of running a single or multiple programs should be suitable to seed a random source. The haveged implementation seeds your system's random source (usually /dev/random) using differences in your processor's time stamp counter (TSC) after executing a loop repeatedly

How to install haveged

Follow the steps in this article. https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

这篇关于Tomcat 启动时间过长 - Java SecureRandom的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！