What do I need to configure, to make sure my software uses /dev/urandom?

Question

When setting up a server, what configuration changes do I need to make sure that all of the software uses /dev/urandom instead of /dev/random?

Some servers don't have much entropy in the entropy pool (e.g., VPSs). If a software component uses /dev/random, then it may block and cause the server to become mysteriously slower. Is there any software that comes out-of-the-box using /dev/random by default? If so, how can I configure it to force it to use /dev/urandom? It'd be nice to have a checklist of configuration settings to set, when setting up a new VPS environment.

Voted to close as too broad, for the reason explained in my answer on meta. — Gilles 'SO- stop being evil', May 01 '12 at 00:21
@Gilles I dont think it's too broad, though admittedly a list of problematic programs would never be complete - but it would be *effectively* complete, once it covers most of the most common programs. And, it should continue to incrementally be added to.... Though I agree about the "one per answer". — AviD, May 01 '12 at 07:54
Should be one answer to your own question, not six. Please merge them. @Gilles lol@"Welcome" :) — Jeff Ferland, May 01 '12 at 08:38

score 27 · Answer 1 · edited Feb 20 '17 at 17:47

27

General advice

Any program written in Java

Add

-Djava.security.egd=file:///dev/urandom switch

or

-Djava.security.egd=file:/dev/./urandom

to the command line invocation used to start the Java process. (Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly.)

Alternatively, in the $JAVA_HOME/jre/lib/security/java.security configuration file, add the line

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

Footnote: In the above examples, you need the crazy-looking filename, e.g., the extra /./, to trick Java into accepting your filename. If you just use /dev/urandom, Java decides you didn't really mean it and replaces what you wrote with /dev/random. Craziness!

Chroot

If you are starting some service in a chroot environment, don't forget to create the /dev/urandom device inside your chroot directory.

Specific software

Apache mod_ssl

Use

SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect file:/dev/urandom 512

in the mod_ssl configuration file. Avoid using file:/dev/random with SSLRandomSeed.

Cyrus POP3, IMAPD, and SASL

Compile Cyrus SASL (libsasl) with the configuration flag --with-devrandom=/dev/urandom.

By default, Cyrus POP3 reads from /dev/random. I couldn't find any configuration setting to change this, short of recompiling.

OpenLDAP

Add

TLSRandFile /dev/urandom

to the slapd.conf configuration file. (This hopefully should be the default, but some guides misleadingly suggest using /dev/random, so you might want to double-check.)

Postfix

Use

tls_random_source = dev:/dev/urandom

in the main.cf configuration file, or

sudo postconf -e 'tls_random_source = dev:/dev/urandom'

from the command line.

edited Feb 20 '17 at 17:47

tanius

105
3

answered Apr 30 '12 at 23:15

D.W.

98,860
33
271
588

