On 9/22/2014 2:38 PM, Maxim Dounin wrote:
Hello!
On Mon, Sep 22, 2014 at 01:39:43PM +0200, Richard Fussenegger, BSc wrote:
I'd like to implement built-in session ticket rotation. I know that it this
was discussed before but it was never implemented. Right now a custom
external ticket key system is supported. Admins with single installations
and not enough knowledge about the topic are left with keys that are valid
for the complete lifetime nginx is running.
That's not really true: ticket keys are regenerated on each
configuration reload.
Exactly but nginx isn't able to decrypt older ticket keys and admins
might not be aware of this and will never implement the required cron job.
I thought about a rotation scheme that introduces a single new configuration
variable (e.g. ssl_session_ticket_key_rotation or
ssl_session_ticket_key_interval) that defines the interval in which the
ticket key should be rotated. I think a default setting of 24 hours would be
enough for most installations. One key is always used for decryption and
encryption and the most recently expired key is only used for decryption.
This means that we have a de- and encrypt key for 24 hours and a decrypt key
for 48 hours with the default setting. The best place for this would be in
ngx_event_openssl.c#2640 after the if (paths == NULL) by checking if the
aforementioned variable is set (default) and if the currently used key has
expired. If it hasn't return NGX_OK (as it is now) otherwise copy current
key to old key and generate new key.
Checking expiration in the ngx_ssl_session_ticket_keys() function
doesn't make sense: creating new SSL context means new random
keys. So if the ngx_ssl_session_ticket_keys() is called, which
only happens while reading a configuration, we currently have
a new key anyway.
Thanks for the insight on this, I'll investigate the source further
unless you have an idea (or pointer for me) where it should go.
Unsolved questions:
Implementation: Currently OpenSSL is generating and keeping track of the key
(this would still be the case if the newly introduced setting is set to
"0"). We'd have to introduce two variables - one for the current and one for
the old key plus timestamps - and let OpenSSL know about the key before
attempting to decrypt sent session data.
The main problem here is how to share keys between worker
processes, to ensure different workers will be able to decrypt
tickets. So automatic rotation of ticket keys will likely require
shared SSL session cache to be configured as well, and using a SSL
session cache to store ticket keys.
Having the session cache as a requirement for ticket rotation isn't a
problem for HTTP context. Not all major browsers support tickets and a
configuration that relies only on tickets doesn't make sense. Of course
it's a problem for the default configuration which is using tickets only.
Per server keys: CVE-2014-3616 from Antoine Delignat-Lavaud was dealing with
this. I have to review his patches but I guess that the variables have to be
arrays and we'd have to keep different current and old keys per server. But
what if one wants to share the sessions among servers? I guess this has to
depend on the location the configuration was set. As I said, I have to
review his patches to gather more knowledge for this problem.
As of now, session tickets can't be decrypted in other server{}
blocks (unless ssl_session_ticket_key is explicitly used to set
keys). I don't see any reasons to change this behaviour.
Me neither and it's great if it's already working this way.
Restarts: Apache is storing the key to file, that would allow the process to
read the last used keys. But of course this isn't very secure and we may
need an additional setting to define the path where these intermediate keys
should be stored. Of course we could also simply ignore restarts, as it is
now. But we'd loose the ability to decrypt old sessions tickets.
Current behaviour is believed to be good enough.
I think so too, losing the ability to decrypt old tickets isn't a big
deal but storing keys to files would be in my book.
Richard
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
