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]<mailto:[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]<mailto:[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