Are `SSLRandomSeed startup builtin` and `SSLRandomSeed connect builtin` good enough to use? – kittygirl Nov 05 '18 at 15:30
@kittygirl, I would not recommend using those. As [the mod_ssl documentation](http://www.modssl.org/docs/2.2/ssl_reference.html#ToC4) states, "this is not really a strong source", and it explains the source of the seed (which is not terrible but not ideal). I recommend `file:/dev/urandom` instead of `builtin`. – D.W. Nov 05 '18 at 16:48
I have no idea why the author of this answer hit a problem with using `/dev/urandom`. Maybe there was a bug in JDK or something else. Generally, the `/dev/urandom` and `/dev/./urandom` path work the same, but only the first one works correcly on Windows machines. I described how it works with OpenJDK source code examples in my answer: https://security.stackexchange.com/a/244954/251259 – agabrys Feb 17 '21 at 08:31
I saw an article at redhat.com that mentioned the /dev/./urandom issue with openjdk 6 and 7. – Dan Pritts Jun 04 '21 at 17:59
@agabrys, this is a super old answer, and I don't know whether it's still needed any more. Maybe it was a bug in an old JDK. I don't have time to investigate but maybe someone else will. It's a little tricky to test: if indeed the JDK is still remapping that to /dev/random, it's likely that everything will appear to "work" as far as can be observed externally (because on most machines, after they've been running for a while, /dev/random won't block if you call it once), so it might take some extra doing to get a definitive answer. – D.W. Jun 04 '21 at 18:43
@D.W. According to this, not anymore: https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html – Whimusical Feb 05 '22 at 22:24

David Schwartz · Answer 2 · 2012-05-01T10:37:43.440

20

Everything:

As root, just do this:

rm /dev/random
mknod /dev/random c 1 9

Now /dev/random will actually access the same underlying logic as /dev/urandom.

After this change, both /dev/random and /dev/urandom will draw from the non-blocking pool. The non-blocking pool will draw from the blocking pool, which the system will still fill.

edited May 01 '12 at 10:37

answered May 01 '12 at 06:05

David Schwartz

4,233
24
21

Is this safe? I was under the impression that `/dev/urandom` is seeded from entropy in `/dev/random` - wouldn't such an operation cause `/dev/urandom` to end up seeding itself, using only a CSPRNG and no new entropy? – Polynomial May 01 '12 at 09:43
4

Yes, it's safe. After this change, `/dev/random` becomes just another name for `/dev/urandom`. So nothing you previously knew about `/dev/random` applies any more. (Specifically, it is no longer in any way associated with the pool that `/dev/urandom` draws off.) – David Schwartz May 01 '12 at 10:34
13

@Polynomial “`/dev/urandom` is seeded from entropy in `/dev/random`” is a shortcut. Actually, `/dev/random` and `/dev/urandom` are both doorways into the same driver inside Linux kernel. The entropy feed happens inside the kernel. Erasing the label on one of the doorways doesn't change what happens under the hood. – Gilles 'SO- stop being evil' May 01 '12 at 10:55
1

afaik, freebsd is using prng for both /dev/urandom and /dev/random – Dog eat cat world May 03 '12 at 22:45
@Dogeatcatworld: The same is true of Linux. – David Schwartz May 03 '12 at 23:00
@DavidSchwartz, are you sure? I read somewhere that /dev/random does not block on freebsd, regardless of entropy – Dog eat cat world May 04 '12 at 08:58
1

@Dogeatcatworld: A PRNG can either block or not block, it's still a PRNG. – David Schwartz May 04 '12 at 11:27
Blocking is a bad choice, it could reveal keystrokes (used to generate entropy among other things) for instance. – Aki May 30 '12 at 14:03
This is not safe! When you first boot linux or restore a snapshot, /dev/urandom has predictable outputs. Programs that read /dev/random do so in order to avoid this. – Navin Jan 07 '16 at 18:39
2

@Navin It does remove a safety against broken startup. You're still safe as long as your startup logic correctly seeds the entropy pool. If you're paranoid, you could add an extra startup script that runs after the pool is supposed to be seeded and checks to make sure that the pool actually was seeded and halts the system if it isn't. – David Schwartz Jan 07 '16 at 18:43
@DavidSchwartz This is not a broken startup, it is a normal first-boot. Collecting entropy on a headless server (probably the only case where you actually *need* good random numbers) takes time. Why would you halt the whole system instead of blocking your webserver until it can seed its own rng using `/dev/random`? – Navin Jan 08 '16 at 12:05
@Navin You would do that because it's the best of a bad set of options. Ideally, it would block only if the PRNG had never been seeded, but there is no easy way to get that functionality. A delay in startup is a fair tradeoff for reliable operation, and you can easily control/minimize that delay by using an entropy gathering deamon. – David Schwartz Jan 08 '16 at 16:03
2

@DavidSchwartz Fair enough. Maybe one of these days, linux will get a new `/dev/srandom` device which blocks until it is reseeded and never blocks again. Then I can hardlink it to `/dev/random`. A man can dream. – Navin Jan 09 '16 at 12:08

score 8 · Answer 3 · edited Mar 17 '17 at 13:14

Great initiative by D.W. to list different software configurations (I am a die-out fan of D.W. already)

BUT - As I mentioned on my previous comment, On my VPS servers I personally still prefer to install one single component (haveged) that gets everything running smoothly.

Perhaps @DavidSchwartz's suggestion is the only one that could be even easier, but I haven't tried it.

Individually configuring each component instead of the underlying entropy pool sounds a little silly to me to be perfectly honest. When I have a problem, I try to solve the root cause and keep the DRY principle.

score 3 · Answer 4 · answered May 01 '12 at 01:06

3

PHP

For PHP sessions you can use /dev/urandom as an entropy source

session.entropy_file = /dev/urandom

answered May 01 '12 at 01:06

rook

47,004
10
94
182

agabrys · Answer 5 · 2021-02-17T08:48:05.247

JAVA Application/Server

I would recommended to read the Everything about Java's SecureRandom article.

TL;DR

You have two options:

set the java.security.egd system property to file:/dev/urandom. The easiest option is to configure it by using the JAVA_TOOL_OPTIONS environment variable:
```
export JAVA_TOOL_OPTIONS = '-Djava.security.egd=file:/dev/urandom'
```
set the securerandom.source security property in the Java Security file to file:/dev/urandom:
```
securerandom.source=file:/dev/urandom
```
It could be defined in the following locations:
- $JAVA_HOME/jre/lib/security/java.security (all JDK versions)
- $JAVA_HOME/conf/security (JDK 9+)

Don't use /dev/./urandom

Don't use the mentioned file:/dev/./urandom path. The sun.security.provider.SeedGenerator class supports paths as follow:

for /dev/random and /dev/urandom it creates an instance of the NativeSeedGenerator class. For Unix the implementation is very simple (see the class):
```
  class NativeSeedGenerator extends SeedGenerator.URLSeedGenerator {

      NativeSeedGenerator(String seedFile) throws IOException {
          super(seedFile);
      }

  }
```
It only extends the sun.security.provider.SeedGenerator.URLSeedGenerator class.
for all other paths it creates an instance of the sun.security.provider.SeedGenerator.URLSeedGenerator class with the configured path.

It generally means that setting /dev/./urandom works the same as setting /dev/urandom. There is only one difference - it works only on Unix machines. On Windows it throws IOException because /dev/./urandom is an invalid path. /dev/urandom works because for this path a new instance of the Windows compatible NativeSeedGenerator class is created.

The core part of the sun.security.provider.SeedGenerator class:

/*
 * Try the URL specifying the source (e.g. file:/dev/random)
 *
 * The URLs "file:/dev/random" or "file:/dev/urandom" are used to
 * indicate the SeedGenerator should use OS support, if available.
 *
 * On Windows, this causes the MS CryptoAPI seeder to be used.
 *
 * On Solaris/Linux/MacOS, this is identical to using
 * URLSeedGenerator to read from /dev/[u]random
 */
if (egdSource.equals(SunEntries.URL_DEV_RANDOM) ||
        egdSource.equals(SunEntries.URL_DEV_URANDOM)) {
    try {
        instance = new NativeSeedGenerator(egdSource);
        if (debug != null) {
            debug.println(
                "Using operating system seed generator" + egdSource);
        }
    } catch (IOException e) {
        if (debug != null) {
            debug.println("Failed to use operating system seed "
                          + "generator: " + e.toString());
        }
    }
} else if (egdSource.length() != 0) {
    try {
        instance = new URLSeedGenerator(egdSource);
        if (debug != null) {
            debug.println("Using URL seed generator reading from "
                          + egdSource);
        }
    } catch (IOException e) {
        if (debug != null) {
            debug.println("Failed to create seed generator with "
                          + egdSource + ": " + e.toString());
        }
    }
}