Option to Relax SNI Host Name Validation for IP Addresses about rustls

[ctz]

• On my macOS Sonoma machine, the system curl identifies as libcurl/8.4.0 (SecureTransport) LibreSSL/3.3.6

So LibreSSL 3.5.0 introduced a change that correctly avoids sending an invalid SNI extension; Apple seems to be significantly behind the upstream LibreSSL though. @chris-wood any thoughts?

[djc]

To unpack this a little bit:

• isahc (no commits in the last 2 years) is effectively a curl wrapper, so we should expect it to have the same results
• I think curl will use OpenSSL as the TLS stack in the default configuration?
• On my macOS Sonoma machine, the system curl identifies as libcurl/8.4.0 (SecureTransport) LibreSSL/3.3.6
• reqwest defaults to native-tls, which I think would pick OpenSSL on Linux and SecureTransport on macOS

[ctz]

We previously reported that to Apple in 2018

This was #203

[ctz]

Thanks for the reproducer. For me all the test cases work as expected, in the sense that none of them demonstrate a client that is rejected by rustls:

running 3 tests
thread 'tests::test_with_isahc' panicked at src/lib.rs:14:9:
we will not get here
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tests::test_with_isahc' panicked at src/lib.rs:55:59:
called `Result::unwrap()` on an `Err` value: Error { kind: ConnectionFailed, context: None, source: Some(Error { description: "SSL connect error", code: 35, extra: None }), source_type: Some("curl::error::Error"), local_addr: Some(127.0.0.1:43942), remote_addr: Some(127.0.0.1:65432) }
test tests::test_with_isahc - should panic ... ok
thread 'tests::test_with_reqwest' panicked at src/lib.rs:14:9:
we will not get here
thread 'tests::test_with_curl' panicked at src/lib.rs:14:9:
we will not get here
thread 'tokio-runtime-worker' panicked at src/lib.rs:70:28:
called `Result::unwrap()` on an `Err` value: Error { description: "SSL connect error", code: 35, extra: Some("OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 127.0.0.1:65433 ") }
thread 'tests::test_with_reqwest' panicked at src/lib.rs:42:55:
called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Ipv4(127.0.0.1)), port: Some(65431), path: "/", query: None, fragment: None }, source: hyper::Error(Connect, Ssl(Error { code: ErrorCode(5), cause: None }, X509VerifyResult { code: 0, error: "ok" })) }
thread 'tests::test_with_curl' panicked at src/lib.rs:71:18:
called `Result::unwrap()` on an `Err` value: JoinError::Panic(Id(4), ...)
test tests::test_with_reqwest - should panic ... FAILED
test tests::test_with_curl - should panic ... ok

failures:

---- tests::test_with_reqwest stdout ----
note: panic did not contain expected string
      panic message: `"called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Request, url: Url { scheme: \"https\", cannot_be_a_base: false, username: \"\", password: None, host: Some(Ipv4(127.0.0.1)), port: Some(65431), path: \"/\", query: None, fragment: None }, source: hyper::Error(Connect, Ssl(Error { code: ErrorCode(5), cause: None }, X509VerifyResult { code: 0, error: \"ok\" })) }"`,
 expected substring: `"decoding error"`

failures:
    tests::test_with_reqwest

test result: FAILED. 2 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.07s

(I think the we will not get here panics all point to the rustls-based server seeing a valid clienthello, and this panic happens after that.)

This was on Debian 12.5.

It is possible that other platforms have a different behaviour: certainly curl+openssl and reqwest+openssl are known to work correctly nowadays (specifically, curl and the openssl rust crate successfully avoid the defects in this area in openssl).

[alexliesenfeld]

That's interesting @ctz. I'm on macOS Sonoma (14.0), toolchain stable-aarch64-apple-darwin - rustc 1.77.0 (aedd173a2 2024-03-17), and I get this instead:

Finished test [unoptimized + debuginfo] target(s) in 0.05s
Running unittests src/lib.rs (target/debug/deps/rustls_sni-c672cb6c9b6a3263)
thread 'tests::test_with_curl' panicked at src/lib.rs:27:43:
called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidData, error: InvalidMessage(InvalidServerName) }
stack backtrace:
  ...
thread 'tokio-runtime-worker' panicked at src/lib.rs:71:28:
called `Result::unwrap()` on an `Err` value: Error { description: "SSL connect error", code: 35, extra: Some("Decode failed") }
stack backtrace:
 ...
thread 'tests::test_with_curl' panicked at src/lib.rs:72:18:
called `Result::unwrap()` on an `Err` value: JoinError::Panic(Id(4), ...)
stack backtrace:
 ...
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'tests::test_with_isahc' panicked at src/lib.rs:27:43:
called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidData, error: InvalidMessage(InvalidServerName) }
stack backtrace:
  ...
thread 'tests::test_with_isahc' panicked at src/lib.rs:56:59:
called `Result::unwrap()` on an `Err` value: Error { kind: ConnectionFailed, context: None, source: Some(Error { description: "SSL connect error", code: 35, extra: None }), source_type: Some("curl::error::Error"), local_addr: Some(127.0.0.1:49684), remote_addr: Some(127.0.0.1:65432) }
stack backtrace:
 ...
thread 'tests::test_with_reqwest' panicked at src/lib.rs:27:43:
called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidData, error: InvalidMessage(InvalidServerName) }
stack backtrace:
 ...
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'tests::test_with_reqwest' panicked at src/lib.rs:43:55:
called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Ipv4(127.0.0.1)), port: Some(65431), path: "/", query: None, fragment: None }, source: hyper::Error(Connect, Error { code: -9833, message: "decoding error" }) }
stack backtrace:
 ...

[ctz]

Well, that is dismal. We previously reported that to Apple in 2018, and they fixed it back then but I guess has regressed. It may be time to give up on accurately implementing the RFC.