[Python-Dev] Verification of SSL cert and hostname made easy

[Christian Heimes]

Am 01.12.2013 12:33, schrieb Nick Coghlan:
> Perhaps a cleaner option would be to make check_hostname read only,
> and add a secure-by-default method that allows all verification
> related settings to be adjusted at once:
> 
>     def set_verify_mode(mode=ssl.CERT_REQUIRED, check_hostname=True):
>         ...
> 
> That way the consistency check would be directly on the method
> arguments, rather than involving the current context state. Any future
> settings that required a verified cert could then use a similar model.

I don't like to add yet another API element to SSLContext. I'd rather
extend SSLContext.__init__ to take two additional parameters:

class SSLContext(_SSLContext):
    def __init__(self, protocol, verify_mode=ssl.CERT_NONE,
check_hostname=False):
        self.protocol = protocol
        self.verify_mode = verify_mode
        self.check_hostname = check_hostname


I also like to point out (again) that the requirement is only a
limitation of our API. OpenSSL is able to acquire and return the peer's
certificate with any mode. In the past somebody decided to map 'no
certificate' to None and 'no verification' to empty dict.


> If we don't do that, then I think Christian's approach is a reasonable
> compromise given the late stage of the release cycle - it ensures the
> context can't get into the inconsistent verify_mode=CERT_NONE and
> check_hostname=True state, and leaves our options completely open for
> 3.5:

You are right, I'm trying to aim for the simplest and smallest solution
possible. I'm well aware that the order of API calls is a limitation and
that it feels a bit awkward, too. In my opinion there is no way this API
can be screwed up. :) Any limitation can be lifted for 3.5 but we can't
make it more restrict in future versions.

And there is ssl.create_default_context(), too. It creates a context
with all security-related bits flipped on.

Christian