I am trying to parse the HTML response I get from hyper request, but in the example, the response is written to stdout.
I'm new to rust and don't know how can I write the response to a string to manupulate it.

This might just be my inability to search through this code properly, but I'll just ask. Does this support using custom root certificates?

I recently found that the reqwest library was fetching anything with an unrecognized scheme (like hxxps: or htps: as plain HTTP: seanmonstar/reqwest#919. That was fixed in seanmonstar/reqwest#921.

This crate appears to have the same problem: Because it calls http.enforce_http(false) (

error:

.connector(::hyper_tls::HttpsConnector::new(4, &core.handle()))
^^^^^^^^^ expected struct `hyper::uri::Uri`, found struct `hyper::Uri`

repo to reproduce this error:

https://github.com/king6cong/tls-test

Funny thing is it will be ok to use:

hyper = { git = "https://github.com/hyperium/hyper" }
hyper-tls = { git = "https://github.com/hyperium/hyper-tls" }

but error occurs:

hyper = { git = "https://github.com/hyperium/hyper", rev = "3da720a99fab9cf6ecf8a206bb22c826ebb74992" }
hyper-tls = { git = "https://github.com/hyperium/hyper-tls", rev = "74aefbe500df5bb2d9a87844580b4ac21d49f134" }

while master rev should be equal to the specified rev at this moment.

Some questions:

1. Will same type of different paths cause problems like this?
2. What is the difference between With rev specified or without rev specified when rev chosen should be the same anyway. (I check Cargo.lock)

I'm using Hyper + Hyper-TLS with the Daemonize crate to make the following HTTPS call from within a Daemon my subprocess runs. Interestingly, if I make a HTTP call things work fine and the request gets POST'ed to my server. However, if I change the BASE_URL to be HTTPS, then I get the following error printed out:

Error {
    kind: Connect,
    cause: Custom {
        kind: Other,
        error: Error {
            code: -909

I can't find any documentation as to what this might be. Also what's disturbing is that after I print this error, no other print statements are executed because the process seems to have died. Any help would be appreciated. Code using hyper/hyper-tls is below.

    let url: hyper::Uri = format!("{}/logs/new", BASE_URL).parse().unwrap();
    let https_connector = HttpsConnector::new(4).unwrap();
    let client = Client::builder().build(https_connector);
    let method = hyper::Method::POST;
    let mut headers = HeaderMap::new();

    let json_payload = json!({
        "jobName": job_name,
        "line": line,
    });

    let mut req = Request::new(Body::from(json_payload.to_string()));

    headers.insert("x-access-token", HeaderValue::from_str(&token).unwrap());
    headers.insert(
        hyper::header::CONTENT_TYPE,
        HeaderValue::from_static("application/json")
    );

    *req.method_mut() = method;
    *req.uri_mut() = url;
    *req.headers_mut() = headers;

    client.request(req).and_then(|res| {
        Ok(res.status())
    }).from_err::<kraken_utils::FetchError>().from_err()

let mut https_connector = ::hyper_tls::HttpsConnector::new(4, &core.handle()).unwrap();
https_connector.danger_disable_hostname_verification(true);
let client = ::hyper::Client::configure()
    .connector(https_connector)
    .build(&core.handle());

my Cargo.toml contains

hyper = "0.11"
hyper-tls = "0.1.2"

If I try to use this client to connect to https://in-house-server-with-dubious-self-signed-cert/yadda/yadda, I get

Io(Error { repr: Custom(Custom { kind: Other, error: Error { repr: Os { code: -2146762487, message: "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider." } } }) })

Just in case, I tried calling danger_disable_hostname_verification(false) but that didn't change anything.

Am I missing something? Is the intent of danger_disable_hostname_verification actually to ignore the certificate/trust process, or is it some other part of the SSL process that I'm misunderstanding?

Hi, what would be the best approach to automatically reload certificates on a running server/client? The use case is for environments where certs are refreshed pretty frequently -- once a day.

For example, in Golang, when configuring TLS is as possible to provide callbacks which are called when certificate is needed. See GetCertificate, GetClientCertificate https://golang.org/pkg/crypto/tls/#Config.

Have you considered switching to use tokio_native_tls rather than tokio_tls for your TlsStream? I'm not sure why tokio has too, seemingly similar, implementations but tokio_native_tls has the advantage for me that it allows you to get the peer_certificate from the underlying native_tls stream.

Now that hyper's master branch supports std::future, it would be very useful to have hyper-tls support std::future as well.

Hi @seanmonstar, are you planning to make a new release anytime soon? We plan to use the 'vendored' feature added here and it is not currently published on crates.io.

I have compiled a simple rust program with hyper-tls crate. But it is not working. Without hyper-tls it is working.

Steps to reproduce

1. Create a project with below dependencies

# Cargo.toml
[package]
name = "musltest"
version = "0.1.0"
edition = "2018"

[dependencies]
hyper = "0.13.2"
hyper-tls = "0.4.1"

// main.rs
use hyper::Client;
use hyper_tls::HttpsConnector;

fn main (){

    let https = HttpsConnector::new();
    let client = Client::builder().build::<_, hyper::Body>(https);
    println!("Hello world!")
}

2. Run below commands

[whizsid@archlinux musltest]$ export OPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0
[whizsid@archlinux musltest]$ export OPENSSL_LIB_DIR=/usr/lib/openssl-1.0
[whizsid@archlinux musltest]$ export OPENSSL_DIR=/etc/ssl
[whizsid@archlinux musltest]$ cargo build --target x86_64-unknown-linux-musl
warning: unused variable: `client`
 --> src/main.rs:7:9
  |
7 |     let client = Client::builder().build::<_, hyper::Body>(https);
  |         ^^^^^^ help: consider prefixing with an underscore: `_client`
  |
  = note: `#[warn(unused_variables)]` on by default
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
[whizsid@archlinux musltest]$ docker run -itd --rm -v $PWD:/data --name=musltest alpine
e60df22d416c085eb5d491bc8de6256651958d24d50752caafadf5e484f22ba6
[whizsid@archlinux musltest]$ docker exec -it musltest /data/target/x86_64-unknown-linux-musl/debug/musltest
OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "no such file or directory": unknown

Is this an error of rust-openssl?

It took me a pretty long time to follow all the type signatures around and construct a valid client. I first tried searching the issue tracker for people having trouble, but didn't seem to find one. Anyway, here is what I came up with for the next person:

use hyper::Client;
use native_tls::Certificate;
use std::path::Path;

fn load_ca_cert(pem_file: &Path) -> Result<Certificate, CertLoadError> {
    use std::fs;

    let bytes =
        fs::read(pem_file).map_err(|e| CertLoadError::Io(format!("Loading {:?}", pem_file), e))?;

    Certificate::from_pem(&bytes).map_err(CertLoadError::TlsError)
}

#[derive(Debug)]
enum CertLoadError {
    TlsError(native_tls::Error),
    Io(String, std::io::Error),
}

fn main() {
    let certificate: native_tls::Certificate =
        load_ca_cert(&Path::new("/path/to/cert.pem")).expect("Failed to load your CA cert");

    let native_tls_connector = native_tls::TlsConnector::builder()
        .add_root_certificate(certificate)
        .build()
        .expect("Building native_tls::TlsConnector");

    let tokio_tls_tls_connector = tokio_tls::TlsConnector::from(native_tls_connector);


    let mut hyper_http_connector = hyper::client::HttpConnector::new();
    hyper_http_connector.enforce_http(false);
 
    let hyper_tls_https_connector = hyper_tls::HttpsConnector::from((
        hyper_http_connector,
        tokio_tls_tls_connector,
    ));

    let client_main = Client::builder().build::<_, hyper::Body>(hyper_tls_https_connector);

    drop(client_main);
}

Hey,

This commit exports native-tls errors which I think is a major improvement and should therefore be published on crates.io!

See also: sfackler/hyper-native-tls#5

Disclaimer: I didn’t look at the code from this crate for too long.

This crate appears to be pretty much the most hands free way to get https support with hyper. However, a caveat is that this does not do any protocol negotiation and thus hyper is forced to always use http1.1.

I think it should, by default, do most of this kind of setup for the user without any additional effort on the user end.

Hi! I was hanging out in office hours and I asked a question about the state of hyper-tls and if there were plans to retire it. There are a few other better tls implementations that we could direct folks to instead in documentation. @seanmonstar Pointed out making an issue to start this discussion might be a good idea.

Example:

• https://crates.io/crates/tokio-rustls

I tried using this library to connect to a websocket server with TLS, which uses wss as a scheme. As the scheme is not https it is falling back to a regular http connection and then failing because it is actually https. It seems impossible to connect to a websocket server with the wss scheme with this connector unfortunately.

For now I've made my own copy of the HttpsConnector<T> which works for this use case, but I feel like there should be a connector here which will allow this. Perhaps a ForceHttpsConnector<T> or something, which will just presume that the connection is https and then error later down the line if it turns out that it actually isn't rather than trying to fail early.

Alternatively, include wss in the check for is_https, but that feels comparatively short sighted.

Since today I'm getting the following compilation error when compiling hyper v0.13.0-alpha.1 with tokio master:

error[E0277]: the trait bound `<T as hyper::client::connect::Connect>::Transport: tokio_io::async_read::AsyncRead` is not satisfied
   --> C:\Users\pim\.cargo\registry\src\github.com-1ecc6299db9ec823\hyper-tls-0.4.0-alpha.1\src\client.rs:109:22
    |
109 |                     .connect(&host, tcp)
    |                      ^^^^^^^ the trait `tokio_io::async_read::AsyncRead` is not implemented for `<T as hyper::client::connect::Connect>::Transport`
    |
    = help: consider adding a `where <T as hyper::client::connect::Connect>::Transport: tokio_io::async_read::AsyncRead` bound

Connecting to URLs like https://[2606:4700:4700::1111]/ fails due to the hostname verification (SNI). This library passes the host() returned by the URI package here, but the value returned for this URL is [2606:4700:4700::1111]/.

This fails TLS hostname verification because not only do the brackets have to be removed, but the IPv6 literal also has to observe specific rules regarding zero compression and suppression. spec

In this case the correct name to pass to the TLS library would be 2606:4700:4700:0:0:0:0:1111.

Hi,
Is it possible use hyper-tls for hyper server "0.12" ?

Please release a upgraded version depending on tokio:0.3

Blocked by:

• hyper & h2

Do you have a working example of using a Self Signed Certificate with hyper-tls

I have tried several ways to do it but not succeeded.

Thanks

The recent PR to Hyper has caused a breaking change that makes this not work with the code from that commit onwards. It seems like the only thing needed to get hyper-tls working again is for it to implement the AsyncRead and AsyncWrite traits from tokio_io. This will allow it to work as a connector again for Hyper.

rust-analyzer failed to load workspace: Failed to read Cargo metadata from Cargo.toml file Cargo.toml, cargo 1.61.0 (a028ae42f 2022-04-29): Failed to run "cargo" "metadata" "--format-version" "1" "--manifest-path" "Cargo.toml" "--filter-platform" "x86_64-apple-darwin": cargo metadata exited with an error: Updating crates.io index
error: failed to select a version for hyper.
... required by package hyper-tls v0.5.0
... which satisfies dependency hyper-tls = "^0.5.0" (locked to 0.5.0) of package ``
versions that meet the requirements ^0.14.2 (locked to 0.14.18) are: 0.14.18

all possible versions conflict with previously selected packages.

previously selected package hyper v0.14.19

failed to select a version for hyper which could resolve this conflict

Given that hyper is moving off of tokio-core to tokio, we should probably think about changing the HttpsConnector::new(...) method to follow a similar pattern that does not require a tokio_core::reactor::Handle as a parameter particularly because HttpConnector on hyper's master branch has removed this requirement. I'm going to work on a PR for this. Let me know if there are any considerations I've missed with this switch.

https://rustsec.org/advisories/RUSTSEC-2023-0018.html

│   ├── hyper-tls v0.5.0
│   │   ├── bytes v1.2.1
│   │   ├── hyper v0.14.20 (*)
│   │   ├── native-tls v0.2.10
│   │   │   ├── lazy_static v1.4.0
│   │   │   ├── libc v0.2.132
│   │   │   ├── security-framework v2.7.0
│   │   │   │   ├── bitflags v1.3.2
│   │   │   │   ├── core-foundation v0.9.3
│   │   │   │   │   ├── core-foundation-sys v0.8.3
│   │   │   │   │   └── libc v0.2.132
│   │   │   │   ├── core-foundation-sys v0.8.3
│   │   │   │   ├── libc v0.2.132
│   │   │   │   └── security-framework-sys v2.6.1
│   │   │   │       ├── core-foundation-sys v0.8.3
│   │   │   │       └── libc v0.2.132
│   │   │   ├── security-framework-sys v2.6.1 (*)
│   │   │   └── tempfile v3.3.0
│   │   │       ├── cfg-if v1.0.0
│   │   │       ├── fastrand v1.8.0
│   │   │       ├── libc v0.2.132
│   │   │       └── remove_dir_all v0.5.3

So I get that this library is intended to be generic as pertains to TLS, but the way this is implemented I can't control anything in a TLS builder pattern.

With the native-tls rust crate, for example, I see that I need to set some boolean's in the builder struct in order to disable certificate and hostname validation. The native-tls TlsConnectorBuilder's methods include public setters for those booleans, but that's only usable during the builder pattern. I don't know how I would disable TLS validation after the connector is built, and I'd imagine it's different depending on what library is managing TLS in that particular instance. I get that none of that is hyper-tls's problem, and I agree.

But, and I'm a total rust newbie so maybe I'm just wrong here, shouldn't this library (which treats TLS generically) allow the caller to create the TLS object, and then pass that to HttpsConnector::new() ?

Are you already doing that somehow and I just missed it? If not, and you think that's probably how things should be done™ then I wouldn't mind submitting a pull request with the suggested changes.

Hi,
I tried to implement automatically choose connector based on given scheme.
I tried.

  let client = match uri.scheme().unwrap(){
    "https" =>::hyper::Client::configure()
        .connector(::hyper_tls::HttpsConnector::new(4, &core.handle()).unwrap())
        .build(&core.handle()),
    _ =>  Client::new(&core.handle())
  };

but get

error[E0308]: match arms have incompatible types
  --> src\client.rs:50:16
   |
50 |     let client = match  uri.scheme().unwrap(){
   |  ________________^
51 | |     "https" =>::hyper::Client::configure()
52 | |         .connector(::hyper_tls::HttpsConnector::new(4, &core.handle()).unwrap())
53 | |         .build(&core.handle()),
54 | |     _ =>  Client::new(&core.handle())
   | |           --------------------------- match arm with an incompatible type
55 | |   };
   | |___^ expected struct `hyper_tls::HttpsConnector`, found struct `hyper::client::HttpConnector`
   |
   = note: expected type `hyper::Client<hyper_tls::HttpsConnector<hyper::client::HttpConnector>, _>`
              found type `hyper::Client<hyper::client::HttpConnector, _>`

is that possible to get a compatible type?

The link to the documentation in the README leads to an empty overview. I suggest to not put the link there (and not publish the crate as 0.0.0), until there's some basic documentation.

I'm trying to use error_chain with the following code:

let connector = HttpsConnector::new(4, handle)?;

Which gives me the following error:

the trait std::convert::From<native_tls::Error> is not implemented for errors::Error

So to be able to add native_tls::Error as a foreign_link in error_chain, I'll have to add native_tls as an additional dependency for my project? Should this error be exported by hyper-tls somehow?

i see this crate was released an hour ago - seems to have broken my crates relying on reqwest.

see seanmonstar/reqwest#971 for report on reqwest crate

more specifically - it looks like std::convert::From<(connect::HttpConnector, tokio_tls::TlsConnector)> is no longer implemented (i think this commit) which is causing this issue

The latest hyper-tls-0.3.1 release has .cargo_vcs_info.json with:

{
  "git": {
    "sha1": "3d1f412d171cd8d9a5efc9396c85ef084a9ef4bd"
  }
}

...but commit 3d1f412 isn't found here. Current master is dc8a134. Forgot to push it?

Trivy scans my project and finds a CVE. When I look at it, the dependency comes in from reqwest which in turn uses hyper-tls that has the dependency. In hyper-tls, the Cargo.toml specifies version ^1 so I guess a simple update and rebuild would include a higher Tokio version that isn't affected by the CVE. I would contribute this as a PR but it seems to me (a Rust noob) that there is no coding involved.

packages/myproject/Cargo.lock (cargo)

Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 0)

┌─────────┬────────────────┬──────────┬───────────────────┬────────────────────────┬───────────────────────────────────────────────────────────┐
│ Library │ Vulnerability  │ Severity │ Installed Version │     Fixed Version      │                           Title                           │
├─────────┼────────────────┼──────────┼───────────────────┼────────────────────────┼───────────────────────────────────────────────────────────┤
│ tokio   │ CVE-2023-22466 │ MEDIUM   │ 1.22.0            │ 1.23.1, 1.20.3, 1.18.4 │ Tokio reject_remote_clients configuration may get dropped │
│         │                │          │                   │                        │ when creating a Windows named pipe...                     │
│         │                │          │                   │                        │ https://avd.aquasec.com/nvd/cve-2023-22466                │
└─────────┴────────────────┴──────────┴───────────────────┴────────────────────────┴───────────────────────────────────────────────────────────┘

Hyper has been updated with =0.2.0.alpha.4. Requires a release of tokio-tls: tokio-rs/tokio#1515

Could it be possible to reuse the TCP connection across multiple requests?

Hello~
I would like to set the self signed certificate to client and connect.
If you look at the impl, you can set the TlsConnector created through from.
However, when I try the direct implementation, it fails and throws an error because the trait bounds don't match.
Can't it be set using the hyper_tls::native_tls::TlsConnector build?

use hyper::{client::HttpConnector, Client};

use hyper_tls::{
    native_tls::{Certificate, TlsConnector},
    HttpsConnector,
};

fn main() {
    let mut tls_connector_builder = TlsConnector::builder();
    const SELF_SIGNED_CERT: &[u8] = include_bytes!(
        "./data/self_signed_certs/public.crt"
    );
    let certificate = Certificate::from_pem(SELF_SIGNED_CERT).unwrap();
    tls_connector_builder.add_root_certificate(certificate);
    tls_connector_builder.danger_accept_invalid_hostnames(true);
    let mut tls_connector = tls_connector_builder.build().unwrap();

    let httpss = HttpsConnector::new();
    let mut http = HttpConnector::new();
    http.enforce_http(false);

    let https = HttpsConnector::<HttpConnector>::from((http, tls_connector));
    let client = Client::builder().build::<_, hyper::Body>(https);
}

HttpConnector has the set_keepalive method, but not HttpsConnector.

https://docs.rs/hyper/latest/hyper/client/connect/struct.HttpConnector.html#method.set_keepalive

I tried to use reqwest for making https requests, which means a transitive dependency on hyper, and then this lib for TLS. However despite reqwest's and hyper's tokio dep being optional (I think?), this library appears to unconditionally depend on tokio with default features.

Unfortunately tokio with default features compiles to a binary so big, it will not fit on my embedded device. This is unfortunate, since without it (and using a simpler executor), everything else is pretty lightweight.

I haven't dug very deep into it, but a cursory look suggests that the tokio dependency could be removed or feature gated. Would this be possible?

It looks like HttpsConnector internally goes through a TlsConnector builder, but doesn't expose it to library users. I was looking into how to tell hyper-tls about custom CA and cert-chains, and it seems that it is not currently possible without having access to the chain of builders up to TlsConnectorBuilderExt.builder_mut(). If so, I'd like to have some builder-pattern or similar method to tweak such details.

I'm still not very familiar with this crate, so pardon me if I missed some already existing details.

Why use BoxError in the HttpsConnector if an enum would work and won't be too complicated?

In my current code, I can't just use ? or .into on the error cause it's not Sized, and, although I can work around it pretty easily, I see no reason why we shouldn't use enum.

IMHO, having this crate separated out from hyper doesn't really accomplish too much other than adding additional time and effort to basic usage. Defaulting to https support, but allowing a user to opt out, would seem to be a far more logical (and secure) pattern.

1. if someone wants to use different connectors, they would certainly still be able to, and perhaps that is when they would opt out of the "https" feature.
2. adoption of hyper would be faster and easier. E.G., I found out that I needed a different support crate for Hyper TLS when using the client and it failed saying that only http was supported.
   I know that there is info on the website, but I did not see it in the docs, and I didn't read the website until later.
3. batteries included seems to be a big part of rust. HTTPS isn't even a battery though. It is standard these days.

All in all, thank you @seanmonstar and everyone else who has contributed to the Hyper ecosystem. It is certainly foundational to the Rust web ecosystem. I hope my feedback here is constructive and valuable.

Hey,

I'm wondering if it is possible to obtain details of the SSL certificate returned by the server when using Hyper as an HTTPS client? I've got this example:

#![deny(warnings)]
#![warn(rust_2018_idioms)]
use std::{env};

use hyper::{Client};
use hyper_tls::HttpsConnector;

// A simple type alias so as to DRY.
type Result<T> = std::result::Result<T, Box<dyn std::error::Error + Send + Sync>>;

#[tokio::main]
async fn main() -> Result<()> {
    pretty_env_logger::init();

    // Some simple CLI args requirements...
    let url = match env::args().nth(1) {
        Some(url) => url,
        None => {
            println!("Usage: client <url>");
            return Ok(());
        }
    };

    // HTTPS requires picking a TLS implementation, so give a better
    // warning if the user tries to request an 'https' URL.
    let url = url.parse::<hyper::Uri>().unwrap();
    

    fetch_url(url).await
}

async fn fetch_url(url: hyper::Uri) -> Result<()> {
    let https = HttpsConnector::new();
    let client = Client::builder().build::<_, hyper::Body>(https);

    let res = client.get(url).await?;

    println!("Response: {}", res.status());
    println!("Headers: {:#?}\n", res.headers());

    println!("Extensions: {:#?}\n", res.extensions().len());

    // Stream the body, writing each chunk to stdout as we get it
    // (instead of buffering and printing at the end).
    // while let Some(next) = res.data().await {
    //     let chunk = next?;
    //     io::stdout().write_all(&chunk).await?;
    // }

    println!("\n\nDone!");

    Ok(())
}

And I'm wondering how can I use the https object or the response object to get the details of the server certificate?

I tried following the code, and it seems that the cert value is not exposed in the public API of this package, but I thought I'd ask.

Thanks in advance for your help!

Hi,

I have issues when using hyper-tls in Android, getting certificate verify failed errors:

Error("Io(Error { repr: Custom(Custom { kind: Other, error: Ssl(ErrorStack([Error { code: 336134278, library: "SSL routines", function: "ssl3_get_server_certificate", reason: "certificate verify failed", file: "s3_clnt.c", line: 1269 }])) }) })"))

Searching around I found these discussions but it seems that the PRs mentioned are not accepted and I cannot find some workaround...

So, I would like to ask, what is the proper way to use hyper_tls in Android?

Now that tokio-tls has been renamed to tokio-native-tls, maybe also rename this crate?

Currently hyper-tls will fall back to using HTTP if the URL passed to the connect function is not using the HTTPS scheme, this is probably not what people expect and it's not mentioned in the documentation anywhere as far as i can see. It might be worth erroring out if the URL scheme is not HTTPS by default in order to prevent people from unintentionally sending data in the clear when, for example, they don't control the URL passed into their application.

This would however be an API breaking change and i'm not sure if that is acceptable for the project right now. At the very least it would be nice to have an optional flag that forces the use of HTTPS, as well as mentioning this behaviour in the documentation so developers are aware of hyper-tls's default behaviour in situations where a URL using the HTTP scheme is used.

A cargo audit reveals the following vulnerabilities for the latest hyper-tls 0.5.0

I've opened an issue on native-tls which will need to be resolved first - see sfackler/rust-native-tls#257

Dependency tree:
openssl 0.10.45
└── native-tls 0.2.11
├── hyper-tls 0.5.0

Crate: openssl
Version: 0.10.45
Title: openssl SubjectAlternativeName and ExtendedKeyUsage::other allow arbitrary file read
Date: 2023-03-24
ID: RUSTSEC-2023-0023
URL: https://rustsec.org/advisories/RUSTSEC-2023-0023
Solution: Upgrade to >=0.10.48

Crate: openssl
Version: 0.10.45
Title: openssl X509NameBuilder::build returned object is not thread safe
Date: 2023-03-24
ID: RUSTSEC-2023-0022
URL: https://rustsec.org/advisories/RUSTSEC-2023-0022
Solution: Upgrade to >=0.10.48

Crate: openssl
Version: 0.10.45
Title: openssl X509Extension::new and X509Extension::new_nid null pointer dereference
Date: 2023-03-24
ID: RUSTSEC-2023-0024
URL: https://rustsec.org/advisories/RUSTSEC-2023-0024
Solution: Upgrade to >=0.10.48

I am new to GitHub and I hope that I do this here is correct?
I currently tracking down a very strange issue with HTTPS-Client requests on MACOS.

I am using Warp and Hyper-Client to create a Webserver and another Backend-Application calling that Webservers interface.
Actually, everything works well, on windows, and linux, even on macos.

But as soon as I execute a HTTPS-Call from within my application running on MacOS to any other Operating System it failes with the error error trying to connect: decoding error
The Error looks quite similar to this one here

Noticeable Things so far:

• If I use localhost to connect to my application running on the same Mac it works well!
• If I use <local-ip> instead, I get the error.
• No matter what I do, adding Root Cert to the HTTPSHandler, to MACOS or disableing all cert checks (danger_accept_invalid_hostnames(true).danger.accept_invalid_certs(true)) the error remains.
• Calls from Safari and Chrome on the same MacOS as well as other devices to my Application working well and are secured (Certificates are valid (even in MacOS))
• A Call with the same client configuration to some public web page, like https://google.de works well. Also local Webservers with HTTP (without S) can be called without any problem.

I would be very grateful for any thought or idea how to proceed ... in hope that I did not discover a hidden but somewhere inside some library...

thanks in advance!

Hello,

I am trying to POST a streamed payload to an HTTPS endpoint, while everything is fine for HTTP, in HTTPS the event loop seems to deadlock :/

Running the following code produce
https://gist.github.com/d33d33/2fb4b264ecdb4a4d787925f993295929

POLL 0
POLL 1
POLL 2

and wait forever, while running it with an HttpConnector produce

POLL 0
POLL 1
POLL 2
POLL 3
POLL 4
DONE
Response: 200 OK

Hey just curious question on HttpsConnector struct there is mut method danger_disable_hostname_verification which trusts any valid certificate for any site.

Question is why on some sites this fails?

extern crate futures;
extern crate hyper;
extern crate hyper_tls;
extern crate tokio;

use futures::{future, Future, Stream};
use std::io::Write;

fn main() {
    tokio::run(future::lazy(|| {
        let mut https = hyper_tls::HttpsConnector::new(4).unwrap();
        https.danger_disable_hostname_verification(true);

        let client = hyper::Client::builder().build::<_, hyper::Body>(https);

        client
            .get("https://httpbin.org/".parse().unwrap())
            .and_then(|res| {
                println!("Status: {}", res.status());
                println!("Headers:\n{:#?}", res.headers());
                res.into_body().for_each(|chunk| {
                    ::std::io::stdout()
                        .write_all(&chunk)
                        .map_err(|e| panic!("example expects stdout to work: {}", e))
                })
            })
            .map_err(|e| println!("request error: {}", e))
    }));
}

$ cargo run --example client
   Compiling hyper-tls v0.2.0-a.0 (file:///home/ow/dev/rust/hyper-tls)
    Finished dev [unoptimized + debuginfo] target(s) in 3.90 secs
     Running `target/debug/examples/client`
request error: an error occurred trying to connect: The OpenSSL library reported an error: error:14094438:
SSL routines:ssl3_read_bytes:tlsv1 alert internal error:ssl/record/rec_layer_s3.c:1407:SSL alert number 80