Jon Brisbin (Migrated from SEC-1386) said:
I'm running tcServer in a cluster on top of VMware ESXi server. When I try and start tcServer (or plain Tomcat 6, for that matter) with a webapp that is Spring Security 3 enabled, it takes 5 minutes or more for the server to fully start. When I symlink /dev/random to /dev/urandom, it starts up normally.
I have /dev/urandom set as the source for my entropy in the system java.security settings. I've also passed -Djava.security.egd=file:/dev/urandom to tcServer per the thread: http://bugs.sun.com/view_bug.do;jsessionid=81ead47d172a98bb75bbdf7fc78?bug_id=4705093
I don't really know what else to try. Every time I reboot, any changes I make to /dev/random revert to the stock, blocking random generator. When I comment out Spring Security, everything start fine.
Luke Taylor said:
I don't really understand why do you think this is a major bug in Spring Security? There doesn't seem to be any evidence for that here.
Jon Brisbin said:
Since I'm running Spring Security inside a VM guest, it's either let the application servers take up to five minutes to start (times the number of nodes I have...this tends to be burdensome and affects my uptime) by letting Spring Security use /dev/random, or do what I've done for the workaround, which is to create an /etc/init.d script that symlinks /dev/random to /dev/urandom. That's a pretty rough workaround, but the only one that works reliably.
Spring Security uses SecureRandom in places (which I think uses the blocking /dev/random for entropy). As far as I have been able to test, this is what's causing a 3-5 minute delay in startup on Spring Security-enabled webapps on Linux VM guests. /dev/random's entropy pool does not get filled very quickly on a VM guest. If Spring Security was coded to use /dev/urandom exclusively, applications that use it would not suffer this startup delay.
If it's not desirable to use /dev/urandom exclusively, then it should at least be configurable so that applications that run on application servers inside VM guests don't have to block on their startup. Or provide some other method to get entropy than by using the blocking /dev/random.
I don't know if this is specific to Xen/VMware or if VirtualBox also suffers from this.
How SecureRandom is configured can vary between different platforms and VMs. Spring Security just uses the class in a standard way, so presumably you would see the same behaviour in any library or application which uses it. The source from which it is seeded should be selected in your java.security file. It's not something that Spring Security should be deciding.
I'm already using /dev/urandom in my java.security file:
But somehow Spring Security is using something that generates randomness (maybe it's plain java.util.Random?) that is using /dev/random instead of /dev/urandom.
One way or another, I think Spring Security should account for this long startup time. If the stance is to punt this issue, that's all well and good, but that doesn't help me any. People coming along behind us should be aware that this is an issue. It looks likes the code is not so replete with references to random generators that they can't be tweaked in just key spots to accommodate this behavior in cloud environments. I'm sure there's more than one way to use those standard objects to get the same result...and do it in a way that doesn't trigger this behavior. That's all I'm talking about.
If the Spring team disagrees and thinks those tweaks are a waste of time, then, as I said, so be it. But no where that I could find is this issue addressed.
Spring Security is just using SecureRandom.getInstance() in the codebase. That's presumably why you are seeing this behaviour. Have you tried just writing a simple app which does nothing other than this and see if you get the same behaviour? We don't use java.util.Random, and that uses a time-based seed, so shouldn't cause a problem.
You really need to work out why "/dev/random" is being used, when your configuration indicates that it shouldn't be.