Session Ticket Rotation

Richard Fussenegger, BSc richard at fussenegger.info
Mon Sep 22 12:26:24 UTC 2014


We already have the file based ticket keys. They require an external 
rotation, but I think that this requirement is okay for admins that 
already have to think of an exchange between several instances.

Richard

On 9/22/2014 2:23 PM, kyprizel wrote:
> What about sharing keys b/w the physical instances?
>
> On Mon, Sep 22, 2014 at 3:39 PM, Richard Fussenegger, BSc 
> <richard at fussenegger.info <mailto:richard at fussenegger.info>> 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.
>
>     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.
>
>     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.
>
>     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.
>
>     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.
>
>     Any thoughts from your side are highly appreciated.
>
>     Richard
>
>     _______________________________________________
>     nginx-devel mailing list
>     nginx-devel at nginx.org <mailto:nginx-devel at nginx.org>
>     http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140922/50e68193/attachment.html>


More information about the nginx-devel mailing list