[Python-Dev] Simplify and unify SSL verification

[Antoine Pitrou]

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 verify_mode=CERT_NONE. Python 3.5 will default
>>>     to CERT_REQUIRED.
>>
>> -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.get_default_context() 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 check_cert(), 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
> check_cert() 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.check_cert() 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 check_cert 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.