As discussed on issue1589 it is now possible to create decent ssl connections with the ssl module - assuming ca_certs is specified and it is checked that the certificates matches.

The standard library do however neither do that nor make it possible to do it in the places where it uses ssl. For example smtplib starttls do not make it possible at all to specify ca_certs.

I suggest all uses of ssl should be reviewed - and fixed if necessary. The documentation should also be improved to make it clear what is necessary to create "secure" connections.

There are open issues for specific modules: #8808 for imaplib, #8809 for smtplib.
In 3.2, poplib already has support for SSL contexts, as do ftplib, http.client and nntplib. If I'm missing a module please tell me.

I'd rather recommend a different approach, where the set of CAs doesn't need to be specified for every module that directly or indirectly uses SSL. Instead, there should be support for a thread-local setting of the allowable CAs, and then no API changes are necessary.

> I'd rather recommend a different approach, where the set of CAs
> doesn't need to be specified for every module that directly or
> indirectly uses SSL. Instead, there should be support for a
> thread-local setting of the allowable CAs, and then no API changes are
> necessary.

While thread-local variables are fine in applications, I think they
should be avoided in libraries (especially the stdlib). There are too
many pitfalls (for example: the user decides to offload a network task
to a separate thread and different SSL parameters get silently used).

The API changes are quite simple, both in concept and in implementation.
I think explicit is really better than implicit when it comes to
security-critical parameters.

The response I got to this issue hinted that it was a lame issue I filed. I haven't had time/focus to investigate further and give constructive feedback.

I think it is kind of OK to require explicit specification of the ca_certs as long as it is made clear in all the relevant places that it _has_ to be done. I think it would be a good idea to deprecate the default value for ca_certs and issue a warning if ca_certs hasn't been specified (as None or a path).

I have heard that some Python variants come with the system ca_certs built in and hard-coded somehow. That is in a way very nice and convenient and a good solution (as long the user wants to use the same ca_certs for all purposes), but it would have to be available and reliable on all platforms to be really useful.

> I think it is kind of OK to require explicit specification of the
> ca_certs as long as it is made clear in all the relevant places that
> it _has_ to be done. I think it would be a good idea to deprecate the
> default value for ca_certs and issue a warning if ca_certs hasn't been
> specified (as None or a path).

The recommended way from Python 3.2 upwards is to define a SSLContext
and use it when doing SSL operations. Many APIs have been updated to
accept a context, a few are remaining as I've said in my first comment.

> I have heard that some Python variants come with the system ca_certs
> built in and hard-coded somehow.

This is really "some OpenSSL variants" rather than "some Python
variants". We can't control how the system (or user-supplied) OpenSSL is
built.
This "feature" is exposed in SSLContext.set_default_verify_paths() (see
http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_default_verify_paths),
with the caveat that you don't know whether it succeeded at all.

> That is in a way very nice and convenient and a good solution (as long
> the user wants to use the same ca_certs for all purposes), but it
> would have to be available and reliable on all platforms to be really
> useful.

Well, for one, it probably won't be effective on Windows builds, since
it's really not Python's job to define a set of reliable CA certificates
(unless Martin wants to take that responsibility, that is), and Windows
doesn't have a set of system certificates in the PEM format AFAIK.