feature = "dummy" about rust-native-tls HOT 13 CLOSED

Doesn't http/2 over TLS require ALPN?

I think it does require ALPN, however, it works without ALPN at least for gRPC.

But why doesn't rust-native-tls support ALPN?

native-tls is not the "one true TLS library".

Well, it would be good to have "one true TLS library". And I don't have time to invest in implementing abstraction over different TLS implementations. (Especially because I don't understand TLS stuff very vell).

It would be nice if rust-native-tls supported the most important stuff, and I wouldn't use anything it doesn't support. (Actually, I don't know what else besides ALPN I need from TLS library).

from rust-native-tls.

It seems pretty strange that it would take hundreds of conditionals do disable a TLS backend. Maybe some refactoring is in order? There is 1 #[cfg] for each TLS backend in rust-postgres for example.

from rust-native-tls.

Well, not hundreds, but tens if you have client and server and dozen of convenient constructors. And you still need to build your code twice: with and without tls just to check you haven't missed something.

Actually, I have two libraries: http/2 and grpc (which depends on http/2), so I need to have these cfg flags in two libraries.

No-op rusttls would be convenient.

from rust-native-tls.

What happens if someone wants to use something other than native-tls?

from rust-native-tls.

Why would someone want to use something other than native tls?

from rust-native-tls.

native-tls is not the "one true TLS library". It's targets the "I don't want to do anything particularly exotic and just want this to work with minimal effort". There an enormous swath of functionality you can get using OpenSSL directly instead of native-tls for example.

from rust-native-tls.

How can http2 be using this library in the first place? Doesn't http/2 over TLS require ALPN?

from rust-native-tls.

Seems like Security.framework doesn't support ALPN. So even if rust-native-tls supported ALPN, I couldn't use it on OSX for proper implementation of HTTP/2.

So I've got another suggestion (which will also make this feature request needless).

Would you like/could you have a crate like rust-tls-api with traits

trait TslConnector {
    fn connect(...) { ... }
}
trait TlsAcceptor {
    fn accept(...) { ... }
}
trait TlsConnectorBuilder { ... }
trait TlsAcceptorBuilder { ... }

and no implementations?

So rust-openssl, rust-schannel and rust-security-framework could depend on that crate and implement these traits?

rust-native-tls could also implement these traits.

So in my implementation of http2/grpc I could simply depend on rust-tls-api, have no #[cfg] directives at all, and concrete implementation of TLS (or none at all) could be chosen by library user.

from rust-native-tls.

Yeah, that'd be a good thing to do.

from rust-native-tls.

Great! What's next? Will you do it all by yourself? Can I help?

from rust-native-tls.

I'll start messing around with stuff over the weekend.

from rust-native-tls.

I've created a sketch of implementation: rust-tls-api.

Doesn't work yet, it's empty interfaces and implementation for rust-native-tls in separate crate.

The largest problem I've encountered which I overlooked before is a lack of HKT in Rust. It's not possible to declare:

struct TlsConnector {
    type <S> TlsStream<S>;
}

So I decided to do it with boxing: tls_api::TlsStream is a struct:

struct TlsStream(Box<TlsStreamImpl>);

Which is probably not a big deal.

from rust-native-tls.

Well, it actually works at least for simple cases:

• generic test
• executed with rust-native-tls

from rust-native-tls.