trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mischa Lehmann <Mischa.Lehm...@Clearswift.com>
Subject RE: Secure usage of /dev/random vs /dev/urandom
Date Wed, 08 Nov 2017 14:52:33 GMT
Dave, thanks for clarification.

I raised this issue during the conference because I falsely thought that we’re generating
information in the tickets based on /dev/random. Which is obviously a bad idea.
Using /dev/random for the STEK seems to be safe if we can guarantee that traffic through ATS
won’t trigger rotation.
Mischa

From: Dave Thompson [mailto:davet@oath.com]
Sent: 01 November 2017 21:22
To: users@trafficserver.apache.org
Subject: Re: Secure usage of /dev/random vs /dev/urandom

Eric,

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 ATS).

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) <efriedri@cisco.com<mailto:efriedri@cisco.com>>
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 <davet@oath.com<mailto:davet@oath.com>>
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


________________________________
Message Processed by the Clearswift R&D Dogfood Secure Email Gateway v4.7.0

This e-mail and any files transmitted with it are strictly confidential, may be privileged
and are intended only for use by the addressee unless otherwise indicated.  If you are not
the intended recipient any use, dissemination, printing or copying is strictly prohibited
and may be unlawful.  If you have received this e-mail in error, please delete it immediately
and contact the sender as soon as possible.  Clearswift cannot be held liable for delays in
receipt of an email or any errors in its content. Clearswift accepts no responsibility once
an e-mail and any attachments leave us. Unless expressly stated, opinions in this message
are those of the individual sender and not of Clearswift.

This email message has been inspected by Clearswift for inappropriate content and security
threats. 

To find out more about Clearswift’s solutions please visit www.clearswift.com

Mime
View raw message