[Python-Dev] Simplify and unify SSL verification

[Nick Coghlan]

On 9 Nov 2013 02:41, "Christian Heimes" <christian at python.org> wrote:
>
> 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.

As long as there is a backports.ssl module, support in tulip and in
requests, it's likely fine in terms of supporting the common 2/3 subset.

However, since this change mostly *can* be published via PyPI, I also don't
think it makes sense to rush the design of this in the next two weeks.

- I'm already trying to help get the binary codec changes, ensurepip and
ModuleSpec landed
- the hash update PEP still needs to be finalised
- there's a couple of other context management features assigned to me to
check before the deadline

Heck, testing on PyPI first would even allow for fixing the misnomer -
currently we're importing the ssl module to access Python's TLS support,
which can't be helping the widespread misunderstanding of the fact they're
not quite the same thing (even though TLS superseded SSL).

The "create_default_context" idea and ensuring affected APIs accept a
context object doesn't need to wait, nor does deprecating the implied
CERT_NONE verification mode.

It's just the parameter deprecations and the matching customisation API I
think should be delayed, since those have broader implications that I don't
believe we can give adequate consideration in two weeks when there's
already plenty of other work we're still trying to finish up.

Cheers,
Nick.

>
> > 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
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131109/f0e1222c/attachment.html>