Return-Path: 
 <tomcat-dev-return-27498-apmail-jakarta-tomcat-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org
Received: (qmail 95240 invoked by uid 500); 13 Sep 2001 05:04:59 -0000
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:tomcat-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:tomcat-dev@jakarta.apache.org>
Reply-To: tomcat-dev@jakarta.apache.org
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 95228 invoked from network); 13 Sep 2001 05:04:58 -0000
Message-ID: <00b601c13c12$2699b510$82deb018@intalio.com>
From: "Remy Maucherat" <remm@apache.org>
To: <tomcat-dev@jakarta.apache.org>
References: <20010912195457.B87959-100000@localhost>
Subject: Re: [Tomcat 4] Initializing PRNGs for Session Identifiers
Date: Wed, 12 Sep 2001 22:08:37 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> BACKGROUND:

> * 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)

I think the current mechanism is good enough. With a carefully chosen
secret, I don't see how that could be cracked, and if it turns out it's
actually doable, it must be a lot easier to try to find another way in.

Also, maybe we can find a way to slightly improve the randomness of the
seed.

> (1C) Plug-in seeding API to allow use of platform-specific algorithms
>      if desired

The plugin mechanism looks like a very good idea, and we should implement it
in the next maintenance release of Tomcat 4.

> 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.

The security level provided by 2B seems enough in 99% of the cases, so I
would leave it as the default.

> 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.

We probably will have to start a modules repository to put that kind of
additional features.

Remy