Create native-tls objects from native library objects.

[nrc]

I'd like to be able to create a native-tls connector/acceptor from the corresponding native objects (e.g., from an OpenSSL connector/acceptor on Linux). The general motivation is that sometimes you have the native objects passed to us and we don't know the configuration, then we want to use the object with native-tls for compatibility with the ecosystem. Our specific use case is that we get an OpenSSL object with keys, etc. already configured and no access to these things since we don't have the privileges.

Does this sound like something we could add to native-tls? If so, I can implement and send a PR.

I have experimented with a solution in this branch. We actually create the builder objects rather than connector/acceptor. It's obviously pretty rough and not ready for making into a PR, but what do you think about the approach? I imagine we would have similar functionality for the other backends.

[sfackler]

See #196.

[nrc]

I would think that with such a security-crucial thing as the TLS library, you are socially locked in to the underlying crates. So even if it were not a technical breaking change, it would need to be a breaking change anyway. E.g., we use native-tls because it is an abstraction over OpenSSL, if that were to change we potentially we would have to stop using it for compliance reasons, even if the API is compatible. Similarly, I'd guess that if you wanted to support other backends, you'd want them as well as the current ones, for similar reasons. Then this kind of thing could be done without harming back compat (assuming a name change for the ctor functions).

[sfackler]

This library is not intended for people that have strong compliance requirements. It is intended for people who just want a TLS implementation that works with reasonable settings with a minimal amount of fuss.

[sfackler]

There is also a difference between switching off of OpenSSL and switching from e.g. rust-openssl 0.10 to 0.11.