[PATCH] Follow OpenSSL's switch from AES128 to AES256 for session tickets

[Piotr Sikora]

Hey Christian,

> # HG changeset patch
> # User Christian Klinger <c.klinger at lirum.at>
> # Date 1478383992 -3600
> # Node ID 5719a734584d23a6bcd22a3e59dd36138d06b803
> # Parent  92ad1c92bcf93310bf59447dd581cac37af87adb
> Follow OpenSSL's switch from AES128 to AES256 for session tickets
>
> OpenSSL switched from AES128 to AES256 for de-/encryption of session
> tickets in May 2016 (commit 05df5c2036f1244fe3df70de7d8079a5d86b999d),
> while we still used AES128, if `ssl_session_ticket_key` was set.
>
> Using AES128 for session tickets means that even when using an AES256
> cipher suite, the session's master key (and hence the whole
> connection) is effectively only protected by AES128, which silently
> weakens encryption.
>
> Hence, we follow OpenSSL's lead and switch from AES128 to AES256 for
> session tickets, if `ssl_session_ticket_key` is set.
>
> While the switch from AES128 to AES256 warrants reading additional
> 16 bytes from the key file, we nonetheless increase by 32 bytes,
> reading a total of 80 bytes instead of previously 48 bytes.
> The additional 16 bytes flow into the key for the SHA256 HMAC.
> Previously, the SHA256 HMAC only used a 16 byte key, and thereby used
> only half of SHA256 HMAC's 32 byte key space. We now provide a 32 byte
> key to the SHA256 HMAC and finally fully use the available key space.

While I agree that we should bump this to AES256 (or at least, make it
work with both), your change to use AES256 with keys that are
half-filled with zeros doesn't seem very appealing...

I suggest that "ssl_session_ticket_key" should either accept only 80
byte files (for use with AES256) or both: 48 byte files (for use with
AES128) & 80 byte files (for use with AES256).

Whether or not we want to support both is up to Maxim, but considering
that this is "advanced" feature, which users are expected to know how
to generate new keys, I'd recommend that NGINX should migrate to 80
byte files for use with AES256, without backward-compatibility for 48
byte keys.

Also, considering that recent versions of OpenSSL use AES256 by
default (i.e. when keys are not provided using
"ssl_session_ticket_key" directive), we shouldn't provide a way lower
the security of Session Tickets.

Best regards,
Piotr Sikora