It would be convenient if ServerContext had new_for_test function which returns a ServerContext which "just works". It could be useful for two purposes:

• for tests (e. g. to test that my http client works with my http server over https)
• to make something work right now

_for_test suffix emphasizes that function should not be used in production.

Is there a reason why TlsStreamExt isn't exposed? I'd quite like to port something that needs to be able to inspect the openssl::ssl::Ssl struct.

Both AsyncRead and AsyncWrite except the same contract as poll. Aka, reading and writing should be possible to perform on separate tasks. tokio-io assumes this w/ split. However, TLS may perform writes in reads and reads in writes. If TLS's read and writes are performed in separate tasks, it is possible to break the contract and end up with dead locks.

As far as I can tell, there is only a single possible fix and that is notifying both the reader task AND the writer task when either the inner read or write half becomes ready. Doing so would probably require using with_notify to implement a "broadcast" notification strategy where both the outer read & write tasks get notified when either the inner read or write become ready.

There could be potential refinements in the heuristic, but the general strategy would be the same.

Looking at the source, it looks like there's an implementation of ClientProto for Client. If I'm also reading the tokio-proto source correctly, there's an implementation of BindClient for all instances of ClientProto. So shouldn't the following work?

let connector = TlsConnector::builder().unwrap().build().unwrap();
let tlsProto: tls::proto::Client<MyProto> =
     tls::proto::Client::new(
        MyProto,
        connector,
        "host.name"
    );
let f = tlsProto.bind_client(handle, io);

I'm getting:

the method `bind_client` exists but the following trait bounds were not satisfied: `tokio_tls::proto::Client<client::MyProto> : tokio_proto::pipeline::ClientProto<_>`...

I fear I'm confused by the various types and the solution is quite simple.

I may have missed it. Have you implemented TLS for tokio-proto pipeline or multiplex servers? After a quick look it seems that tokio-core may need to be touched as well? Thanks

It is not clear how to integrate tokio-tls with tokio-proto

Released 6/25/2018.

SSL_VERIFY_PEER is forced for ClientContext https://github.com/tokio-rs/tokio-tls/blob/master/src/openssl.rs#L73

My use case is that I need to accept a tls connection with SSL_VERIFY_NONE first, prompt the user if he want to pair the other device, add the cert to a local cert pool and use SSL_VERIFY_PEER on the next connection.

The client advertise its cn before the handshake allowing the server to determine if it should use SSL_VERIFY_PEER of SSL_VERIFY_NONE.

Do any of these libraries expose the SNI bit of the TLS stream so that the tokio/hyper server can route the request?

I'm having trouble figuring out how you'd do this with what's provided.

Example API: https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5

Hi. How do I set certificates?

https://tokio-rs.github.io/tokio-tls/tokio_tls/struct.ClientContext.html

This is pointing to openssl SslContext but I'm facing errors with below code

let cx = ClientContext::new().unwrap();
        {
            let backend_cx = cx.ssl_context_mut();
            let _ = backend_cx.set_CA_file("ca.crt");
            let _ = backend_cx.set_certificate_file("test.crt", X509FileType::PEM);
            let _ = backend_cx.set_private_key_file("test.key", X509FileType::PEM);
        }
        cx.handshake("server:8883", socket)

Error

error: no method named `set_CA_file` found for type `&mut security_framework::secure_transport::SslContext` in the current scope
src/main.rs:26             let _ = backend_cx.set_CA_file("/home/raviteja/Desktop/mqtt_gcloud_certs/ca.crt");
                                              ^~~~~~~~~~~
src/main.rs:27:32: 27:52 error: no method named `set_certificate_file` found for type `&mut security_framework::secure_transport::SslContext` in the current scope
src/main.rs:27             let _ = backend_cx.set_certificate_file("/home/raviteja/Desktop/mqtt_gcloud_certs/client_mqtt_veh_test.crt", X509FileType::PEM);
                                              ^~~~~~~~~~~~~~~~~~~~
src/main.rs:28:32: 28:52 error: no method named `set_private_key_file` found for type `&mut security_framework::secure_transport::SslContext` in the current scope
src/main.rs:28             let _ = backend_cx.set_private_key_file("/home/raviteja/Desktop/mqtt_gcloud_certs/client_mqtt_veh_test.key", X509FileType::PEM);

From README.md:
You can find an example of using this crate at https://tokio.rs along with a detailed explanation of what's happening.

The link points to https://tokio.rs/docs/getting-started/tls/ which returns a 403 forbidden error page.

It seems impossible to use tokio_tls to listen to two sockets at the same time:

fn main() {
  let mut lp = Core::new().unwrap();
  let loop1 = serve_https(lp.handle(), "cert1.pfx", 8443);
  let loop2 = serve_https(lp.handle(), "cert2.pfx", 8444);
  lp.run(loop1.join(loop2) ... ).unwrap();
}

