tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Cain <cc...@mhsoftware.com>
Subject Re: [Tomcat 4] Initializing PRNGs for Session Identifiers
Date Fri, 14 Sep 2001 23:55:18 GMT
Sorry for the late reply. I was offline for a few days. More below ...

Craig R. McClanahan wrote:

[snip]

 > DECISION 1 - WHAT SEEDING MECHANISMS SHOULD WE SUPPORT?
 >
 > (1A) Default seeding of java.security.SecureRandom (time consuming but
 >      reasonably secure)
 >
 > (1B) Current mechanism of timestamp + entropy string (very fast,
 >      potentially not secure)
 >
 > (1C) Plug-in seeding API to allow use of platform-specific algorithms
 >      if desired
 >
 > Currently, Tomcat 4 only supports (1B).  It certainly makes sense to 
offer
 > (1A) as well.  Offering (1C) is more work, but is not conceptually
 > difficult.

IMHO, and as Craig points out, offering 1A only makes sense. Allowing
for a "maximum security" configuration, given that the changes necessary
to make it an option are trivial, is a no-brainer.

I really dig 1C as well, and I'll help put it together. As Remy said, we
can pursue this once RC1 is out the door.

 > DECISION 2 - WHAT SEEDING MECHANISM SHOULD BE THE DEFAULT?
 >   (assumes, of course, that we support them both)
 >
 > (2A) Default seeding
 >
 > (2B) Current mechanism
 >
 > Currently, (2B) is supported, because only (1B) is supported.  This is
 > likely to be a much more involved discussion that Decision 1.  I could be
 > persuaded to (2A), but I'm not really certain that this is an issue 
in the
 > majority of Tomcat installations -- if we allow people who care about it
 > to choose (2A), but not make people suffer when they don't feel 
session id
 > predicatability is an issue, that seems like a reasonable approach.

I would argue that allowing it to self-seed at container startup time is
also not really an issue in the majority of installations (although I'm
sure I'll hear some disagreement on that one :-)  In production, how
often is the container restarted? And in development, if reloading is
working, how often then?

Since the mechanism for toggling between the slower self-seeding and the 
faster current mechanism will presumably be as easy as changing a value 
in server.xml, it would be simple enough to change it in a develop 
environment where you find yourself restarting often. My feeling is that 
  minor startup delays in a production system are usually unimportant, 
especially if you are trading up for ultra-security.

The current implementation seems reasonably secure, to be fair, but it 
is not a common approach that has been picked over by cryptoanalysts for 
years, whereas the system entropy routines are. The truth is, it is 
impossible to say with near certainty that the current approach is 
cryptographically secure, whereas I *can* make that statement about 
entropy. My opinion is to err on the side of caution, given how 
devasting a weakness in session IDs would be. As a general rule of 
thumb, I prefer to ship with the tightest possible configuration, then 
let users tweak for performance as necessary. If they don't even notice 
the delay, either because their hardware is killer or because they don't 
restart that much, then why even worry about? The ones that do notice 
will look in the docs, and in server.xml itself, and realize that they 
can change it to be faster. It just seems safer to default it to a 
proven approach for people who just want to run the install, fire it up, 
and let it run.

Finally, JDK1.4 is slated to have a *much* faster self-seeding 
mechanism, since the current one is gratuitously slow even for what it 
has to do. At some point in the near future, then, SecureRandom is going 
to get much faster. So why not just change the default before the 4.0 
product goes final, since that will be the obvious default when the JDK 
  gets faster?

 > DECISION 3 - WHAT PLUG-INS FOR (1C) SHOULD WE OFFER AS STANDARD?
 >
 > (3A) Unix systems /dev/random
 >
 > (3B) Unix systems /dev/urandom
 >
 > (3C) ???
 >
 > Currently, none of these are supported.

The Unix plug-ins would be quite easy to write. Windoze doesn't store 
any pre-cached system entropy (which is essentially what the 
random/urandom devices are), so until they do, there's really no way to 
speed things up on that platform.

Dunno about Mac. Since OSX is based on the Mach kernel, chances are that 
the OS stashes some entropy in a similar way to random devices, so a 
plug-in for that is probably quite doable. I have no earthly idea about 
the older Mac OSes =)

- Christopher

/**
   * Pleurez, pleurez, mes yeux, et fondez vous en eau!
   * La moitiƩ de ma vie a mis l'autre au tombeau.
   *    ---Corneille
   */



Mime
View raw message