trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Thompson <da...@oath.com>
Subject Re: Secure usage of /dev/random vs /dev/urandom
Date Wed, 08 Nov 2017 16:34:44 GMT
So, TLDR; form of this thread on /dev/random vs /dev/urandom

/dev/random - Use when entropy tracking matters, e.g. sensitive security
needs.  Performance-wise can be very expensive, to the point of
constraining how it's used.

/dev/urandom - When performance is the priority.  Not for use with long
lived security keys.

STEK (Session Ticket Encryption Key) - it's among one of the most sensitive
tidbits on a TLS server, with regards to transaction privacy.  It should be
rotated regularly. Out-of-the-box ATS only generates new at startup, though
provides multiple hooks for site-specific rotation handlers.

Caveat, above is linux specific, details may vary with OS.

Dave

On Wed, Nov 8, 2017 at 8:52 AM, Mischa Lehmann <
Mischa.Lehmann@clearswift.com> wrote:

> 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> 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> 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