Support SSL_set_ex_data to ServerConnection to fit async ecosystem

[taikulawo]

I saw many use cases in issues that we want to have more control over rustls to integrate into async ecosystem.

Our certificates recevied from control panel, and we want to set different cert based on SNI and update at runtime.

All certifcates maintain in tokio::sync::RwLock, but rustls ResolvesServerCert and many other trait defined in ServerConfig are Sync, which can't embed into async workflow.
https://docs.rs/rustls/latest/rustls/server/trait.ResolvesServerCert.html

Could we support openssl https://www.openssl.org/docs/man1.1.1/man3/SSL_set_ex_data.html to empower rustls callback trait?
we can set extra certificate in async workflow and then call rustls handshake, so that we can satisfy many async use case

The api should change to

pub trait ResolvesServerCert: Send + Sync {
    /// Choose a certificate chain and matching key given simplified
    /// ClientHello information.
    ///
    /// Return `None` to abort the handshake.
    fn resolve(&self, ssl: &mut SslConnection, client_hello: ClientHello) -> Option<Arc<sign::CertifiedKey>> {
        let cert = ssl.extra_data("certificate");
        return Some(Arc::new(cert))
    }
}

client_hello is useless for me, we have a tls client hello parse https://github.com/iamwwc/tunnel/blob/master/src/app/sniffer.rs#L91, which extract SNI from record, and then wrapper into other high level tls stream wrapper
https://github.com/iamwwc/tunnel/blob/af5ce758d74d092c9905d6c57957058f9998e61c/src/app/sniffer.rs#L186

[taikulawo]

relative issue #89

[djc]

The modern way to do this is with the Acceptor. If you're using Tokio, you might want the tokio-rustls equivalent LazyConfigAcceptor. This will give you a ClientHello type that exposes the SNI.

If you have additional constraints that mean you would like to have more methods on our ClientHello type, I'd be happy to hear your use case.

In my view, callbacks are usually not great, nor do I think that OpenSSL APIs are always the best example of how to model the solution to a problem. So we'd prefer to find a different solution to your use cases.

[taikulawo]

My use case is customize certificate verify process.

Every connection use different root cert store according to control panel information.

In openssl, we set x509 store by set_ex_data before ssl handshake, fetching it in verify callback, and then use the store in callback to complete handshake.

How I can do this by rustls way?

The only way I though to do is create ServerConfig everytime, then let conf = Arc::new(ServerConfig), set conf in server_connection, but it require heap allocation for every handshake

[djc]

Did you look at the documentation for the acceptors that I linked to?

[taikulawo]

Yes, I have read all acceptor, accepted api, but I'm not sure how compose apis to implement

[djc]

Which part is unclear to you? The LazyConfigAcceptor<TcpStream> implements Future, so you poll it. Once it yields Ready you get a StartHandshake which gives you access to the ClientHello type. The ClientHello::server_name() method lets you inspect the SNI value. Then you start kick off the handshake with an Arc<ServerConfig> which you can pregenerate (if you have a fixed set of server names) or generate some other way.

[taikulawo]

We are gateway like nginx, others can choose different domain name to use.

we can change configuration dynamically at app runtime, for example, change to different root ca, different alpn decision which all cause to regenerate serverconfig everytime.

ServerConfig live behind in Arc, I can't get mut after clone it. Full regenerate Arc<ServerConfig> isn't a good idea I think

Making one of these can be expensive, and should be once per process rather than once per connection.

[djc]

Why don't you think it's a good idea to generate per-client ServerConfigs? It doesn't seem like a big deal to me.

[taikulawo]

I just follow docs said https://docs.rs/rustls/latest/rustls/server/struct.ServerConfig.html

Making one of these can be expensive, and should be once per process rather than once per connection.

[djc]

If you're worrying at this level, run a benchmark and check for yourself what the performance is like. The performance will vary depending on how many of the configuration options in the ServerConfig you actually need to use.

I'm going to close this now, since I haven't seen any use cases that I don't think we can serve right now.