Custom TLS hostname validation? #678
Description
Hi, I have this use case where I need to customize the TLS hostname validation. At first I tried to implement the support in NativeTLS for that, only to find out that it already supported the case I was thinking of: setting an expected CN different than the domain name: sfackler/rust-native-tls#141
An explanation copied from that PR:
For some use cases outside of the common HTTPS usage, the server hostname checking benefits from customizability.
My main use case is due to AWS's recent announcement about phasing out "path style" URLs for the S3 storage service, favoring the "virtual host" style URLs. (For example from https://s3.amazonaws.com/bucket.name/object.name to https://bucket.name.s3.amazonaws.com/object.name) The problem with this is that S3 bucket names can contain dots, but they are certified using a wildcard certificate with CN *.s3.amazonaws.com. Because wildcards don't match multiple labels, S3 buckets with dots in their names cause TLS errors.
The immediate remedy would be to use danger_accept_invalid_hostnames, but this exposes the client to MitM attacks so it's unacceptable. The subdomain namespace is guaranteed to be used for bucket names by AWS who controls the DNS s3.amazonaws.com and the bucket names, so implementing a custom check would be an acceptable solution here.
However, I can't access that knob from Reqwest, because it just sets up the hyper_tls::HttpsConnector that just uses the domain name and gives no leeway for customization. This brings me to ask, before I send any PRs: is in the scope of this project to be customizable enough to be able to set up custom TLS hostname checking, or should I be using something else for this use case?