[Python-Dev] PEP 476: Enabling certificate validation by default!

[Nick Coghlan]

On 4 September 2014 22:39, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 4 Sep 2014 13:11:38 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> That leaves Python 2.7, and I have to say I'm now persuaded that a
>> backport (including any required httplib and urllib features) is the
>> right way to go. One of the tasks I'd been dreading as a follow-on
>> from PEP 466 was organising the code audit to make sure our existing
>> Python 2 applications are properly configuring SSL. If we instead
>> change Python 2.7.9 to validate certificates by default, then the need
>> to do that audit *goes away*, replaced by the far more mundane tasking
>> of doing integration testing on 2.7.9, which we'd have to do *anyway*.
>
> What are "our existing Python 2 applications"? Is it a Red Hat-specific
> statement? What is the "code audit" you are talking about?

Yes, that's a Red Hat specific statement. In addition to OpenStack,
many of our other products include Python components. We mostly rely
on pycurl, pyopenssl, python-nss, etc for SSL/TLS for historical
reasons (since ssl wasn't available in the Python standard library
until RHEL 6), which was why these concerns got picked up via the
OpenStack community rather than the Fedora community. However, being
aware of the problem creates that element of doubt as to whether there
are *other* cases where someone used the stdlib ssl module rather than
one of the alternatives that verifies HTTPS by default.

I'd previously been looking at the question while wearing my upstream
core developer & CPython redistributor hats. Glyph et al finally
prompted me to look at it while wearing my "automated quality
assurance toolchain architect for an application vendor" hat (i.e. my
actual day job), and that's a *radically* different perspective when
it comes to a language runtime that fails to verify HTTPS connections
correctly by default.

That's the core reason I changed my mind: this conversation forced me
to think through how I could ensure correct HTTPS handling in all our
Python code, and the only workable solution I now see is to fix it at
the standard library level. The alternative is to prepare for the
likelihood of future CVEs in Python based tools based on failure to
properly verify SSL certificates, as I don't see a practical way of
automatically detecting "tried to use HTTPS without verifying the SSL
certificate properly".

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia