Hey, > 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 key: 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. Best regards, Piotr Sikora _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel