[Python-Dev] Simplify and unify SSL verification (original) (raw)

Christian Heimes christian at python.org
Fri Nov 8 17:39:04 CET 2013

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 CERTNONE and then expect calling matchcert() 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 checkcert() 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!

:p

Christian

More information about the Python-Dev mailing list