Add support for SSL/TLS session tickets

[Haw Loeung]

Hi,

To reduce CPU usage in SSL/TLS session handshaking, let's enable use of session tickets. This will allow us to increase the number of requests we can handle. See:

| https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-tls-ticket-keys

One idea is to expose the ticket key as a charm config variable so it can be easily rotated out semi-frequently and also will remain consistent across the units (and preferably
not persisting to disk).

[Haw Loeung (hloeung)]

Per Joel's comment in MP:380460:

"""
Also, as discussed, it would be preferable to use session tickets which removes the need for state to be stored on the servers and allows session resumption across all frontends if they share keys. The challenge is ensuring frequent rotation and preferably not persisting ticket keys to disk.
"""

[Junien F (axino)]

I disagree that using a charm config variable for this is a good idea. You shouldn't need to update a juju config every 12h or something to have security.

How in sync must the ticket files be ? Even with a config option, if another hook is running on one unit, it will take more time on that unit and the files could be out of sync for seconds, if not minutes.

[Haw Loeung (hloeung)]

12h - 24h or there abouts to ensure PFS.

Reading through the HAProxy docs last night, it seems it's a collection of keys, so we just keep appending to that keyfile with the last few used). Reading elsewhere, we drop the key in place say every 5 mins the job runs to check and update, then after a certain period of time, say 20-30 mins (so key file age), issue the HAProxy reload to make it live. This would then ensure they're all rotated at the same time.

They don't *need* to be in sync. If I read correctly, tickets are already enabled by default with HAProxy (OpenSSL default), but if tickets don't match then the TLS/SSL session is renegotiated (full handshaking).

The thing is, in our set up, we have different content-cache units deployed as different applications based on DC so we can't use juju relations to have it synchronise key generation and rotation. Instead, a juju charm config to drop the updated ticket in place, and a juju action to actually reload HAProxy. Or another idea is an agent or subordinate that talks to a central place for the ticket keys file.

[Junien F (axino)]

We can still use juju relations, just need to update the charm. We could also have a common subordinate, and the ticket keys would be part of its application databag.

We do want to confirm that everything would still work should the juju controllers go away for a few days.