Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 8D0D0200D33 for ; Wed, 8 Nov 2017 17:35:00 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 8B561160BDA; Wed, 8 Nov 2017 16:35:00 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 2B4871609E0 for ; Wed, 8 Nov 2017 17:34:59 +0100 (CET) Received: (qmail 23944 invoked by uid 500); 8 Nov 2017 16:34:58 -0000 Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@trafficserver.apache.org Delivered-To: mailing list users@trafficserver.apache.org Received: (qmail 23934 invoked by uid 99); 8 Nov 2017 16:34:58 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Nov 2017 16:34:58 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 4A81C1A234A for ; Wed, 8 Nov 2017 16:34:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=oath.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id aBGmPH3LlDiZ for ; Wed, 8 Nov 2017 16:34:53 +0000 (UTC) Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 8BB9860F8C for ; Wed, 8 Nov 2017 16:34:52 +0000 (UTC) Received: by mail-pf0-f181.google.com with SMTP id z80so2040389pff.4 for ; Wed, 08 Nov 2017 08:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oath.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OxqkT1avnjVZNMCdA7uQUAUXQWIAIS+3XDV6QbyE/2I=; b=TJblKAMysLRRlv6BGZR0fWW2eiGLP8gmSbotM08GyF1eFX5bCoHSS8cQNpj14os4iB PZ0eseSNCxjzIPcBhIOJ7JtUv9s6Qlo+Ra8y+OvhGNqyKmkJNK2esx6bS/PZsq2oGlqF Sy1OqhQyiLjCftA27NlCdSSkJNV4LlexwI9fUdnjkVppJ6cDX2PL6O/0JuF9B3eS+vp6 eG5BGm8RgYOqrXC0ys009VZxuKIMU/yy5huFNtSEiYvcuMR6eS6LBzLzVPgYAbFd/Lq/ BiDnd3a1iAXrfXyrmtIf1Ft3DpCYHwJLnSf7085tmyznYnb/bcYP3WeEfO1GWUZ9rLl6 7spQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OxqkT1avnjVZNMCdA7uQUAUXQWIAIS+3XDV6QbyE/2I=; b=npwlhYbpVppbmLdnR/R4CEE1XyYYZgvrIG2sKUH6wWd93cvofNDc2gQlVhCVxzVi6y t80IwnkyPE7JffUR0+v+W2uMtOsZuqT9HgDgqr3vCyABRC1ab+qZTrUc1KEU7o1sc3lq g/+MQNr60tHG5Z+UszvCy0m3qWzsTx9l4NFpswBwC3HlIXuHO2bKw0ANDdFhENSRNsY2 fqOZGzyHV5D0RdhQkNoO1WOOiq89zPMllCprVSI1AhXuBkL5THC8NMp0SvnpTlQ+wYua gs8juv5NFT9L1fOxysQ443bgpDakJL59G6PWiF7IX5xQsOxn/uOZYCvaPvvWXCoKHEf8 1QMA== X-Gm-Message-State: AJaThX7fLVW15T8Zw/zrhjoUGdvW0j6GSK2e3DRMCr+5u9ssGLaCqnMx qsWH8z3ZJ5/ouDcLNYyb+tRAWpx6rpd7/Oo86jhoxsv1 X-Google-Smtp-Source: ABhQp+TpYu05msxnuGlPouDL9IHCQ2Wg0gVASBT2Rmxa+ZVMmVxaEzbu2+tyzolS7StX+n7nHojh7lw4do4AIiKgRko= X-Received: by 10.84.240.140 with SMTP id z12mr968880plk.328.1510158885122; Wed, 08 Nov 2017 08:34:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.183.171 with HTTP; Wed, 8 Nov 2017 08:34:44 -0800 (PST) In-Reply-To: References: <41F65922-5DE5-4864-A54B-503B5CBA8F39@cisco.com> From: Dave Thompson Date: Wed, 8 Nov 2017 10:34:44 -0600 Message-ID: Subject: Re: Secure usage of /dev/random vs /dev/urandom To: users@trafficserver.apache.org Content-Type: multipart/alternative; boundary="089e0820b430e74209055d7b43d1" archived-at: Wed, 08 Nov 2017 16:35:00 -0000 --089e0820b430e74209055d7b43d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99re 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=E2=80=99t 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 k= ey > 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 the= ir > 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=E2=80=99t at the summit, so am likel= y missing > some context. > > > > Doesn=E2=80=99t ATS rely on openssl to manage random number generation? > > > > =E2=80=94Eric > > > > > > 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 entro= py > 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 questi= on > 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 h= ad > 2^128 different possibilities. If one doesn't pay attention to the entro= py > 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 withi= n > 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 conc= ern > 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 canno= t > 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 a= re > 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=E2=80=99s solutions please visit > www.clearswift.com > --089e0820b430e74209055d7b43d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

So, TLDR; form of this threa= d on /dev/random vs /dev/urandom

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

/dev/urandom - When performance is the priority.=C2=A0 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 transac= tion privacy.=C2=A0 It s= hould be rotated regularly. Out-of-the-box ATS only generates new at startu= p, though provides multiple hooks for site-specific rotation handlers.
<= span class=3D"gmail-s1">

Caveat, above is linux specific, details may vary wit= h OS.

Dave

=

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

