Support native-tls as a TLS abstraction.

[YoEight]

Feature Request

Support native-tls as a TLS abstraction.

Crates

• native-tls

Motivation

rustls because of its webpki dependency, can't support certificate with an IP address as its common name: briansmith/webpki#54

It prevents tonic from being used in many situations due to this limitation.

Proposal

Alternatives

[LucioFranco]

@YoEight ah that is unfortunate :( I would like to see rustls support this feature and I don't think it totally makes that much sense to add openssl support back to the transport module. native-tls will not work because it currently doesn't support ALPN negotiation.

That said, it should be possible to supply your own connector which uses something like openssl via https://docs.rs/tonic/0.1.0-beta.1/tonic/transport/struct.Endpoint.html#method.connect_with_connector. If this is the route you want to take I am happy to help :) but as it stands right now I don't think we will provide support out of the box for openssl or native-tls.

[YoEight]

Happy new year @LucioFranco !
I'd be glad to use your approach, however, excuse my lack of SSL skills but wouldn't be doing that conflict with the handshake done by rustls?

[LucioFranco]

@YoEight if you don't configure tls with the builders then there will be no tls done. This allows a user to pass in what ever IO type they need. If they want the crate to do tls you can then apply it on top but its not required nor default.

I have seen a couple users have issues with rustls I am considering writing a tower-openssl crate that will implement the correct types for MakeConnection so that all you need to do is pass in the openssl config.

[LucioFranco]

We now have examples of using hyper directly with tonic, so for now you can use hyper-tls or hyper-openssl to achieve what you want.