[Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

[Chris Angelico]

On Tue, Jun 4, 2013 at 7:31 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>
> On 3 June 2013 21:05, Chris Angelico <rosuav at gmail.com> wrote:
>> Some legit sites with proper
>> certificates still manage to muck something up administratively
>> (developer.quicksales.com.au has a cert from RapidSSL but doesn't
>> bundle the intermediates, and I've told their devs about it, but all I
>> can do is disable cert checking). This will break code in ways that
>> will surprise people greatly. But I'd still rather the default be
>> True.
>
> I'm happy if the "will cease to work" clause only says "some sites with
> broken security configurations may stop working" with a clear explanation
> that it is *their* fault, not Python's. I'd also expect that the same sites
> would fail in browsers - if not, we should also be able to make them work
> (or face cries of "well, Internet Explorer/Firefox doesn't have a problem
> with my site, why does Python?").

In this specific case, I get no warning from Google Chrome on either
Windows or Linux, but I do get a warning from Iceweasel on the same
Linux (it's Debian Wheezy, fwiw). So there probably will be cries of
"well, Chrome doesn't etc etc".

> Also, we should consider the issue for application users. Suppose I'm using
> a Python application that downloads something from the web. I upgrade to
> 3.4, and the app stops working because of a "will cease to work" case. As an
> end user, how can I get the app working again? Having to patch the sources
> isn't an option, and reverting to 3.3 provokes the reaction "Python broke my
> app".

Right. The instance I'm citing comes from what I'm doing at work; I
had to disable certificate checking in order to get a non-interactive
application to work. If I'd never thought to make sure cert checking
was happening, the app could easily have been unexpectedly broken by
this change.

But you're absolutely right. It's a failing at the remote end, or...

On Tue, Jun 4, 2013 at 7:41 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Keep in mind that not every HTTPS service is a Web site that is meant
> to be readable with a browser. Some are Web services, possibly internal,
> possibly without a domain name (and, therefore, probably a non-matching
> certificate subject name).

... this. This isn't a problem, as checking can easily be disabled,
but I'd be inclined to recommend that this one be solved without
changing code by explicitly importing that certificate. That would
resolve everything, but would require administrative action.

ChrisA