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

Antoine Pitrou solipsis at pitrou.net
Fri Nov 8 08:42:53 CET 2013

Le 07/11/2013 22:42, Christian Heimes a écrit :

Am 07.11.2013 21:45, schrieb Antoine Pitrou:

I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is quite young. It's available since 3.3

3.2 actually, while many code bases are still 2.x-compatible. There's no need to make migration more annoying right now.

- deprecate implicit verifymode=CERTNONE. Python 3.5 will default to CERTREQUIRED.

-0.9. This breaks compatibility and doesn't achieve anything, since there's no reliable story for CA certs. I'd like to move to "secure by default". The CA cert situation is solved on most platforms.

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).

- add ssl.getdefaultcontext() to acquire a default SSLContext object if the context argument is None. (Python 3.4)

I think I'm against it, for two reasons: 1. It will in the long term create compatibility and/or security issues (we'll have to keep fragile legacy settings if we want to avoid breaking existing uses of the default context) 2. SSLContexts are mutable, which means some code can affect other code's behaviour without even knowing. It's a recipe for subtle bugs and security issues. Applications and/or higher-level libraries should be smart enough to choose their own security preferences, and it's the better place to do so anyway. You misunderstood me. I'm not proposing a global SSLContext object but a factory function that creates a context for Python stdlib modules. Right now every urllib, http.client, nntplib, asyncio, ftplib, poplib and imaplib have duplicated code. I'd like to have ONE function that creates and configures a SSLContext object with sensible default values for Python stdlib.

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.

I'm against calling it checkcert(), it's too generic and only induces confusion. Do you have an idea for a better name?

match_service()? match_cert()?

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).

And why is there an "initiator" object? Personally I prefer to avoid passing opaque user data, since the caller can use a closure anyway. And what are the **kwargs? No, they can't use a closure. The callback function is part of the SSLContext object. The context object can be used by multiple SSLSocket objects.

So what? If you want to use multiple callbacks or closures, you can create multiple context objects.

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.

So what does this bring compared to the statu quo? I thought at least sock.checkcert() would be called automatically, but if you have to call it yourself it starts looking pointless, IMO. As you have said earlier, cert matching is not strictly a SSL connection thing. With the checkcert feature you can do stuff like validation of self-signed certs with known hash sums:

Ok, so you can pass that context to e.g. httplib, right? I'm convinced, except on the "user data" part :)

Regards

Antoine.

More information about the Python-Dev mailing list