1
$\begingroup$

I am trying to fix issues with a server where the server keeps freezing up and needs to be restarted. I recently started hearing about entropy and it importance to secure tls keys in linux. The one thing I haven't found in my research is, how much is needed/how to increase entropy on a linux server for TLS 1.2.

I believe this is where the issue is coming from. It started to appear when we were implementing TLS 1.2 and the randomness might not be high enough.

Have done some research on the topic, talked to a few other higher level developers but no one seems to be ale to point me in the write direction.

$\endgroup$
6
  • 1
    $\begingroup$ Generally 128 bits of entropy is enough to start a CSPRNG. Usually the /dev/(u)random should be seeded by the OS during the startup phase. If you have an embedded system you should check which entropy sources are available. If you have a virtualized system then you probably want to install the additional client tools as that should generally seed the random generator (especially useful if you have multiple instances of the same VM). $\endgroup$
    – Maarten Bodewes
    Commented Jan 24, 2023 at 19:55
  • $\begingroup$ Thank you very much! $\endgroup$ Commented Jan 24, 2023 at 19:56
  • 1
    $\begingroup$ You're welcome, I used the ale to put me in the write direction (see your last sentence) ;) $\endgroup$
    – Maarten Bodewes
    Commented Jan 24, 2023 at 19:59
  • $\begingroup$ Headless servers often suffer from a lack of entropy. If you want to increase real entropy available you can usually use rngd and have it get entropy from the CPU (e.g. RDRAND). This will add data from the CPU to the kernel's entropy pool. See linux.die.net/man/8/rngd for more information. $\endgroup$ Commented Jan 24, 2023 at 21:39
  • 1
    $\begingroup$ This has a lot of information on the topic: security.stackexchange.com/questions/186086/… $\endgroup$
    – Elias
    Commented Jan 25, 2023 at 10:35

2 Answers 2

1
$\begingroup$

While it's quite possible that any daemon (I mean MySQL in particular since my employer had trouble with it before we increased our RAM capacity) can cause a freeze, let's focus on entropy source for PRNGs since the topic of our site is cryptography.

The common practice is to use the /dev/urandom device for practically all of the randomness source.

  • On Linux, this special device does not block at all - not even when the "estimated" entropy of its seed material is low.

  • On BSDs, /dev/random and /dev/urandom behaves identically, as their developers believe that any properly designed PRNG algorithm can meet the demand even when just bare-minimum entropy is fed.

So the cryptographic advice to your problem, is to switch to /dev/urandom in your configuration.

References:

Also, keep updating software regularly (I convinced my employer to do so once a month), because if this is indeed a bug, it may get fixed in some version.

$\endgroup$
1
$\begingroup$

The proper interface to use on Linux is getrandom, which is available in most Linux distros these days. The interface will block until the CSPRNG is initialized on startup (unless GRND_NONBLOCK is specified) and never again.

That ensures that you have at least 256 bits of entropy on the system, which is enough to generate all the keys you could possibly need. The system will continually reseed the CSPRNG with new entropy as it goes along as well. Note that making sure the CSPRNG is seeded on Linux is very easy if you have a hardware RNG like RDRAND or RDSEED and you've configured CONFIG_RANDOM_TRUST_CPU in your kernel (most distros do).

On FreeBSD, getrandom is also available, and you can use getentropy or arc4random on any of the BSDs. (Technically, those are also available on Linux, but only in more recent versions of glibc.) To my knowledge, the BSDs by default ensure the OS CSPRNG is seeded appropriately on startup, provided writable media exist. See the random(4) page for your BSD for details.

On most varieties of Unix, /dev/urandom can be used as well, but on Linux it doesn't guarantee that the CSPRNG has been appropriately seeded. That's why using getrandom or getentropy is preferred.

On Windows, RtlGenRandom is the right interface.

Note that if your system is hanging after the machine has been up and serving TLS requests for a while, then it isn't a lack of entropy, because all major operating systems continue to serve data from the system CSPRNG after it's initially seeded. As mentioned, 256 bits of entropy is sufficient to generate a virtually unlimited amount of random data on the system (especially considering the fact that you'll reboot now and again for kernel security updates), so there's no need to block once correctly seeded.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.