tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@binarix.com>
Subject Re: [Tomcat 4] Initializing PRNGs for Session Identifiers
Date Thu, 13 Sep 2001 05:27:42 GMT
"Craig R. McClanahan" wrote:
> 
> Christopher Cain has raised some concerns (both in private email and
> publicly on this list) regarding the initialization of pseudo random
> number generators (PRNGs) used to calculate session id values.  We need to
> have a quick discussion about this, to determine whether we want to change
> the current approach.  The purpose of this particular mail thread is to
> decide what to do for Tomcat 4 -- developers on the other versions are
> welcome to chip in and describe what they do, and what their preferences
> might be as well.
> 
> BACKGROUND:
> 
> Tomcat 4 uses an instance of java.security.SecureRandom to generate
> session identifiers for a particular session.  The instance is initialized
> the first time (after Tomcat is started, or after a webapp is restarted)
> that a session identifier is requested.  The issue at hand for this
> discussion is the mechanism used to seed the random number generator
> instance.  (If the seed is predicatable, then the entire sequence of
> session ids that will be generated is also predictable, which is a nasty
> security risk.)
> 
> The default seeding algorithm (i.e. if you do not seed it yourself)
> gathers system entropy information based on current system activity.  The
> good news is that this tends to create a very random starting value.  The
> bad news is that it can take many seconds to calculate, with noticeable
> impact on the response time for the first session-related request.
> 
> To ameliorate this, Tomcat 4 seeds the random number generator based on a
> combination of:
> 
> * The current timestamp (in milliseconds) when the first request for
>   a session id for this web app occurs
> 
> * An optional entropy-increasing string value that you can specify
>   in your "conf/server.xml" file, like this:
> 
>     <Context ...>
>         ...
>         <Manager entropy="My Private Entropy String"/>
>         ...
>     </Context>
> 
>   If no entropy property is specified, a default (and therefore
>   predictable) entropy string is used.
> 
> This approach has the advantage of seeding much more quickly, but the
> disadvantage that the sequence of session ids is potentially predicatable.
> Predicatability is *much* easier if an attacker can manage to read
> "conf/server.xml" (although, as I've pointed out to Christopher, security
> of your session ids is the *least* of your problems if this happens).  The
> current approach is also the one that was recommended the last time this
> issue was raised (when Tomcat 3.1 had a *very* weak approach to
> calculating session ids).
> 
> The decision we face, of course, is whether or not to change this.  A
> complicating factor is that some platforms offer facilities (such as
> /dev/random) to take advantage of entropy gathered by the OS -- but such
> things are obviously not portable, so they cannot be relied on to satisfy
> all requiremnts.
> 
> It seems to me we have a number of overlapping decisions.  My thoughts are
> after each decision area -- I'm looking for input from others.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Craig McClanahan

Some of that stuff has been implemented in Tomcat 3.3 (3.x?). The file
SessionIdGenerator.java should be able to explain how TC 3.3 handles
those issues.

>From memory, there was a discussion about using /dev/urandom on this
list in relation to Tomcat 3.x (search for '/dev/urandom' and/or
'SessionIdGenerator' on this list) and also the differences of it as
compared to /dev/random. Doug Barnes nicely explained a lot of that
stuff. This can also be helpful.

In practice, having /dev/urandom helping with session ID's is essential.
It speeds up Tomcat significantly.

Also, if you inspect the above mentioned code, you'll notice that if
platform specific instrumentation is not available, Tomcat 3.3 will
default to the same thing in Java world, which is
java.security.SecureRandom.

Bojan

Mime
View raw message