Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of paul@querna.org designates
 209.85.216.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.1110011837500.5312@eru.sfritsch.de>
References: 
 <CAMDeyhxLdBGfrxwV9THC=wZ5REyMjh1y0_8FhBtTCU9go_+0Bw@mail.gmail.com>
	<4E8571E6.7070102@kippdata.de>
	<CAMDeyhxM0vuBLEqSpaPqCEcsXXzfYK8a695ggpsDO-J+DnPJ3g@mail.gmail.com>
	<4E85D549.7080802@kippdata.de>
	<alpine.DEB.2.00.1110011837500.5312@eru.sfritsch.de>
Date: Sat, 1 Oct 2011 16:35:33 -0700
Message-ID: 
 <CAMDeyhx6ybYXzahS2GGOF3L0wqyK7++=8AfKpXaRizmtfOWpcg@mail.gmail.com>
Subject: Re: [PATCH] Support for TLS Session Tickets
From: Paul Querna <paul@querna.org>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 1, 2011 at 9:48 AM, Stefan Fritsch <sf@sfritsch.de> wrote:
> On Fri, 30 Sep 2011, Rainer Jung wrote:
>>
>> Thanks for the info. That would definitely be a nice feature. Would it
>> be safe to use a statically defined key? Only as long as the config file
>> is safe?
>
> As I understand it, knowledge of the session ticket key allows to
> decrypt all connections that use session tickets with this key. I
> think this is true even if the tls cipher itself guarantees forward
> security (like DHE). If this is correct, the option certainly needs
> some warnings in the documentation.
>
> Also, I think the config file is the wrong place for the key. Just think of
> mod_info, which would display the key in the configuration. And I am also
> against generating the key from some ASCII password that likely has less
> entropy than the 48 bytes used for the key.
>
> What about specifying a file that contains the base64 encoded key? If
> the file does not exist, httpd could create it with a random value and
> the correct permissions. The admin would then just need to start httpd on
> one server and copy the created file to the other servers.
>
> Or we could just document how to create it. Under Unix, it's a one-
> liner:
>
> (umask 077; dd if=/dev/random bs=48 count=1|
> openssl base64 > filename.key)

How about using the private key for the certificate as a signing key
as one way to get more (deterministic) data?