[Python-Dev] Simplify and unify SSL verification

[Christian Heimes]

Am 08.11.2013 08:42, schrieb Antoine Pitrou:
> 3.2 actually, while many code bases are still 2.x-compatible.
> There's no need to make migration more annoying right now.

There is also no need to hinder and delay future improvements for the
sake of 2.x compatibility. Python 2.7.0 has been released in July 2010.
Python 3.5 will be released late 2015. 3rd parties can backport Python
3.x ssl module if they need the new feature in 2.x, too.

Seriously, it's time to set Python 3 free. Python 2.7 shall no longer be
a millstone around Python 3's neck.

> If it's not solved on *all* platforms then you're introducing a nasty
> discrepancy between platforms.
> 
> That said, "secure by default" could be a property of the "default
> context factory" (see below).

I think you forget that incompatible changes won't happen until Python
3.5. Developer and users can still have the insecure, non verified mode
but they have to configure it explictly.


> Ok, so what about the long term compatibility issues?
> 
> I'd be ok if you changed the name as suggested by Nick *and* if it was
> explicit that the security settings for this context can change between
> releases, therefore working code can break due to upgraded security
> standards.

Absolutely! Applications shall create their own context if they require
full control. create_default_context() return a sensible context object
that is subject to changes between releases.


> But, really, it strikes me that adding this method to SSLSocket may make
> things more confusing. The docs will have to be clear that certificate
> *validation* and certificate *matching* are two different things (that
> is, you can't pass CERT_NONE and then expect calling match_cert() is
> sufficient).

I like Nick's idea with verify_hostname flag and a postverify callback.

At first the callback is invoked. Then the hostname is verified if
either verify_hostname is true or None with CERT_OPTIONAL /
CERT_REQUIRED. Similar to __exit__() the callback can return a true
value in order to skip hostname matching.


>> The **kwargs make it possible to pass data from the caller of
>> check_cert() to the callback function of the SSLContext instance.
> 
> Well, I think such explicit "user data" needn't exist in Python.

Sure, people can just use thread local storage or walk up the stack with
sys._getframe(). That's going to work well for asyncio! </irony>

:p

Christian