fn serve_https(handle: Handle, cert: &str, port: usize) -> Box<Future<Item=(), Error=io::Error>> {
  ...
  let listener = TcpListener::bind(&addr, &handle).unwrap();
  let acceptor = TlsAcceptor::builder(pfx).unwrap().build().unwrap();
  ...
  Box::new(listener.incoming().for_each(move |(socket, _)| {
    acceptor.accept_async(socket).then(move |r| match r {
      ...
    }
  }
}

$ curl -k https://localhost:8444
{"success": true}
$ curl -k https://localhost:8443
TLS connection failed: Error { code: -50, message: "One or more parameters passed to a function were not valid." }
curl: (35) Server aborted the SSL handshake

running https://github.com/ashleygwilliams/npm-registry-follower-rust/tree/log on both OSX and Ubuntu i get:

  Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/npm-registry-follower`
ERROR:tokio_proto::streaming::pipeline::client: pipeline error: No error.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Custom(Custom { kind: BrokenPipe, error: StringError("broken pipe") }) })', ../src/libcore/result.rs:799
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Process didn't exit successfully: `target/debug/npm-registry-follower` (exit code: 101)

previously only got this error on https in OSX, now it is for all https on OSX and Ubuntu. have been speaking with @alexcrichton - he told me to file here. full log text for RUST_LOG=hyper,tokio_proto cargo run &> log.txt is at https://github.com/ashleygwilliams/npm-registry-follower-rust/blob/log/log.txt

EDIT: the log included is from being run on OSX. lemme know if you want the one from ubuntu and i can push that as well

It would be great to have a sample that shows how to compose protocols.

client.get(uri)

works, but

let mut request = Request::new(Method::Get, uri);
client.request(request)

results in a broken pipe.

hyper 0.11.2
hyper-tls 0.1.2
tokio-core 0.1.9

Tested on Windows 10 and Arch Linux.

The choice of whether to send SNI should be separated from the choice of whether to validate the certificate for the (SNI) host name.

In particular, a server might use the SNI to route a connection to a backend, and/or it might fail to do any routing if SNI isn't provided, so SNI is needed in some cases even when certificate validation isn't done.

Also, I imagine some users might want to avoid putting SNI in the client hello but still want to validate the certificate for a particular host name, e.g. if they're trying to hide the hostname from the plaintext part of the TLS connection.

Some users of this API are already doing the wrong thing. For example, this one is disabling SNI when only disabling certificate verification is intended: https://github.com/hyperium/hyper-tls/blob/da69ab8b9897f3b2bce25e5afce02ff94b750985/src/client.rs#L93-L100

Also, IMO, the scope of this crate should be "connect Tokio and rust-native-tls" together. tokio-tls should have a way of accepting a configuration that is configured using the rust-native-tls APIs, and that should be the way configuration of SNI, certificate validation, etc. is done, without any such APIs in tokio-tls itself.

Therefore, I propose we remove this API.

See the related discussion at quininer/tokio-rustls#14 (comment)

Hi,
what are plans for upgrade to new tokio?
I'm especially interested because I used it with hyper 0.11 for server side tls (via tokio-proto), but with new hyper 0.12 this option is not available.

Not sure of the long-term plans but it would be nice if this project was published as a crate.

For example, here's the familiar hyper/tokio code for when you want to bring your own reactor and grab the connection's socket address:

struct MyService {
    peer: SocketAddr
}

fn main() {
    let mut core = Core::new().unwrap();
    let handle = core.handle();

    let addr = "127.0.0.1:3000".parse().unwrap();
    let http = Http::new();
    let listener = tokio_core::net::TcpListener::bind(&addr, &handle).unwrap();

    let factory = move |peer| {
        MyService { peer }
    };

    let future = listener.incoming().for_each(move |(socket, peer)| {
        let conn = http.serve_connection(socket, factory(peer))
            .map(|_| ())
            .map_err(|e| eprintln!("server connection error: {}", e));

        handle.spawn(conn);
        Ok(())
    });

    println!("Listening on http://localhost:3000");
    core.run(future).unwrap()
}

However, I've been unable to figure out how to collaborate the structs and traits in tokio-tls to recreate that.

The only thing the example demonstrates is the trivial case where you don't have your own executor nor do you want to access the client socket address.

let acceptor = TlsAcceptor::builder(pfx).unwrap().build().unwrap();
let proto = proto::Server::new(Http::new(), acceptor);
let srv = TcpServer::new(proto, https.host);
srv.serve(move || Ok(MyService(ctx)));

I can see the sort of code I wrote in my first snippet inside the tokio-tls::proto module, but the types are a bit advanced.

Could somebody provide an example? I'd love to update the examples/ folder once I figure something out.

Hey,
it seems like AppVeyor does not run anymore.

Trying to follow the futures-rs tutorial I stumbled on that I was missing the system package libssl-devel.

I'm running a fresh install of Ubuntu for other flavors of Linux it might be openssl-devel.
Please add this to the usage instructions.

I'm trying to use tokio-tls in a non-HTTP scenario with self-signed certificates building a peer to peer connection. All I want is essentially a Diffie-Hellman key exchange and an encrypted channel. During the handshake I'd like to avoid the usual PKI trust chain and let peers decide programatically if they trust the certificate of the other party.

To achieve this, the usual way is to provide a hook for a callback function where certificate of the peer can be validated. In Java you can set a custom TrustManager while initializing your SslContext. Also, crate rustls nicely supports this like here https://github.com/ctz/rustls/blob/master/examples/tlsclient.rs#L424 , but I'd like the same thing in Tokio without blocking.

I've found no way to achieve this with tokio-tls. Is this possible somehow out of the box? If not, is it hard to add to the library?

As per the commit message for b121025

(just wanted to keep track of this)

Hi!
This issue may be related to sfackler/rust-native-tls

I tried to implement ssl support for mysql_async using tokio-tls but faced an issue with random errors in tests on macOS (10.12.6). Implementation itself is in blackbeam/mysql_async@ff1d9ee

Also there is no errors with RUST_TEST_THREADS=1.

All errors is in connect_async and usually looks like this (but i believe i once saw something different):

Error { code: -50, message: "One or more parameters passed to a function were not valid." }

You can setup my environment quite easy (if you have make and mysql binaries in your PATH):

git clone https://github.com/blackbeam/rust-mysql-simple.git
git clone https://github.com/blackbeam/mysql_async.git
cd rust-mysql-simple
make test
# now you need to Ctrl+C when cargo starts to compile mysql
cd ../mysql_async
cargo test --features "ssl"

cc @sfackler

https://github.com/sfackler/rust-native-tls just had a 0.1.0 release pushed to crates.io.