tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject [Tomcat 4] Initializing PRNGs for Session Identifiers
Date Thu, 13 Sep 2001 03:20:28 GMT
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



Mime
View raw message