Git Product home page Git Product logo

hyper-rustls's Introduction

Rustls is a modern TLS library written in Rust.

Status

Rustls is used in production at many organizations and projects. We aim to maintain reasonable API surface stability but the API may evolve as we make changes to accomodate new features or performance improvements.

We have a roadmap for our future plans. We also have benchmarks to prevent performance regressions and to let you evaluate rustls on your target hardware.

If you'd like to help out, please see CONTRIBUTING.md.

Build Status Coverage Status (codecov.io) Documentation Chat

Changelog

The detailed list of changes in each release can be found at https://github.com/rustls/rustls/releases.

Documentation

https://docs.rs/rustls/

Approach

Rustls is a TLS library that aims to provide a good level of cryptographic security, requires no configuration to achieve that security, and provides no unsafe features or obsolete cryptography by default.

Rustls implements TLS1.2 and TLS1.3 for both clients and servers. See the full list of protocol features.

Platform support

While Rustls itself is platform independent, by default it uses aws-lc-rs for implementing the cryptography in TLS. See the aws-lc-rs FAQ for more details of the platform/architecture support constraints in aws-lc-rs.

ring is also available via the ring crate feature: see the supported ring target platforms.

By providing a custom instance of the crypto::CryptoProvider struct, you can replace all cryptography dependencies of rustls. This is a route to being portable to a wider set of architectures and environments, or compliance requirements. See the crypto::CryptoProvider documentation for more details.

Specifying default-features = false when depending on rustls will remove the dependency on aws-lc-rs.

Rustls requires Rust 1.63 or later.

Cryptography providers

Since Rustls 0.22 it has been possible to choose the provider of the cryptographic primitives that Rustls uses. This may be appealing if you have specific platform, compliance or feature requirements that aren't met by the default provider, aws-lc-rs.

Users that wish to customize the provider in use can do so when constructing ClientConfig and ServerConfig instances using the with_crypto_provider method on the respective config builder types. See the crypto::CryptoProvider documentation for more details.

Built-in providers

Rustls ships with two built-in providers controlled with associated feature flags:

  • aws-lc-rs - enabled by default, available with the aws_lc_rs feature flag enabled.
  • ring - available with the ring feature flag enabled.

See the documentation for crypto::CryptoProvider for details on how providers are selected.

Third-party providers

The community has also started developing third-party providers for Rustls:

Custom provider

We also provide a simple example of writing your own provider in the custom-provider example. This example implements a minimal provider using parts of the RustCrypto ecosystem.

See the Making a custom CryptoProvider section of the documentation for more information on this topic.

Example code

Our examples directory contains demos that show how to handle I/O using the stream::Stream helper, as well as more complex asynchronous I/O using mio. If you're already using Tokio for an async runtime you may prefer to use tokio-rustls instead of interacting with rustls directly.

The mio based examples are the most complete, and discussed below. Users new to Rustls may prefer to look at the simple client/server examples before diving in to the more complex MIO examples.

Client example program

The MIO client example program is named tlsclient-mio. The interface looks like:

Connects to the TLS server at hostname:PORT.  The default PORT
is 443.  By default, this reads a request from stdin (to EOF)
before making the connection.  --http replaces this with a
basic HTTP GET request for /.

If --cafile is not supplied, a built-in set of CA certificates
are used from the webpki-roots crate.

Usage:
  tlsclient-mio [options] [--suite SUITE ...] [--proto PROTO ...] [--protover PROTOVER ...] <hostname>
  tlsclient-mio (--version | -v)
  tlsclient-mio (--help | -h)

Options:
    -p, --port PORT     Connect to PORT [default: 443].
    --http              Send a basic HTTP GET request for /.
    --cafile CAFILE     Read root certificates from CAFILE.
    --auth-key KEY      Read client authentication key from KEY.
    --auth-certs CERTS  Read client authentication certificates from CERTS.
                        CERTS must match up with KEY.
    --protover VERSION  Disable default TLS version list, and use
                        VERSION instead.  May be used multiple times.
    --suite SUITE       Disable default cipher suite list, and use
                        SUITE instead.  May be used multiple times.
    --proto PROTOCOL    Send ALPN extension containing PROTOCOL.
                        May be used multiple times to offer several protocols.
    --no-tickets        Disable session ticket support.
    --no-sni            Disable server name indication support.
    --insecure          Disable certificate verification.
    --verbose           Emit log output.
    --max-frag-size M   Limit outgoing messages to M bytes.
    --version, -v       Show tool version.
    --help, -h          Show this screen.

