Sorry I was on my phone and didn’t get to fully reply to this.
On 29.08.2014 21:47, Alex Gaynor wrote:
I've just submitted PEP 476, on enabling certificate validation by default for
HTTPS clients in Python. Please have a look and let me know what you think.
PEP text follows.
Thanks for the PEP. I think this is generally a good idea,
but some important parts are missing from the PEP:
* transition plan:
I think starting with warnings in Python 3.5 and going
for exceptions in 3.6 would make a good transition
Going straight for exceptions in 3.5 is not in line with
our normal procedures for backwards incompatible changes.
As far as a transition plan, I think that this is an important
enough thing to have an accelerated process. If we need
to provide a warning than let’s add it to the next 3.4 otherwise
it’s going to be 2.5+ years until we stop being unsafe by
Another problem with this is that I don’t think it’s actually
possible to do. Python itself isn’t validating the TLS certificates,
OpenSSL is doing that. To my knowledge OpenSSL doesn’t
have a way to say “please validate these certificates and if
they don’t validate go ahead and keep going and just let me
get a warning from it”. It’s a 3 way switch, no validation, validation
if a certificate is provided, and validation always.
Now that’s strictly for the “verify the certificate chain” portion,
the hostname verification is done entirely on our end and we
could do something there… but I’m not sure it makes sense
to do so if we can’t do it for invalid certificates too.
It would be good to be able to switch this on or off
without having to change the code, e.g. via a command
line switch and environment variable; perhaps even
controlling whether or not to raise an exception or
I’m on the fence about this, if someone provides a certificate
that we can validate against (which can be done without
touching the code) then the only thing that really can’t be
“fixed” without touching the code is if someone has a certificate
that is otherwise invalid (expired, not yet valid, wrong hostname,
etc). I’d say if I was voting on this particular thing I’d be -0, I’d
rather it didn’t exist but I wouldn’t cry too much if it did.
* choice of trusted certificate:
Instead of hard wiring using the system CA roots into
Python it would be good to just make this default and
permit the user to point Python to a different set of
This would enable using self signed certs more easily.
Since these are often used for tests, demos and education,
I think it's important to allow having more control of
the trusted certs.
to easily specify your own CA roots and/or disable the validations.
or a file to change the root certificates without code changes. The
an unrelated thing where you can’t pass in an in memory certificate.