En l'instant précis du 01/17/07 17:00, Peter Crowther s'exprimait dans toute sa noblesse: >> From: David Delbecq [mailto:[EMAIL PROTECTED] >> Those are generated by taking the first 16 characters of >> the md5 sum of a random byte[16]. >> > > Interesting. Note that although the existing code makes considerable > effort to ensure this *is* random, a number of factors can apparently > decrease the randomness: > > - Running on Windows, which removes the ability to use /dev/urandom; > > - Running without APR, which reduces the set of values that getEntropy() > can return to the set of valid addresses of Java objects on the Tomcat > heap at the time (more of an issue with a small webapp); > > - Best-practise time synchronisation between servers plus running on > operating systems with relatively large millisecond clock granularity > (like Windows on x86, which I think still has a 20ms granularity), which > can result in the major entropy source (the millisecond clock) being > closely synchronised between the servers; > > - Restarting the containers and then opening for business via a load > balancer, which may result in the first requests coming in to multiple > servers at very similar times - particularly a problem if the clocks are > closely synchronised, as it drastically increases the chance of the same > millisecond clock value on multiple servers. > Yes, it's not impossible that 2 tomcat instance infortunately starts with the same seed when servers are synchronized and your os has big granularity.. I didn't go fully in the insides of random generation, and particulary the seed part.
I found the analysis of this article (http://research.microsoft.com/~dalia/pubs/GM05.pdf) a good argument for switching to somewhere where exists a urandom :) > If you ever happen to get the same seed between two servers, you're > seriously hosed - I *think* the way the code works, those systems will > generate and continue to generate duplicate session IDs until one is > restarted. > > I don't know how much of an effect these factors have in reality, but I > think I'd prefer to run on some OS other than Windows and/or enable APR > if I were planning to rely on the session IDs. This is based on a > relatively superficial analysis of the code; it may be that there are > built-in defences against the problems described above that I've not > found! > > - Peter > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