Some sample runs:

$ cargo run --bin tlsclient-mio -- --http mozilla-modern.badssl.com
HTTP/1.1 200 OK
Server: nginx/1.6.2 (Ubuntu)
Date: Wed, 01 Jun 2016 18:44:00 GMT
Content-Type: text/html
Content-Length: 644
(...)

or

$ cargo run --bin tlsclient-mio -- --http expired.badssl.com
TLS error: InvalidCertificate(Expired)
Connection closed

Server example program

The MIO server example program is named tlsserver-mio. The interface looks like:

Runs a TLS server on :PORT.  The default PORT is 443.

`echo' mode means the server echoes received data on each connection.

`http' mode means the server blindly sends a HTTP response on each
connection.

`forward' means the server forwards plaintext to a connection made to
localhost:fport.

`--certs' names the full certificate chain, `--key' provides the
RSA private key.

Usage:
  tlsserver-mio --certs CERTFILE --key KEYFILE [--suite SUITE ...] [--proto PROTO ...] [--protover PROTOVER ...] [options] echo
  tlsserver-mio --certs CERTFILE --key KEYFILE [--suite SUITE ...] [--proto PROTO ...] [--protover PROTOVER ...] [options] http
  tlsserver-mio --certs CERTFILE --key KEYFILE [--suite SUITE ...] [--proto PROTO ...] [--protover PROTOVER ...] [options] forward <fport>
  tlsserver-mio (--version | -v)
  tlsserver-mio (--help | -h)

Options:
    -p, --port PORT     Listen on PORT [default: 443].
    --certs CERTFILE    Read server certificates from CERTFILE.
                        This should contain PEM-format certificates
                        in the right order (the first certificate should
                        certify KEYFILE, the last should be a root CA).
    --key KEYFILE       Read private key from KEYFILE.  This should be a RSA
                        private key or PKCS8-encoded private key, in PEM format.
    --ocsp OCSPFILE     Read DER-encoded OCSP response from OCSPFILE and staple
                        to certificate.  Optional.
    --auth CERTFILE     Enable client authentication, and accept certificates
                        signed by those roots provided in CERTFILE.
    --crl CRLFILE ...   Perform client certificate revocation checking using the DER-encoded
                        CRLFILE. May be used multiple times.
    --require-auth      Send a fatal alert if the client does not complete client
                        authentication.
    --resumption        Support session resumption.
    --tickets           Support tickets.
    --protover VERSION  Disable default TLS version list, and use
                        VERSION instead.  May be used multiple times.
    --suite SUITE       Disable default cipher suite list, and use
                        SUITE instead.  May be used multiple times.
    --proto PROTOCOL    Negotiate PROTOCOL using ALPN.
                        May be used multiple times.
    --verbose           Emit log output.
    --version, -v       Show tool version.
    --help, -h          Show this screen.

Here's a sample run; we start a TLS echo server, then connect to it with openssl and tlsclient-mio:

$ cargo run --bin tlsserver-mio -- --certs test-ca/rsa/end.fullchain --key test-ca/rsa/end.rsa -p 8443 echo &
$ echo hello world | openssl s_client -ign_eof -quiet -connect localhost:8443
depth=2 CN = ponytown RSA CA
verify error:num=19:self signed certificate in certificate chain
hello world
^C
$ echo hello world | cargo run --bin tlsclient-mio -- --cafile test-ca/rsa/ca.cert -p 8443 localhost
hello world
^C

License

Rustls is distributed under the following three licenses:

  • Apache License version 2.0.
  • MIT license.
  • ISC license.

These are included as LICENSE-APACHE, LICENSE-MIT and LICENSE-ISC respectively. You may use this software under the terms of any of these licenses, at your option.

Project Membership

  • Joe Birr-Pixton (@ctz, Project Founder - full-time funded by Prossimo)
  • Dirkjan Ochtman (@djc, Co-maintainer)
  • Daniel McCarney (@cpu, Co-maintainer - full-time funded by Prossimo)
  • Josh Aas (@bdaehlie, Project Management)

Code of conduct

