Bug 61072 - SessionIdGeneratorBase will not use platform default SecureRandom algorithm for empty secureRandomAlgorithm attribute
Summary: SessionIdGeneratorBase will not use platform default SecureRandom algorithm f...
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 9.0.0.M20
Hardware: All All
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2017-05-05 05:29 UTC by Simon Björner
Modified: 2017-05-05 15:30 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Simon Björner 2017-05-05 05:29:03 UTC
Setting secureRandomAlgorithm to an empty string and not specifying secureRandomProvider still seems to lead to SessionIdGeneratorBase creating its SecureRandom instance using SecureRandom.getInstance("SHA1PRNG"), which is contrary to the wording in the documentation saying "To specify that the platform default should be used, do not set the secureRandomProvider attribute and set this attribute to the empty string.". See the implementation of SessionIdGeneratorBase.createSecureRandom(), where the "result = new SecureRandom()" line doesn't seem to be triggered for this case (secureRandomProvider=null, secureRandomAlgorithm="").

Getting the platform default SecureRandom algorithm is wanted on Linux systems where /dev/random blocks or is slow, either due to misconfiguration or exhaustion. See the latest comment on http://bugs.java.com/view_bug.do?bug_id=4705093 for a description of the current SecureRandom behavior. Regardless of that problem, and the motivation it provides for being able to easily get a default algorithm SecureRandom, I believe the former paragraph describes either a documentation or implementation bug in itself, so unless requested I don't think it's necessary to prove in this bug entry that Tomcat hangs on such a system. (Though it could be argued that platform default SecureRandom would be a better default to make Tomcat never block on /dev/random out-of-the-box.)
Comment 1 Remy Maucherat 2017-05-05 08:36:54 UTC
I agree it should do what the specification says. I made a change to only use the hardcoding if there is an error.
It will be in 9.0.0.M22, and it will be backported once the current release cycle is complete.
Comment 2 Remy Maucherat 2017-05-05 15:30:34 UTC
This should be fixed. 8.5.16, 8.0.44 and 7.0.78 will have the fix.