Dave, thanks for clarification.<= /span>

=C2=A0

I raised this issue during the conference beca= use I falsely thought that we=E2=80=99re generating information in the tick= ets based on /dev/random. Which is obviously a bad idea.

Using /dev/random for the STEK seems to be saf= e if we can guarantee that traffic through ATS won=E2=80=99t trigger rotati= on.

Mischa

=C2=A0

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

=C2=A0

Eric,

=C2=A0

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

=C2=A0

STEK is the key that a TLS server will use to encryp= t/decrypt all TLS session tickets.=C2=A0 It is among one of the most sensit= ive tidbits on the server, as with it, one can decrypt all client session t= ickets (which contain the individual session keys that encrypt/decrypt bulk data), for all clients resumption to a TLS = cluster that shares the STEK.=C2=A0 =C2=A0Common practice is to generate/ro= tate STEK every <24 hour period.=C2=A0 =C2=A0

=C2=A0

The actual coordination of STEK rotation and generat= ion is outside the scope of ATS, with the details likely deployment environ= ment constrained.=C2=A0 ATS has more than one mechanism for external proces= ses to set this.=C2=A0 =C2=A0By default ATS will generate a STEK each time it is started, though for a multi-node ATS clust= er, this is not functional as each node would have different STEKs (resumpt= ions would typically fail ), nor is it secure (e.g. lack of rotation).=C2= =A0 =C2=A0As such I would speculate (hope) most would roll their own handler.

=C2=A0

Dave Thompson

=C2=A0

=C2=A0

On Tue, Oct 31, 2017 at 10:50 AM, Eric Friedrich (ef= riedri) <efriedr= i@cisco.com> wrote:

Dave-

=C2=A0 Thanks for the explanation. I wasn=E2=80=99t = at the summit, so am likely missing some context.=C2=A0

=C2=A0

Doesn=E2=80=99t ATS rely on openssl to manage random= number generation?

=C2=A0

=E2=80=94Eric

=C2=A0

=C2=A0

On Oct 30, 2017, at 6:21 PM, Dave Thompson <davet@oath.com> wrote= :

=C2=A0

At the ATS summit la= st week, there was some confusion regarding appropriate use of /dev/random = vs /dev/urandom .=C2=A0 De= pending on the usage, exploits associated with getting this wrong can be se= vere.=C2=A0 I&= #39;ll sleep better, not letting this drop before attempting to explain whi= ch is an appropriate source. ;-)

From a linux= perspective, the difference between these two sources of random data is th= at one is an entropy tracking source (/dev/random) which will block reads w= hile the entropy pool is low, versus /dev/urandom which will always return a timely response regardless of the state of the entrop= y pool. When random numbers come from a deterministic pseudo-random number = generator algorithm, the only real thing that is actually random is that wh= ich is collected in the entropy pool.

The linux en= tropy tracked source does come at a cost. =C2=A0 I have measured upwards of 2 seconds per byte.=C2=A0 Depending on the application, one might be waiting ~2 minutes to get= keying material, which often imposes design constraints.=C2=A0 Naturally, if one doesn't need high quality random, don't us= e an low entropy blocking source.=C2=A0=C2=A0=C2=A0 /dev/urandom returns requested material almost immediately.=C2=A0 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.=C2=A0 A 128-bit cipher operating at 128-bit cipher str= ength requires a key that had 2^128 different possibilities.=C2=A0 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.=C2=A0 On linux a 'man 4 random', is quite explicit in that long-li= ved GPG/SSL/SSH keys should *not* use /dev/urandom. Different OS may have d= ifferent constraints.=C2=A0

---

Further exce= rpts from the linux 'man 4 random':

"When read, the= /dev/random device will only return=C2=A0 ra= ndom=C2=A0 by= tes=C2=A0 wi= thin the=C2=A0 es= timated=C2=A0 nu= mber of bits of noise in the entropy pool.=C2=A0 /d= ev/random should be suitable for uses that need very high quality=C2=A0 ra= ndomness=C2=A0 su= ch as one-time pad or key generation.=C2=A0 Wh= en the entropy pool is empty, reads from /dev/random will block until addit= ional environmental noise is gathered.

A= =C2=A0 re= ad=C2=A0 fr= om=C2=A0 th= e=C2=A0 /d= ev/urandom=C2=A0 de= vice=C2=A0 wi= ll not block waiting for more entropy.=C2=A0 As= a result, if there is not sufficient entropy in the=C2=A0 en= tropy pool, the returned values are theoretically vulnerable to a cryptogra= phic attack on the algorithms used by the driver.=C2=A0 Kn= owledge of how to do this is not available in the current non-classified li= terature, but it is theoretically possible that such an attack may exist.=C2=A0 If= this is a=C2=A0 co= ncern in your application, use /dev/random instead."<= /u>

=C2=A0

---=

Dave Thompson=

=C2=A0

=C2=A0

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 ot= herwise indicated.=C2=A0 If you are not the intended recipient any use, dis= semination, printing or copying is strictly prohibited and may be unlawful.= =C2=A0 If you have received this e-mail in error, please delete it immediat= ely and contact the sender as soon as possible.=C2=A0 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 le= ave 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=E2=80=99s solutions please visit www.clearswift.com<= br>


--089e0820b430e74209055d7b43d1--