trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Thompson <>
Subject Re: Secure usage of /dev/random vs /dev/urandom
Date Wed, 01 Nov 2017 21:22:03 GMT

The discussion context was along the lines of an ATS plugin written to
manage sharing of TLS session information and session ticket encryption key
information amongst a group of nodes behind a load balancer.     The
question was which source of random is used for key material of the TLS
session-ticket-encryption-key (STEK) in our own STEK plugin handler (not

STEK is the key that a TLS server will use to encrypt/decrypt all TLS
session tickets.  It is among one of the most sensitive tidbits on the
server, as with it, one can decrypt all client session tickets (which
contain the individual session keys that encrypt/decrypt bulk data), for
all clients resumption to a TLS cluster that shares the STEK.   Common
practice is to generate/rotate STEK every <24 hour period.

The actual coordination of STEK rotation and generation is outside the
scope of ATS, with the details likely deployment environment constrained.
ATS has more than one mechanism for external processes to set this.   By
default ATS will generate a STEK each time it is started, though for a
multi-node ATS cluster, this is not functional as each node would have
different STEKs (resumptions would typically fail ), nor is it secure (e.g.
lack of rotation).   As such I would speculate (hope) most would roll their
own handler.

Dave Thompson

On Tue, Oct 31, 2017 at 10:50 AM, Eric Friedrich (efriedri) <> wrote:

> Dave-
>   Thanks for the explanation. I wasn’t at the summit, so am likely missing
> some context.
> Doesn’t ATS rely on openssl to manage random number generation?
> —Eric
> On Oct 30, 2017, at 6:21 PM, Dave Thompson <> wrote:
> At the ATS summit last week, there was some confusion regarding
> appropriate use of /dev/random vs /dev/urandom .  Depending on the usage,
> exploits associated with getting this wrong can be severe.  I'll sleep
> better, not letting this drop before attempting to explain which is an
> appropriate source. ;-)
> From a linux perspective, the difference between these two sources of
> random data is that one is an entropy tracking source (/dev/random) which
> will block reads while the entropy pool is low, versus /dev/urandom which
> will always return a timely response regardless of the state of the entropy
> pool. When random numbers come from a deterministic pseudo-random number
> generator algorithm, the only real thing that is actually random is that
> which is collected in the entropy pool.
> The linux entropy tracked source does come at a cost.   I have measured
> upwards of 2 seconds per byte.  Depending on the application, one might
> be waiting ~2 minutes to get keying material, which often imposes design
> constraints.  Naturally, if one doesn't need high quality random, don't
> use an low entropy blocking source.    /dev/urandom returns requested
> material almost immediately.  For purposes of TLS
> session-ticket-encryption-key generation (which is the context the question
> came up), one *absolutely* must know their PRNG is properly seeded.  A
> 128-bit cipher operating at 128-bit cipher strength requires a key that had
> 2^128 different possibilities.  If one doesn't pay attention to the entropy
> level seeding their PRNG, one has no idea.
> Check the OS that the code is running on.  On linux a 'man 4 random', is
> quite explicit in that long-lived GPG/SSL/SSH keys should *not* use
> /dev/urandom. Different OS may have different constraints.
> ---
> Further excerpts from the linux 'man 4 random':
> "When read, the /dev/random device will only return  random  bytes  within
> the  estimated  number of bits of noise in the entropy pool.  /dev/random
> should be suitable for uses that need very high quality  randomness  such
> as one-time pad or key generation.  When the entropy pool is empty, reads
> from /dev/random will block until additional environmental noise is
> gathered.
> A  read  from  the  /dev/urandom  device  will not block waiting for more
> entropy.  As a result, if there is not sufficient entropy in the  entropy
> pool, the returned values are theoretically vulnerable to a cryptographic
> attack on the algorithms used by the driver.  Knowledge of how to do this
> is not available in the current non-classified literature, but it is
> theoretically possible that such an attack may exist.  If this is a  concern
> in your application, use /dev/random instead."
> ---
> Dave Thompson

View raw message