This project adopts the Rust Code of Conduct. Please email [email protected] to report any instance of misconduct, or if you have any comments or questions on the Code of Conduct.

hyper-rustls's People

Contributors

alex avatar atouchet avatar cpu avatar cramertj avatar crawford avatar cryze avatar ctz avatar dependabot-preview[bot] avatar dependabot-support avatar dependabot[bot] avatar djc avatar erickt avatar g2p avatar gelbpunkt avatar jjant avatar lucab avatar marcoieni avatar mehcode avatar messense avatar mikailbag avatar nwtgck avatar paolobarbolini avatar pickfire avatar richardoc avatar seanmonstar avatar sfackler avatar tgeoghegan avatar timluq avatar tobz avatar tottoto avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

hyper-rustls's Issues

How to generate self-signed certificates by using openssl?

I use the example code server.rs. And when I use the sample.pem and sample.rsa in the example fold, the server will crash and give me these messages:

Starting to serve on https://127.0.0.1:1337.
[!] Voluntary server halt due to client-connection error...
FAILED: error accepting connection: TLS Error: Custom { kind: InvalidData, error: AlertReceived(BadCertificate) }

And when I generated the self-signed certificates follow these instructions How to enable SSL and TLS 1.3 on NGINX.

After I load the ca.crt and ca.key file, I still got these message:

Starting to serve on https://127.0.0.1:1337.
[!] Voluntary server halt due to client-connection error...
FAILED: error accepting connection: TLS Error: Custom { kind: InvalidData, error: AlertReceived(BadCertificate) }

I want to use TLS 1.3, but I don't know how to generate the self-signed certificates. BTW, my environment is MacosX + Rust 1.45.2.

Please give me some advice, thank you.

hyper 0.12 support

I'm currently having issues porting my code to hyper 0.12 and getting it to work with hyper-rustls again.

Currently I'm stuck here:

the trait `hyper::client::connect::Connect` is not implemented for `hyper_rustls::HttpsConnector`

I think a new release might be necessary. Thanks for building rustls and hyper-rustls! :)

UnknownCA error

Steps to reproduce

git clone https://github.com/ctz/hyper-rustls
cd hyper-rustls
cargo run --example server

and in an other terminal:

curl https://127.0.0.1:1337

In the first terminal, you should get:

Starting to serve on https://127.0.0.1:1337.
FAILED: error accepting connection: received fatal alert: UnknownCA

Expected behavior

The server should not crash when the client return an UnknownCA alert and just close the connection.

Don't force HTTP2 support

Currently hyper-rustls sets alpn_protocols to advertise HTTP2 (in connector.rs).
It doesn't properly work with current hyper features (which require http2 to be explicitly enabled), and forces the user to enable a feature that has a large dependency footprint and potential security surface (or to be incompatible with some peers).

hyper-rustls should give the caller some control over that, prior to building the connector.
And the support should be conditional on an hyper-rustls/http2 feature, so that the dependency set is always correct at compile time. It could work similar to how the root certificates are determined.

HttpsConnector: expose a rustls ClientConfig builder

Capturing from #6 (comment):

let people pass in a whole Arcrustls::ClientConfig, then they can do all the file IO and error handling outside TlsClient.

I would like to see such a feature as well. I'm a bit unsure about what is the expected signature here.

I was thinking about some simple with_config(&cfg), however hyper-tls seems to have taken a different approach and now has a

fn from(args: (T, TlsConnector)) -> HttpsConnector<T>

