-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
