Convert from SslConnector to TlsConnector

[massand]

It would be useful to add the ability to construct a native_tls::TlsConnector from openssl:ssl::SslConnector using:

From<openssl::ssl::SslConnector> for native_tls::TlsConnector

Here is an example scenario - hyper-proxy provides the ability to set the tunneling native_tls::TlsConnector. However, when employing custom OpenSSL engines to offload crypto operations during TLS, the openssl crate is the only convenient path to achieve such an implementation.

It would be cleaner to add support for the openssl::ssl::SslConnector -> native_tls::TlsConnector conversion, which would allow hyper-proxy to continue using native_tls::TlsConnector (and tokio-native-tls stream) for TLS handshake, instead of adding a new hyper-proxy feature for openssl::ssl::SslConnector (and tokio_openssl::SslStream) support.

[sfackler]

This crate does not publicly expose the backend libraries so that they can be upgraded without a breaking change. This crate is specifically designed to be a "least common denominator", not an general interface on top of the backend libraries.

[ryankurte]

Would you be open to adding this behind a feature guard? I understand the intent is to isolate underlying TLS library but, native-tls appears used super commonly as a transitive dependency often exposed in the API of other crates. Because of the least common denominator approach if you need any additional configuration you cannot use -any- of them (at least, without refactoring them to not use native-tls).

[sfackler]

Adding a Cargo feature does not change the fact that exposing the underlying libraries would make it a breaking change to upgrade them. This crate is not intended to be the single canonical TLS library that everything uses.