[maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

["André Warnier (tomcat)" <aw...@ice-sa.com>]

There seem to be a recrudescence of interventions on this list about SSL/HTTPS, and 
associated discussions about the usage of various randomness sources.
I found this article interesting :
https://www.2uo.de/myths-about-urandom/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

(This turned out to be quite long. I honestly think it's worth reading.)

On 10/27/17 5:32 PM, André Warnier (tomcat) wrote:
> There seem to be a recrudescence of interventions on this list
> about SSL/HTTPS, and associated discussions about the usage of
> various randomness sources. I found this article interesting : 
> https://www.2uo.de/myths-about-urandom/

Thanks for posting this. I have a couple of comments.

1. The author provides very few references.
2. The author seems to be arguing /strongly/ in favor of universal use
of /dev/urandom, except the the time he briefly concedes that
long-lived keys probably ought to use /dev/random

So basically, he has expanded random(4) into a semi-didactic rant
about why people use "common knowledge" instead of real information.

I mentioned in a recent thread that maybe using haveged[1] on a
virtual machine might not be a good idea. My argument against goes
something like this:

1. Users should always have a choice between /dev/random and /dev/urando
m.
2. If you choose to use /dev/random for whatever reason (e.g. to
generate long-lived TLS/PGP/SSH keys), then you are expecting to get
the kind of entropy and randomness that device is documented to provide.
3. Virtual machines pull the wool over the eyes of the guest OS in
such a way to make all kinds of "hardware" events less random than one
would expect from bare-metal.
4. This tool therefore has the high potential to make /dev/random
behave like /dev/urandom, therefore this tool removes choice from the
user, the OS, and everything else. A user drawing from /dev/random is
expecting one type of randomness and getting another, and it's
possible that the user has no idea it's happening.

I would never recommend to anyone that they switch all of their uses
of /dev/urandom to /dev/random (not vice-versa). But I definitely
would recommend against anything that switches the semantics of
/dev/random to anything other than what it already does.

It's worth mentioning that there has been a lot of confusion over the
years as to what Java uses for its seeds -- at least the Sun/Oracle
flavor. For a time, the source was /dev/random, then /dev/urandom,
then a time where both /dev/random and /dev/urandom were somewhat
transparently aliased to one another so that if you wanted to get the
REAL one you wanted, you had to specify things like /dev/./urandom (or
/dev/./random) because the JVM would decide it knew better than you
did about where you wanted your entropy to come from.

As of this moment, the $JAVA_HOME/jre/lib/security/java.security file
on an arbitrary server I have available to me has the following line
of configuration in it:

securerandom.source=file:/dev/random

There is nothing in the comments surrounding that setting that
suggests anything other than /dev/random will be used.

Have a look at [2] which has references to the history of the whole
thing and a (reasonably) current statement about what's being used in
modern JVMs. I'm glad I read the Oracle Java 8 security update (which
I hadn't read before) ... I never knew that there was a new
SecureRandom.getInstanceStrong method to get the "Strongest source of
randomness" available to the JVM. Sadly, you can't select the provider
and algorithm -- while that choice might actually be counter-productive.

Remember that entropy is only required when seeding a random-number
generator such as java.util.Random or java.security.SecureRandom. Once
the algorithm has been seeded, no additional entropy is necessary for
the lifetime of PRNGs. Certain algorithms may choose to mix-in some
entropy at intervals during their lifetime, but it's not strictly
necessary.

IMHO, when it comes to generating long-lived keys, use of Java is not
necessary because there are better tools available. I don't know of
anyone who uses Java to generate PGP or SSH keys, for example. keytool
obviously does RSA and it the "tool of choice" when it comes to
generating new server keys for TLS with Java-based servers. I tend not
to use Java for and server-side TLS -- I use non-Java-based
reverse-proxies for that purpose -- and so use of keytool is
irrelevant for me. When using keytool, I highly suspect that
SecureRandom.getInstanceStrong is in use so using Java for such
high-security keys does in fact seem reasonable.

But for online use? Using /dev/urandom is certainly acceptable.
Unfortunately, it looks like Java's Random/SecureRandom classes don't
allow the client code to choose the source of randomness. That means
starting-up Tomcat will require a bit of entropy to come from
/dev/random -- at least on Java 8 and later -- and that may lead to
long startup times while the (blocking) device satisfies itself -- and
client code.

This presents a conundrum for system administrators who must then
decide amongst the following options for how to deal with long startup
times:

1. Use something like haveged
2. Switch the JVM from /dev/random to /dev/urandom
3. Use a real hardware-based generator such as [3]
4. Continue to suffer with long startup times

Choosing #1 is great unless you are in a virtual environment.

Choosing #2 violates my desire to give choices to users. But, on Java,
there seem to be no choices once the JVM has launched. :(

Choosing #3 may be impossible (e.g. AWS/Azure/etc where hardware is
not accessible) or cost-prohibitive -- either for the hardware (which
is relatively cheap) or for the management of such hardware across
hundreds or thousands of physical servers.

#4 isn't really a choice.

I don't see any one-size-fits-all solution. This is a common theme in
computing: the solution that is best for one organization is not the
best one for another organization. Even with a single organization,
the decision may need to be made on a per-service or even per-server
basis.

But it's important that programmers, system administrators, and
managers understand the concepts and complexities of these kinds of
decisions, and use the information available to them to make a sound
decision rather than just Googling for "fix Tomcat slow startup" and
stick with the very first solution that solves the immediate problem.

- -chris

[1] http://www.issihosts.com/haveged/
[2] https://security.stackexchange.com/a/112044/89987
[3] http://www.entropykey.co.uk/
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln3MkwACgkQHPApP6U8
pFjnQA//Y+Shh2NIkf6rBe0rVsVTlloeqxmGb1P8uFkngAGnKS6ddiUU6sHHI9Ic
Y+8GljoNJwfS2+bAPJqzk9t6cpU5suDf5+WuzwLVlO/usu+qC0b3SzxArZ7TkXbC
shlOAK2J6lwt5UbQw1Le42PqD660cKLxlgOCdH4ZnaxQLL9WtrMdZhX+djKXz4EZ
VV5VA3vg5WI2tzXQDCFOUae2P9MpBhMrCPKQKTXS+7FTEM9O9SlRtmbfFKXnXLTF
uRD+9VlQQTOA2F+hweOm2wWptCBeFoAP63I5gQxBavRvKyE5x9KcwA6IKqLS0WUN
FJlWpFtENuvdDCo7b7HnaPUQ9vXXEwp8ARPcqIwO7il0OKGMP2Qwx+lqOaGp93Of
dBRtKlbz71itr/nwe/Up6goDUOtInpgLAeJQmrE8Mg7b6VigpWHOyKtobccAKJO8
tVVDB89V7MyXIwn9RZ9bLptxySTvBYtLSJP+1hMgqvkNE1YkM2ibl6qvOYPs/niJ
VOVhOpA9i+JnXlolTo8E+ejNfP7CzFbVovf2sJ09Io+Q5RXqN+IDZldW8KgU22Po
/kxN6NSx5DzGsYhvNEX2/ljRZE5bLssAqunLIS2tnoVFonbPDRhAwgxRPPfSk9cq
Rbw6YyTY+8JA+YhPvVdoJQicnhzM6egTqbY4OCZFF9WcCQCC7X8=
=yZcA
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

["André Warnier (tomcat)" <aw...@ice-sa.com>]

On 28.10.2017 00:54, Bob Hall wrote:
>   > On Friday, October 27, 2017, 2:32:50 PM PDT, André Warnier (tomcat) <aw...@ice-sa.com> wrote:
>   >  >  > There seem to be a recrudescence of interventions on this list about SSL/HTTPS, and
>> associated discussions about the usage of various randomness sources.> I found this article interesting :> https://www.2uo.de/myths-about-urandom/
>
> André, [OT] or not, thanks for adding a word to my vocabulary and for the article; recrudescence sounds better in French:
> Google Translate
>
>

Well, Merriam-Webster defines it as follows :

Definition of recrudescence
:a new outbreak after a period of abatement or inactivity :renewal

     a recrudescence of the symptoms

     a recrudescence of guerrilla warfare


.. which is pretty much what I meant.

It may be however that the fact that I deal with a lot of medical literature in my 
professional life, is somewhat colo(u)ring my English vocabulary.
  ;-)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

[Bob Hall <rf...@yahoo.com.INVALID>]

 > On Friday, October 27, 2017, 2:32:50 PM PDT, André Warnier (tomcat) <aw...@ice-sa.com> wrote:
 >  >  > There seem to be a recrudescence of interventions on this list about SSL/HTTPS, and 
> associated discussions about the usage of various randomness sources.> I found this article interesting :> https://www.2uo.de/myths-about-urandom/

André, [OT] or not, thanks for adding a word to my vocabulary and for the article; recrudescence sounds better in French:
Google Translate


| 
| 
|  | 
Google Translate

Google's free service instantly translates words, phrases, and web pages between English and over 100 other lang...
 |

 |

 |


- Bob