Feature Request : Disable hostname verification

It seems that this isn't always necessary, for example when I'm using pinned certs. I ran up against that issue trying to use https://github.com/kelproject/pykube and will have to use a proxy workaround.  I'm using the IP address, not the hostname to contact the server per the prepackaged configuration file. I get the hostname '<IP ADDRESS>' doesn't match either of .... message.  

So, ultimately this is just not very likely to happen. The utility of having certificate verification but not hostname verification is very low (basically zero) in the general case, so the *only* useful situation is for pinned certificates. In the pinned certificate case, though, the question has to be asked: why doesn't the owner mint a valid certificate?

In this case the hostname is generic and the same in multiple configurations that will have different certificates - the certificate is specific to the environment.  So the desktop client (which is outside of the environment) uses the ip address to connect.  I disagree that this doesn't have utility.  Another case is with mobile applications where the app does the verification.  There is less reason to "mint a valid certificate" if the app itself is in charge of validating that certificate. 

> There is less reason to "mint a valid certificate" if the app itself is in charge of validating that certificate.

This is where I don't agree. If you are capable of getting a TLS certificate that will chain to an appropriate trust root, it should be essentially a trivial amount of extra work to ensure that that the certificate will also pass hostname validation.

Regardless, Requests is not going to add an option for this. You can use a Transport Adapter to pass urllib3 a fingerprint to use the validate the certificate for any of these connections if that's what you'd rather do, or you can do the same to disable hostname validation in urllib3, but requests isn't going to add a high-level switch to enable this functionality. Its use in 99%+ of cases would be dangerous.

That's what I'm saying the certificate is not chained to the trust root. It's validated by the app only.  There is less need for the chain of trust if the app itself is validating the cert.  

If the certificate is not chained to a trust root then it won't pass cert validation *at all*, and so you'd need to pass `verify=False`.

Yes, the point is there are other ways to validate a cert. chained to a trust root is one that is used a lot, but it's not the only way.  Cert pinning is another way. 


Sure, and `verify=False` exists to satisfy those use cases. Why is `verify=False` insufficient for you?

 Well in this case I'd have to add it at the application level or fork the library I'm using. 

Hang on, let's stop back for a moment.

Your feature request, as I originally understood it, was to disable hostname verification *only*. I assumed, from the nature of that question, that disabling verification *entirely* was insufficient. That appears to be wrong: your follow-up responses appear to me say that that would be fine. I think this means I don't understand what you want. :smile:

So let's step back so that I can better understand your problem. You are using pykube, correct? Your problem, as I understand it, is that you would like to disable certificate validation *entirely* so that you can use untrusted certificates with pykube, because you plan to validate them some other way. Your last comment suggests that you would like a way to do that that does not involve touching pykube. Does all of that sound correct, or have I misunderstood?

I don't think we really want to turn verify off as it is using client certificates.  I think it's using the filename path to a CA Bundle for validation.  The host in the cert bundle simply doesn't match what's in the k8s config file, as by default it uses the IP :/

Hrm. Is it worth resolving this by adding a hosts file entry instead? Alternatively, does the remote cert have the appropriate iPAddress subject alternative name field?

The discussion here has stalled for months and there's very little clarity on what's desired. I'm happy to reopen this, but for now I'm closing this.