tls: api to change tls ticket keys

[silverwind]

As discussed briefly in #1462. Here's the relevant section from rfc5077:

   o  The keys should be changed regularly.

   o  The keys should be changed if the ticket format or cryptographic
      protection algorithms change.

For the first point, we need an api (a function?) to change the ticket keys. For the second part, I'm not sure, can these conditions happen?

[silverwind]

cc: @indutny

[silverwind]

Also related: The docs don't state how long the default sessionTimeout is, if there's any (I hope so).

[silverwind]

Another docs issue: What if ticketKeys isn't provided, will the keys be auto-generated in that case?

[indutny]

Yep, they will be auto-generated.

[silverwind]

One thing to keep in mind is that changing the ticket key will invalidate all tickets offered before this point in time. I think the ticketKeys API would need to be extended to take an array of past and present keys to be able to decrypt old but valid tickets.

[indutny]

@silverwind I doubt OpenSSL will allow it. Actually, it is considered a normal behaviour. Old tickets are invalidated, the clients will have new tickets once they'll connect to the server.

[silverwind]

Well, I'm not sure yet how, but Cloudflare seems to be able to match a ticket to the corresponding key:

https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/#sessionticketresumption

Also we set the session ticket lifetime hint to be 18 hours, the same value for SSL session timeout. Each server also keeps ticket keys for the past 18 hours for ticket decryption.

[indutny]

cc @grittygrease: some trade secret? ;)

[silverwind]

I think you might be able to store a timestamp and a hash of each encrypted ticket. With that you could map to the corresponding old key and decrypt the ticket with that. I think such functionality would be best left to user modules, but we should give them this option.

[grittygrease]

@indutny We do it in Lua with https://github.com/openresty, it has not been open sourced at this point in time.

[silverwind]

Actually, it is considered a normal behaviour. Old tickets are invalidated, the clients will have new tickets once they'll connect to the server.

That kind of defeats the purpose of tickets in the case where you rotate keys faster than the lifetime of tickets. I still have to check out tickets in Wireshark if they contain any hints to which key was used to encrypt them, but doubt there is any.