@ctz should we have a similar from() here? Directly taking a ClientSession (I'm unsure about the hostname in the constructor)?

Update to the released tokio 0.2

This is mostly meant as a tracking issue for the update to tokio 0.2 and hyper 0.13. tokio 0.2 is out and hyper has tokio 0.2 support on master, so someone could already start migrating hyper-rustls and be ready for when they release hyper 0.13.

Dependabot can't resolve your Rust dependency files

Dependabot can't resolve your Rust dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

    Updating crates.io index
error: failed to select a version for `ring`.
    ... required by package `webpki v0.19.0`
    ... which is depended on by `hyper-rustls v0.15.1 (/home/dependabot/dependabot-updater/dependabot_tmp_dir/home/dependabot/dependabot-updater/dependabot_tmp_dir

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

Connector may panic

It seems the unwrap in this line of the connector:

let dnsname = DNSNameRef::try_from_ascii_str(dst.host()).unwrap();

may panic if the url contains an IP instead of an host name. I can't get my patch to compile right now, so I'm leaving this as an issue instead. :)

invalid dnsname

use this example:
Starting to serve on https://127.0.0.1:1337.
[!] Voluntary server halt due to client-connection error...
FAILED: run errorerror trying to connect: invalid dnsname

hyper-current: needs update for latest hyper master?

I was having a quick look at this crate and I think the hyper-current branch (for async hyper) may be a bit behind. hyper::client::HttpsConnector is not anymore there and I'm not sure how the whole thing has been re-arranged. Any hints / branch to a have a working async-hyper + rustls setup?

Update rustls version to `0.5.8` to make it work with nightly compiler.

Hi,

thanks for your library! I'm using it to get around of OpenSSL nightmares on different platforms.

I encountered a compiler error when i tried to compile my project with nightly rustc.
Error is caused by old version of rustls, which is using unknown compiler feature #[export_macro]. That issue is now fixed in 0.5.8 . source: rustls/rustls#55

Is it welcome to submit PR that upgrades just that dependency?
ps: I'm not in hurry and i can wait for next release.

How to set server TCP socket options such as `TCP_NODELAY`?

hyper has an API for that, see https://docs.rs/hyper/0.12.7/hyper/server/struct.Builder.html#method.tcp_nodelay. However based on the server example code of hyper-rustls, I do not get the required hyper::server::Builder<Incoming>, but a complex type hyper::server::Builder<futures::stream::filter_map::FilterMap<futures::stream::then::Then<futures::stream::and_then::AndThen<tokio_tcp::incoming::Incoming, [closure@webserver/src/lib.rs:328:19: 328:51 serverconfig:_], tokio_rustls::AcceptAsync<tokio_tcp::stream::TcpStream>>, [closure@webserver/src/lib.rs:329:15: 337:10], std::result::Result<std::option::Option<tokio_rustls::TlsStream<tokio_tcp::stream::TcpStream, rustls::server::ServerSession>>, std::io::Error>>, [closure@webserver/src/lib.rs:338:21: 338:26]>>. How to proceed?

Releasing 0.16.1?

Thanks for landing #69! Would it be possible to cut a 0.16.1 release? That'll allow us to pull hyper-rustls into Fuchsia.

Thanks again!

Server examples do not compile anymore

cargo run --example server
error: native library `ring-asm` is being linked to by more than one version of the same package, but it can only be linked once; try updating or pinning your dependencies to ensure that this package only shows up once

  ring v0.9.7
  ring v0.11.0

HTTP/2 over HTTPS has a problem, but HTTP/1.1 over HTTPS does not

Hi. Thank you for your wonderful project!

I upgrade hyper to 0.14 and hyper-rustls from 0.14 to 0.22. Then, I got an error only on HTTP/2 over HTTPS.

How to reproduce the error?

I created a minimal sample here:

Type the following commands to run an HTTPS server.

git clone [email protected]:nwtgck/public-code.git
cd public-code/hyper-0-14-http2-unexpected-eof-problem
cargo run

Then, https://localhost:8443/ is served.

I got "hello, world" successfully when using HTTP/1.1 over HTTPS like the following.

$ curl -k --http1.1 https://localhost:8443/
hello, world

But, I got an error when using HTTP/2 over HTTPS like the following.

$ curl -k --http2 https://localhost:8443/
curl: (56) Unexpected EOF

Here is verbose output with -vvv.

$ curl -vvvk --http2 https://localhost:8443/
*   Trying ::1...
* TCP_NODELAY set
* Connection failed
* connect to ::1 port 8443 failed: Connection refused
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=localhost
*  start date: Jan  6 15:33:09 2021 GMT
*  expire date: Jan  6 15:33:09 2022 GMT
*  issuer: CN=localhost
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fadb080d800)
> GET / HTTP/2
> Host: localhost:8443
> User-Agent: curl/7.54.0
> Accept: */*
>
* Unexpected EOF
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (56) Unexpected EOF

I got an error in Web browser too. Honestly speaking, I am not sure which library causes the error: tokio, hyper, tokio-rustls, rustls, hyper-rustls, so I may post the issue on wrong place.

When I used like the following dependencies with hyper 0.13 and the same rust code, HTTP/2 over HTTPS worked as I expected.

# <hyper 0.13 (old)>
# ...

[dependencies]
hyper = { version = "0.13", features = ["stream"] }
futures = "0.3"
http = "0.2"
tokio = { version = "0.2", features = ["macros", "stream"] }
rustls = "0.18"
hyper-rustls = "0.22"
futures-util = "0.3"
tokio-rustls = "0.14"
async-stream = "0.3.0"

HTTPS doesn't work with proxy

How do you use hyper-rustls with an http proxy? The following results an error.

let ssl = TlsClient::new();
let connector = HttpsConnector::new(ssl);
let proxy_config = ProxyConfig::new("http", host, port, connector, ssl);
let client = Client::with_proxy_config(proxy_config);

The error message is:

the trait bound hyper_rustls::TlsClient: hyper::net::SslClient<hyper::net::HttpsStream<hyper_rustls::WrappedStream>> is not satisfied

hyper-rustls 0.19 is not compiling against tokio 0.2.7

It looks like the recently released tokio 0.2.7 has broken hyper-rustls:

   Compiling tokio v0.2.7
   Compiling pin-project v0.4.6
   Compiling futures-util v0.3.1
error[E0432]: unresolved import `tokio_macros::main_basic`
   --> /Users/etryzelaar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.7/src/lib.rs:276:21
    |
276 |             pub use tokio_macros::main_basic as main;
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `main_basic` in the root

error[E0432]: unresolved import `tokio_macros::test_basic`
   --> /Users/etryzelaar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.7/src/lib.rs:277:21
    |
277 |             pub use tokio_macros::test_basic as test;
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `test_basic` in the root

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0432`.

As best as I can tell, this should be fixed once tokio-rs/tokio#2069 lands though.

API for going from WrappedStream -> rustls::Session

My specific goal is to go from hyper::server::Request to a client certificate.

I can get from Request to WrappedStream with request.ssl::<hyper_rustls::WrappedStream>().unwrap(), and a rustls::Session has get_peer_certificates, so it seems the missing piece is hyper_rustls::WrappedStream -> rustls::Session.

'cannot access native cert store

Thread 'fetch' panicked at 'cannot access native cert store: Custom { kind: InvalidData, error: BadDER }', C:\Users\runneradmin.cargo\registry\src\github.com-1ecc6299db9ec823\hyper-rustls-0.18.0\src\connector.rs:29

I got this issue when tried to run https://github.com/openethereum/openethereum client.
I use
OS Name Microsoft Windows 10 Pro
Version 10.0.18363 Build 18363

What can cause this issue? And how it can be solved?

New release with tokio v1.0

Hey @ctz—quite keen to get a new release with the recent upgrade with the tokio v1.0/hyper v0.14 bump! One of the last two pieces to get a new release of Rusoto out. Thanks in advance!

Allow creating HttpsConnector with executor

The hyper::client::HttpConnector that HttpsConnector uses under the hood has a new_with_executor() constructor. This is very useful for performance if the application already has an existing threadpool, allowing it to be reused instead of having the connector create one of its own, which as far as I can tell, is unfortunately hard-coded to only 4 threads. This constructor should really be exposed to ensure feature parity with hyper.

Cannot make HTTPS connection to www.googleapis.com as of v0.17.0

As of v0.17.0, I am unable to successfully make an HTTPS connection to www.googleapis.com. Using HTTP/2, I get a "connection closed" response (it seems the server drops the connection). Using HTTP/1.1, the connection hangs indefinitely.

There's a code snippet and debug logs here: https://gist.github.com/jbg/2b24ec191dac2bd0ad165d43efd50b11

Prior to the v0.17.0 release, we were using a local fork of hyper-rustls that I had updated to use the new rustls/tokio-rustls/etc releases, and had no issues. There's a small difference between the way v0.17.0 was updated to use the new tokio-rustls API, and the way I had updated our local fork.

With this patch applied to v0.17.0, I'm able to connect to www.googleapis.com over TLS successfully again:

https://github.com/ctz/hyper-rustls/compare/master...jbg:master?expand=1

issue when updating from `0.18` to `0.20`

Hey,

I have tried to update this crate from 0.18 to 0.20 but I'm getting the following errors without bumping hyper to 0.13:

error[E0277]: the trait bound `hyper_rustls::HttpsConnector<hyper::client::connect::http::HttpConnector>: hyper::client::connect::Connect` is not satisfied
   --> util/fetch/src/client.rs:203:12
    |
203 |                 .build(hyper_rustls::HttpsConnector::new());
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `hyper::client::connect::Connect` is not implemented for `hyper_rustls::HttpsConnector<hyper::client::connect::http::HttpConnector>`

error[E0599]: no method named `request` found for struct `hyper::Client<hyper_rustls::HttpsConnector<hyper::client::connect::http::HttpConnector>, _>` in the current scope
   --> util/fetch/src/client.rs:218:13
    |
218 |                     client.request(request.into())
    |                            ^^^^^^^ method not found in `hyper::Client<hyper_rustls::HttpsConnector<hyper::client::connect::http::HttpConnector>, _>`
    |
   ::: /home/niklasad1/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-rustls-0.20.0/src/connector.rs:22:1
    |
22  | pub struct HttpsConnector<T> {
    | ---------------------------- doesn't satisfy `_: hyper::client::connect::Connect`
    |
    = note: the method `request` exists but the following trait bounds were not satisfied:
            `hyper_rustls::HttpsConnector<hyper::client::connect::http::HttpConnector>: hyper::client::connect::Connect`

AFAIU, the trait hyper::Connect was implemented by 0.18 but was removed in 0.19.

Is there any workaround for this without using hyper 0.13?
I want to avoid using futures 0.3.

Make logging optional

Reference to rustls/rustls#22.

Having log be an optional crate is great in rustls. However, this crate depends on rustls with no way to turn off logging, which really, really looks bad in binary crates (especially since rustls prints out all of this debug info in the INFO log level instead of DEBUG).

Please either make logging an option here or turn it off.

How to handle TLS handshake error in examples/server.rs

I have tried the example. But I failed to compile the program with Ok(None):

let stream = tls_acceptor.accept(socket).map_err(|e| {
println!("[!] Voluntary server halt due to client-connection error...");
// Errors could be handled here, instead of server aborting.
// Ok(None)
error(format!("TLS Error: {:?}", e))
});

If the error does not handle here. The server will abort.

Cut a 0.19.1 release?

Just to make sure my request in #100 (comment) doesn't get missed, would it be possible to have a 0.19.1 release made? We need this in order to update hyper-rustls in Fuchsia. Thanks so much!

Release 0.15.1?

Would it be possible to release a 0.15.1 that includes the ALPN update? That way we can start to enable it reqwest.

Update examples from upstream

The stuff in examples/ are meant to be verbatim copies of upstream hyper examples of the same name, showing how to integrate this crate. But they've fallen out of sync. Bring these up to date.

How to use ECDSA certs and have a custom config?

Could you please make an example how to

  • use P-384 ECDSA certificates (they are not PKCS#1 (BEGIN RSA PRIVATE KEY), everything other than this fails (BEGIN PRIVATE KEY))
  • restrict the cipherlist to e.g. TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384
  • set the min/max TLS version, e.g. TLS 1.3-only
  • set the curve list, e.g. X25519:secp384r1:secp521r1; (would be nice if this is only for the key exchange and the curve from the certificate hasn't to be in the list, then i would set X448:X25519 in the future)

All snippets I can find about this topic in rustls are really big and seem to not fit into this.

There had been https_with_context() or https_using_context in hyper, but they say
hyperium/hyper#887 (comment)

With the release of 0.10, hyper no longer bundles a default SslClient, and instead proposes use of pluggable crates to provide it. So I'm going to close this.

Iron/hyper feels like a cool mini nginx in rust.
I think it would go too far if I ask you how to use SNI (different context per domain) on the same port with hyper, so I won't ask this.

How would that be done with your example server?
https://github.com/ctz/hyper-rustls/blob/master/examples/server.rs

Thank you, I love Rust <3

Edit: I see, it's better to use hyper master from git and use rusttls' server example because they have massively changed how things #work.
If ECDSA certs and defining a curve lists work I will close this issue. Have to test first.

HTTP/2 server support

I'm looking to serve HTTP/1.1 and HTTP/2 over TLS behind the same port with ALPN. Is that within scope for this crate or as an example in this crate?

server example error handling is incorrect + documentation is insufficient

steps to reproduce:

first, verify the server example works:

$ cargo run --example server
Starting to serve on https://127.0.0.1:1337.

$ curl -X POST --data "POST-it note" https://127.0.0.1:1337/echo --insecure
POST-it note

so far so good! lets try curling with http to see if the server gracefully drops the packet


$ curl -X POST --data "POST-it note" http://127.0.0.1:1337/echo 
curl: (52) Empty reply from server

that part seems right, but wait! my server has crashed!

[!] Voluntary server halt due to client-connection error...
FAILED: error accepting connection: TLS Error: Custom { kind: InvalidData, error: CorruptMessage }

ok - lets look at the example code. it seems to say that i can uncomment the error and just return Ok(None) and that should take care of things: uncomment this line and comment this line so it looks like this:


let incoming_tls_stream = tcp
  .incoming()
  .map_err(|e| error(format!("Incoming failed: {:?}", e)))
  .and_then(move |s| {
    tls_acceptor.accept(s).map_err(|e| Ok(None))
  })
  .boxed();

unfortunately when i run the server it fails to compile with a rather verbose error message:

$ cargo run --example server
   Compiling hyper-rustls v0.21.0 (/Users/averyharnish/Documents/work/hyper-rustls)
error[E0271]: type mismatch resolving `<[closure@examples/server.rs:67:44: 72:14] as std::ops::FnOnce<(std::io::Error,)>>::Output == std::io::Error`
  --> examples/server.rs:66:10
   |
66 |         .and_then(move |s| {
   |          ^^^^^^^^ expected enum `std::result::Result`, found struct `std::io::Error`
   |
   = note: expected enum `std::result::Result<std::option::Option<_>, _>`
            found struct `std::io::Error`
   = note: required because of the requirements on the impl of `futures_util::fns::FnOnce1<std::io::Error>` for `[closure@examples/server.rs:67:44: 72:14]`
   = note: required because of the requirements on the impl of `std::future::Future` for `futures_util::future::future::map::Map<futures_util::future::try_future::into_future::IntoFuture<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>>, futures_util::fns::MapErrFn<[closure@examples/server.rs:67:44: 72:14]>>`
   = note: required because of the requirements on the impl of `futures_core::future::TryFuture` for `futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>`

error[E0599]: no method named `boxed` found for struct `futures_util::stream::try_stream::and_then::AndThen<futures_util::stream::try_stream::MapErr<tokio::net::tcp::incoming::Incoming<'_>, [closure@examples/server.rs:65:18: 65:64]>, futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>, [closure@examples/server.rs:66:19: 73:10 tls_acceptor:_]>` in the current scope
  --> examples/server.rs:74:10
   |
74 |         .boxed();
   |          ^^^^^ method not found in `futures_util::stream::try_stream::and_then::AndThen<futures_util::stream::try_stream::MapErr<tokio::net::tcp::incoming::Incoming<'_>, [closure@examples/server.rs:65:18: 65:64]>, futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>, [closure@examples/server.rs:66:19: 73:10 tls_acceptor:_]>`
   | 
  ::: /Users/averyharnish/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.5/src/stream/try_stream/and_then.rs:13:1
   |
13 | pub struct AndThen<St, Fut, F> {
   | ------------------------------
   | |
   | doesn't satisfy `_: futures_core::stream::Stream`
   | doesn't satisfy `_: futures_util::stream::stream::StreamExt`
   |
   = note: the method `boxed` exists but the following trait bounds were not satisfied:
           `futures_util::stream::try_stream::and_then::AndThen<futures_util::stream::try_stream::MapErr<tokio::net::tcp::incoming::Incoming<'_>, [closure@examples/server.rs:65:18: 65:64]>, futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>, [closure@examples/server.rs:66:19: 73:10 tls_acceptor:_]>: futures_core::stream::Stream`
           which is required by `futures_util::stream::try_stream::and_then::AndThen<futures_util::stream::try_stream::MapErr<tokio::net::tcp::incoming::Incoming<'_>, [closure@examples/server.rs:65:18: 65:64]>, futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>, [closure@examples/server.rs:66:19: 73:10 tls_acceptor:_]>: futures_util::stream::stream::StreamExt`
           `&futures_util::stream::try_stream::and_then::AndThen<futures_util::stream::try_stream::MapErr<tokio::net::tcp::incoming::Incoming<'_>, [closure@examples/server.rs:65:18: 65:64]>, futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>, [closure@examples/server.rs:66:19: 73:10 tls_acceptor:_]>: futures_core::stream::Stream`
           which is required by `&futures_util::stream::try_stream::and_then::AndThen<futures_util::stream::try_stream::MapErr<tokio::net::tcp::incoming::Incoming<'_>, [closure@examples/server.rs:65:18: 65:64]>, futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>, [closure@examples/server.rs:66:19: 73:10 tls_acceptor:_]>: futures_util::stream::stream::StreamExt`
           `&mut futures_util::stream::try_stream::and_then::AndThen<futures_util::stream::try_stream::MapErr<tokio::net::tcp::incoming::Incoming<'_>, [closure@examples/server.rs:65:18: 65:64]>, futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>, [closure@examples/server.rs:66:19: 73:10 tls_acceptor:_]>: futures_core::stream::Stream`
           which is required by `&mut futures_util::stream::try_stream::and_then::AndThen<futures_util::stream::try_stream::MapErr<tokio::net::tcp::incoming::Incoming<'_>, [closure@examples/server.rs:65:18: 65:64]>, futures_util::future::try_future::MapErr<tokio_rustls::Accept<tokio::net::tcp::stream::TcpStream>, [closure@examples/server.rs:67:44: 72:14]>, [closure@examples/server.rs:66:19: 73:10 tls_acceptor:_]>: futures_util::stream::stream::StreamExt`

warning: unused import: `StreamExt`
  --> examples/server.rs:10:22
   |
10 |     stream::{Stream, StreamExt, TryStreamExt},
   |                      ^^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

error: aborting due to 2 previous errors; 1 warning emitted

Some errors have detailed explanations: E0271, E0599.
For more information about an error, try `rustc --explain E0271`.
error: could not compile `hyper-rustls`.

To learn more, run the command again with --verbose.

I tried looking into the documentation and I found into_failable which seems like maybe something that could be useful to me? But really I'm not sure where to go from here. Any help with this is greatly appreciated and I'd be happy to update the server example with something that works once I understand what's going on.

Dependabot couldn't find a Cargo.toml for this project

Dependabot couldn't find a Cargo.toml for this project.

Dependabot requires a Cargo.toml to evaluate your project's current Rust dependencies. It had expected to find one at the path: /tokio-rustls/Cargo.toml.

If this isn't a Rust project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

Semantic error

In the file lib. rs ,Lines 73 to 80 :

fn promote_tls_error(&mut self) -> io::Result<()> {
    match self.tls_error.take() {
      Some(err) => {
        return Err(io::Error::new(io::ErrorKind::ConnectionAborted, err));
      },
      None => return Ok(())
    };
  }

is that correct? Should remove the ';'?

Why is HTTP2 not the default?

It seems like neither the client nor the server use HTTP2 by default. The server example recently got updated to manually allow HTTP2, but the client example still only uses HTTP1.1. Which begs the question why you even need to do this manually in the first place. I feel like either there should be some helper in the HttpsConnector .with_http2() or it should just be the default. I may be misunderstanding something though.

So hyper-rustls doesn't do ALPN by default and hyper-tls doesn't do ALPN at all. I'm so confused.

Is async-std within the scope of this crate?

It seems to be possible to use hyper with async-std if you provide a Connector for it that uses async-std. Considering half the ecosystem is seemingly moving to async-std and tokio doesn't play well with async-std, there should probably be a good rustls based Connector that can be used in that case. I'm not sure if that is within the scope of hyper-rustls or if we need a second hyper-rustls-async-std.

Can I get the CN?

With an older version of Hyper using OpenSSL I could do something like this:

 if let Some(sslstream) = request.ssl::<SslStream<HttpStream>>() {
            let ssl: &Ssl = sslstream.ssl();
            let peer_x509: X509 = ssl.peer_certificate().unwrap();
            let sn = peer_x509.subject_name();
            cn = sn.text_by_nid(Nid::CN).unwrap();
            debug!("cn: {}", &cn);
        }

I need the CN to do anything useful on our corporate network.
Is it possible to do something like this when I'm using hyper-rustls?
If yes, how?

Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.