Home / server / Questions / 153604
Accepted
Eric3
Asked: 2010-06-23 05:52:49 +0800 CST

Qmail says "PRNG not seeded" when sending mail to certain servers

  • 772

We recently moved a web server running Fedora 2 and Plesk 8.2.1 to a virtual machine. Since then, qmail has been refusing to send messages to certain servers, complaining in the mail log that "TLS_connect_failed:_error:24064064:random_number_generator:SSLEAY_RAND_BYTES:PRNG_not_seeded". Evidently this is an OpenSSL problem related to the switch from actual to virtual hardware. Is there a way to change where OpenSSL is getting its random data from, or at least to tell qmail to fall back on non-secure protocols SSL/TLS doesn't work?

email openssl

2 Answers

  1. Best Answer

    Have you checked to make sure /dev/random and /dev/urandom exist on the system? I found this site with instructions for recreating them if they don't.

    http://eitwebguru.com/fix-prng-is-not-seeded/

    • 1

  2. As well as making sure that the relevant devices exist (as per David Smith's answer) you need to make sure there is actually some entropy in the pool.

    cat /proc/sys/kernel/random/entropy_avail will tell you its current level. If there is not enough then sending mail through a TLS stream (i.e. encrypted) will either block (waiting for there to be enough) or fail, unless you mail transfer agent is happy to use the non-blocking random device instead (which as its name suggests does not block, but is theoretically less secure).

    The entropy pool is replenished by the kernel over time using data from interrupt timings caused by I/O operations, but if the machine (or VM) does not see much activity it takes a long time for the pool to grow are there are very few I/O operations to collect timings from.

    On a small machine at our company that acts as nothing more then the internet gateway an SMTP relay we hit this problem with exim. To work around it I simply set a small script running via init that does nothing but slowly read from a disk by running pv --rate-limit 2m /home/4GigFile > /dev/null then sleeping the 30 seconds in a loop. Your VM provider is unlikely to be fond of this solution as it imposes unnecessary extra I/O load on the host machine - you might though get away with a less aggressive script that checks the content of /proc/sys/kernel/random/entropy_avail and only runs the arbitrary I/O operation of the loop if the value found is less than, say, 1000.

    There are scripts/tools out there that allow you to pull "random" values from other sources to feed the entropy pool too. If you are happy to give the MTA a less truly random (so less secure) entropy source, you could try feed the entropy pool from '/dev/urandom' using rngd or even just make /dev/random a synlink to /dev/urandom, though some software will be thorough enough to check for that and fail if they are configured by default to be paranoid about the quality of their entropy source.

    Edit:

    You are only experiencing this issue intermittently for one or both of two reasons: firstly the pool may be sufficiently populated most of the time, and secondly qmail may be communicating with some servers through plain (unencrypted) streams as a fall-back (some, possibly many, receiving servers will refuse non-encrypted connections so this fall-back can not always be used when negotiating a TLS connection fails).

    • 1