Caddy: TLS session secret management

[neilstuartcraig]

Hi

On my way in to work today, i was thinking about Caddy in terms of a HA service, wherein you'd probably have 3+ servers. It occurred to me that (AFAIK) we can't manage TLS sessions secret keys in Caddy and thus we can't (unless something like LB session affinity is used) use TLS session secrets in a multiple server configuration (because each server will have a different session secret and thus a session from one server won't work on another).

It'd be great to be able to supply (as part of the tls config) multiple session secret files (in preference order, i.e. Caddy would use the first for new sessions but accept others of existing sessions).

Does that make sense?

Cheers

[mholt]

Yep, it makes sense! Thanks for the suggestion. I'll add it to the list of things that could be implemented.

[neilstuartcraig]

Excellent. Thanks so much Matt. :-)

Sent from my iPhone

On 30 Jun 2017, at 15:56, Matt Holt [e-mail] wrote:

Yep, it makes sense! Thanks for the suggestion. I'll add it to the list of things we can implement.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[lbguilherme]

There are other things that would need cooperation regarding TLS here:

• Sharing obtained managed certificates (do not obtain a new certificate on each server, neither renew them multiple times)
• Sharing OSTP staples of those certificates
• Sharing the secret response for a successful HTTP challenge (ACME)
• Session secrets/tickets

Those are not an easy problem because it would probably require RAFT between the servers. Although good libs for that exist.

[neilstuartcraig]

@lbguilherme - Just to be sure i'm not causing confusion here :-)...i'm "only" asking for the facility to manually specify (multiple) TLS session secret key files, i'm not asking for Caddy to synchronise these between servers - that would be difficult to do well and in a way which would work for everyone (though people could conceivably use e.g. an AWS EFS volume mounted on all their servers). Hope that makes sense.

[wmark]

»TLS sessions secret keys« is unclear terminology and sounds like a mixture of

1. »secret key« (as in, the private part of a keypair or certificate–key pair),
2. »TLS session ID«,
3. and/or »TLS session ticket«.

(1) pertains to certificate management, (2) should be obsoleted and requires a rather large shared data structure, (3) is about securely exchanging a few bytes across machines and electing an authoritative (leader) node for the ticket rotation.

If (2) is botched or the data stolen, then a subset of all past connections can be retroactively decrypted. (3) pushes data to the client and thusly reduces impact. As (2) and (3) are used to resume TLS connections, where a LB's session stickyness would add value, I suspect you've meant one of those.

Distributed (3) does not need any new age algorithms. ;-)

[mholt]

@neilstuartcraig Mark makes some good clarifications that I now realize was confusing me at first. Could you specify which one of those you mean?

Is it similar to this? https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html and this: https://jacob.hoffman-andrews.com/README/how-to-check-for-tls-ticket-key-rotation/

[neilstuartcraig]

@mholt - yep sure. I am referring to item 2 in the list.

Yes, in https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html it's the bit which starts after the first big quote, para begins "The last obstacle to correctly implementing forward secrecy was our use of TLS session tickets"

And in https://jacob.hoffman-andrews.com/README/how-to-check-for-tls-ticket-key-rotation/ it is the focus of the whole article (i only scanned it quickly but it seems to be thew whole article).

FWIW, my main familiarity is on my current work project which is a distributed traffic management edge based on NGINX. We have an API controller service which can generate and securely deploy new session ticket secrets to groups of edge servers in order to rotate them. To make this workable, we make use of NGINX ability to use >1 session ticket secret in config so in rotating, we first move the current primary secret to be the secondary, then we add the new primary secret and -HUP NGINX to apply the change. This way, we can provide a new secret without a hard cut-off for clients which have the existing secret in use.

the NGINX directive is this one: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key

Does that help? Apologies for my not having described it more accurately in the first place.

[wmark]

@neilstuartcraig You're confusing (2) and (3) again. What you're describing is a standard (centralized) leader-follower two-phase TLS ticket rotation (→3). Remove the word session everywhere and it's not as confusing anymore what you want. ;-)

In a gist, your RFE is this, rephrased:

• Caddy currently manages TLS tickets in-memory.
• Add an optional directive to have them read and updated from a file
(on SIGUSR or any such signal, and/or if the file has been closed (→ inotify event)).
• Iff such a file were provided at start, then Caddy's own ticket rotation shall not be used.
• For the sake of completeness, disable the TLS session ID/session cache scheme for such cases. It won't reliably work; and if it did, then for a miniscule fraction of legacy devices at the expense of security all other' devices.

[neilstuartcraig]

Thanks for the rephrasing @wmark :-). I probably wasn't totally clear but IMO/AFAIK the names of 2 and 3 are not quite correct. For the sake of completeness/accuracy, what i am talking about is https://tools.ietf.org/html/rfc5077#section-5.5

I and the folk I work with refer to these as TLS session ticket secrets, the server-side secret which is used to encrypt the TLS session ticket. I am not referring to the older TLS sessions mechanism RFC4507 at all here, just to the newer tickets as described in RFC5077.

So i'd perhaps adjust the RFE you proposed to:

• Caddy currently manages TLS tickets in-memory.
• Add an optional directive to have them ticket master keys read and updated from a file
(on SIGUSR or any such signal, and/or if the file has been closed (→ inotify event)).
• If such a ticket master key file were provided at start, then Caddy's own ticket rotation shall not be used.
• For the sake of completeness, disable the TLS session ID/session cache scheme for such cases. It won't reliably work; and if it did, then for a miniscule fraction of legacy devices at the expense of security all other' devices.

I hope that is helpful. I'm aware i'm not directly contributing (in code, as i don't yet know much about Go) but am asking for features so please don't see my ideas as demands - i'm just suggesting what occurs to me whilst using Caddy from my PoV (which is both as a personal user of Caddy and also as someone who works at a large org).

Cheers

[mholt]

Thanks for clarifying. I've been giving this some thought since then. But with TLS 1.3, there won't be session tickets anymore. Filippo's recent blog post about flaws of session tickets explains that tickets which are rotated _and shared by multiple servers_ become higher profile, and more valuable, targets. I don't know if the complexity required for this feature is worth it once TLS 1.3 is implemented by Go.