s2n-quic icon indicating copy to clipboard operation
s2n-quic copied to clipboard

Please provide a stable API for reconfiguring TLS without killing a server or client

Open bdonlan opened this issue 3 years ago • 2 comments

Problem:

Currently, a certificate rotation requires creating a new quic Server or Client, as the TLS provider is passed only during the server or client builder and cannot be accessed subsequently. This would potentially terminate ongoing connections to the quic Server (or client), which may not be desired.

Solution:

Providing a proxy TLS Endpoint implementation as a public API which allows the backend to be swapped out would be one solution. Alternately, this could be implemented by users easily enough if the Endpoint trait was stabilized. One thing to note here, however, is that currently the TLS Endpoint trait is not object-safe. This means that a proxy which would support switching to an entirely different TLS implementation cannot easily be implemented.

Requirements / Acceptance Criteria:

An API is provided that allows the TLS configuration for a s2n_quic::Server or s2n_quic::Client to be reconfigured, including changing trust roots and/or presented certificates.

Out of scope:

For our purposes, it is not required that the API allow switching to an entirely different TLS Endpoint implementation type - although we wouldn't mind it if that were the case.

bdonlan avatar Jul 15 '22 16:07 bdonlan

~~I have a PR prepared for this but need to wait for https://github.com/aws/s2n-quic/pull/1399 to land first.~~ Nevermind, problem wasn't as simple as I was expecting and I don't think I'll quite have time to finish this.

bdonlan avatar Jul 15 '22 23:07 bdonlan

This should be supported on the server by implementing the client hello callback. In that callback, you would associate whatever Config object with each connection as it comes in. On the client, we'll probably need another mechanism.

camshaft avatar Jul 19 '22 15:07 camshaft