Consider optionally use openssl for windows about rust-native-tls HOT 9 CLOSED

I personally agree with @sfackler that if you want to use OpenSSL then you should use OpenSSL (the crate). Also note that we've got tokio-openssl as a crate as well.

Over time I've come to find native-tls switching backends via features a little odd. That means that downstream code which wants to use the extension traits now has no reasonable way to do so (b/c it doesn't know what will be activated without gymnastics).

from rust-native-tls.

Schannel does support server-side TLS.

If you want to use OpenSSL, then it seems to me like you should use OpenSSL? This crate is designed specifically for the use case of "I don't need any complex features, I just want a thing that works with the minimal possible effort".

from rust-native-tls.

The readme says otherwise: https://github.com/steffengy/schannel-rs/blob/master/README.md
I think this crate can achieve both goals: work with the minimal possible effort, and support more complex features.
After all, it's the only crate I know that provides a common interface to several tls libraries.

from rust-native-tls.

I've fixed the schannel readme, thanks.

Many crates support pluggable TLS implementations, including hyper, rust-postgres, etc.

from rust-native-tls.

Ha, looks like we ended up in the same place.

@sfackler there's a similar discussion I have over on hickory-dns/hickory-dns#103

Right now I'm using the @alexcrichton 's tokio-tls crate. This request to use OpenSSL instead of native. I see your comments above about everyone using pluggable TLS implementations, and I could do the same, but the concern I have is that we may end up with a lot of duplicate code, and some of it complex in the case of tokio.

My thought was, why not just have a feature on native-tls for always using OpenSSL, obviously defaulting to the native platform. This would allow for shared code up the stack, with native-tls being the common TLS abstraction layer (much like MIO is for async IO). Thoughts?

from rust-native-tls.

There isn't much complex duplication in my experience: https://github.com/sfackler/rust-postgres/blob/master/tokio-postgres/src/tls/openssl.rs.

This would allow for shared code up the stack, with native-tls being the common TLS abstraction layer (much like MIO is for async IO).

This is the wrong layer to abstract at IMO. If you want to use OpenSSL in particular and that had to be done through native-tls, you'd have to do half of the setup through native-tls APIs, import the trait that lets you downcast, and then do the other bit of configuration. It seems way simpler to just use OpenSSL's APIs directly and have the trait abstraction layer be at the level of "wrap this stream with TLS".

from rust-native-tls.

Yes, I've been considering a pattern around this, definitely. The hyper style interfaces look good. The concern I have is really duplicating the tokio support for MidHandshake<S> in the tokio-tls library. This is currently a state machine over the native-tls libraries abstractions. I'd prefer not to duplicate that code unnecessarily. https://github.com/tokio-rs/tokio-tls/blob/master/src/lib.rs#L203

Though I do agree with you that there is a lot of custom code that needs to exist to demux between the native libraries. Perhaps there is no way around having to duplicate some of this, but I was hoping not to.

from rust-native-tls.

Oh I missed the tokio-openssl crate... I was about to ask you if I shoudl start one. I guess this is a no-op for me.

I propose closing this issue then.

from rust-native-tls.

@alexcrichton thanks for the insight.

from rust-native-tls.