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 < [email protected]> 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:[email protected]] > *Sent:* 01 November 2017 21:22 > *To:* [email protected] > *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) < > [email protected]> 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 <[email protected]> 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 >
