rustls / futures-rustls Goto Github PK

As per https://rustsec.org/advisories/RUSTSEC-2023-0052 webpki is vulnerable, but it is also unmaintained. Better switch to rustls-webpki.

rustls::server::Acceptor allows selecting a ServerConfig based on the client hello. This has various potential benefits. I need this for a presumably less obvious case than usual:

I develop the rustls-acme crate, which implements Let's Encrypt certificate acquisition via the tls-alpn-01 mechanism. This requires negotiating an application protocol via alpn iff the client hello offers a specific protocol and only that one protocol.

This wouldn't be particularly problematic if I relaxed the last condition a bit, because I could list that protocol in the ServerConfig and be done with it. However, as of rustls 0.20 raises an error if the ServerConfig specifies at least one protocol and the client offers at least one, but no overlap can be found. Therefore I need to select a different config iff the client hello indicates a tls-alpn-01 validation request.

I am using async-rustls (based on rustls 0.19), which simply doesn't do alpn if no overlap is found. Switching to futures-rustls and rustls 0.20 in is blocked by the inability to work around this issue in futures-rustls.

This crate is using a slightly outdated version of rustls, which puts aws-lc-rs behind a feature that can only be reached on the "inner" Cargo.toml and it makes the module unusable.
Would it be possible to pass feature to rustls directly from futures-rustls please ?

This is a great crate. The state of affair of async-tls is problematic. Its update to rustls 0.20 is still not released, whereas users are providing continuous feedback to tokio-tls.

It seems to me that futures-rustls is compatible with either tokio-tls and async-tls. Is it possible to use rust features to provide a different configuration for different needs of backends.

For example, is it possible to use features = ['tokio', 'futures'] where the default feature is 'tokio' so that tokio users won't feel any change, while enabling async-std or gio users to benefit from the community and continuous improvement of the library by enabling the 'futures' feature for their choice of backend?

Hi! What does LazyConfigAcceptor do? When would it be more appropriate to use LazyConfigAcceptor instead of using TlsAcceptor directly?