Add support for disabling SSL host name verification

There are some use-cases where SSL certificate verification is required, but without validating the CN (it is the host name of the server in HTTPS).

This patch introduces the dont_verify_host flag, which disables host verification, only if it is set to True. A value of None (the default) or False will keep the enabled host verification.


I don't think this will be accepted as is, as half of the changes are in shazow/urllib3, which is a different project.

If you know the CN announced by the server you can do something like this:
(Note the `assert_hostname` parameter)

``` py
import requests


class MyAdapter(requests.adapters.HTTPAdapter):
    def init_poolmanager(self, connections, maxsize, block):
        self._pool_connections = connections
        self._pool_maxsize = maxsize
        self._pool_block = block
        self.poolmanager = requests.packages.urllib3.PoolManager(num_pools=connections,
                                                                 maxsize=maxsize,
                                                                 assert_hostname='t-8ch.de')

s = requests.Session()
s.mount('https://', MyAdapter())

s.get('https://test.t-8ch.de')
```

Without mounting the adapter you will get an exception.
It should go away when mouting the adapter.

(Note to future visitors: I'll fix my certificate when this issue is resolved, so you may not experience the described behaviour :smile: )


This patch introduces an existing feature in any SSL library - letting the library user decide whether to verify the CN. For example in openssl, the default is _not_ to verify the CN.

In the regular usage, where a known public server is requested, it is mandatory to verify the CN, and this patch does not touch this behavior.

On the other hand, when a custom small chain of trust is used, such as in our use-case, verifying the CN, even if it is a constant one, is completely useless.

By the way, why did you copy shazow/urllib3, instead of git submodule'ing it?


Hi @borfig, thanks for this pull request!

As @t-8ch said, in its current form we can't accept this Pull Request. We do not make local changes to urllib3, so the urllib3 portions of this work would have to be contributed separately upstream. You should feel free to do that if you'd like to. As for why we have vendored urllib3 instead of using a git submodule, I'll point you at the discussion in #1384 which went over the decision in great detail. (Short answer: the standard Python repository structure does not lend itself to being a git submodule.)

Approaching this more generally, Requests has very strong opinions about SSL. Even if this feature was added to urllib3, I don't think we'd add it to the functional Requests API. Instead, I think we'd expect people to use Transport Adapters (as @t-8ch has demonstrated) to get that functionality.


There have been talks in urllib3#140 about a new class `Verification` where users can embed their own verification logic, as urllib3's ssl api is becoming a but unwieldy.
Until this gets implemented it may be possible to change the `assert_hostname` of `urllib3` to disable hostname verification if it's value is the empty string `''`.

cc @shazow


Setting `assert_hostname` of packaged `urllib3` to `''` will trigger the validation as if it was `None`. The same also happens in standalone shazow/urllib3.

My goal is to disable the CN validation, and the current code, both in `requests` and `urllib3`, does not allow this. I could also replace `match_hostname` function dynamically in the code that imports `requests`, but this is way too ugly.


Indeed, the current implementation doesn't allow this. I wanted to propose a _change_ which would introduce the behaviour I proposed. Sorry if this wasn't clear.


I think that for the moment this discussion should be moved over to urllib3. Feel free to open a new Pull Request if and when urllib3 includes the necessary changes.

Thanks for opening this Pull Request, keep them coming! =)


This has been implemented by @borfig in shazow/urllib3#194. It has already been merged into master.


Oh excellent! I still need a new PR with only the new changes though. =)