[PATCH] Follow OpenSSL's switch from AES128 to AES256 for session tickets
piotrsikora at google.com
Sun Nov 6 11:19:36 UTC 2016
> 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.
...and while we're breaking backward-compatibility, we should also
change the order in which values are read from files to match what
OpenSSL, BoringSSL & Apache are doing, i.e. key name, HMAC key, AES
ngx_memcpy(key->name, buf, 16);
ngx_memcpy(key->hmac_key, buf + 16, 32);
ngx_memcpy(key->aes_key, buf + 48, 32);
instead of the current: key name, AES key, HMAC key, which I
introduced by mistake and which has been annoying me ever since.
More information about the nginx-devel