Allow choose different crypto backend dynamically

[taikulawo]

Problem:

background
we have ssl_backend "s2n/rustls" directive to choose ssl crypto impl for different domain

{
    domain "a.com"
    http3 true
    ssl_backend "rustls"
    ssl_certificate ""
    ssl_certificate_key ""
}
{
    domain "b.com"
    http3 true
    ssl_backend "s2n-tls"
    ssl_certificate ""
    ssl_certificate_key ""
}

Current, s2n-quic support rustls/aws-lc-rs, but enable by feature

s2n-quic/quic/s2n-quic/src/provider/tls.rs

Line 24 in ac52a48

if #[cfg(feature = "provider-tls-default")] {

which means we can only choose use rustls or aws-lc as compile time.

Solution:

crypto backend should put in Config, to allow use different crypto backend by change Config.
Here are how quinn does. put crypto trait into Config, so we can choose backend by switch Config.

https://github.com/quinn-rs/quinn/blob/6bfd24861e65649a7b00a9a8345273fe1d853a90/quinn-proto/src/endpoint.rs#L611

• Does this change what s2n-quic sends over the wire?
• No
• Does this change any public APIs?
• maybe

[WesleyRosenblum]

Hi WeiChao! Can you provide more context on why you need this functionality?

[taikulawo]

For different domain, apply use Config. use different TLS backend in this issue.

1. On ClientHelloCallback, we read connection SNI.
2. Read our internal config, get s2n Config from map, HashMap::get(sni) -> Config
3. connection.set_config(config)

cloudflare/quiche#1259

s2n current design

1. choose tls provider
2. create server
3. listen and accept.

So we can only choose one of tls backend, s2n-tls or rustls at compile time.

Quinn solve this through dyn trait.
quinn-rs/quinn#2024 (comment)
https://github.com/quinn-rs/quinn/blob/6bfd24861e65649a7b00a9a8345273fe1d853a90/quinn-proto/src/endpoint.rs#L611

[WesleyRosenblum]

Thanks WeiChao. This specialized behavior isn't something that we would support in the main s2n-quic library. Fortunately, the tls::Endpoint trait (link) gives enough flexibility such that something like this could be implemented in your own application. You could then configure your s2n-quic server endpoint with your own custom tls::Endpoint that has this behavior.

At a high level, implementing this functionality would look something like the following:

You would create a tls::Endpoint impl that when new_server_session is called it holds onto the given transport parameters and returns a wrapper tls::Session that when poll is called the first time it parses the ClientHello, reads the SNI and then decides if it wants an s2n-tls or rustls session.

[taikulawo]

Wow, maybe a workaround, I will give a try. thankyou

[taikulawo]

Here are s2n bootstrap code, How I replace tls::Endpoint with my own implementation?

let tls = s2n_quic::provider::tls::s2n_tls::Server::builder()
            .with_client_hello_handler(callback)
            .unwrap()
            .build()
            .unwrap();
        let io = IoBuilder::default()
            .with_rx_socket(socket)
            .unwrap()
            .build()
            .unwrap();
        let mut server = Server::builder()
            .with_tls(tls)
            .unwrap()
            .with_io(io)
            .unwrap()
            .start()
            .unwrap();

[WesleyRosenblum]

Hi WeiChao. You will need to implement the s2n_quic::provider::tls::Provider trait (link) and the s2n_quic_core::crypto::tls::Endpoint trait (link). That should then let you provide it to the Server builder

[boquan-fang]

Hello Weichao, we are resolving this issue, since we are not implementing this in s2n-quic. Feel free to open another issue if you have any more questions.