On Fri, Mar 28, 2014 at 08:00:06PM +0100, Dr. Stephen Henson wrote:
> > Therefore, implementations can over time move to encrypt session
> > tickets with 256-bit keys. So I would not exclude session tickets
> > at any of the security levels, this adds no security, but makes
> > the use of security less likely (more expensive handshakes, more
> > server hardware, ...).
> >
>
> Some applications generate a long term key which is then shared among
> multiple servers. That defeats PFS if an atatcker could just steal that
> key and then decrypt any session tickets protected with it.
Implementations can have all kinds of security flaws, and in features
other than session tickets.
> If an application implements key rollover and uses 256 bit AES keys then
> there are no issues with using tickets at any security level. Unfortunately
> not many applications do AFAIK.
Postfix rotates session ticket keys. It currently uses AES-128
for the bulk encryption, but this is easy to change. I could easily
make it configurable. (Will as soon as I get a chance).
By the way, RFC 5077 specifies a 256-bit HMAC key for session
tickets, but OpenSSL seems to by default use as 128-bit HMAC key.
Is this deliberate?
ssl/s3_lib.c:
if (cmd == SSL_CTRL_SET_TLSEXT_TICKET_KEYS)
{
memcpy(ctx->tlsext_tick_key_name, keys, 16);
memcpy(ctx->tlsext_tick_hmac_key, keys + 16, 16);
memcpy(ctx->tlsext_tick_aes_key, keys + 32, 16);
}
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
