classification
Title: standard library do not use ssl as recommended
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: kiilerix, loewis, pitrou
Priority: normal Keywords:

Created on 2010-12-30 01:42 by kiilerix, last changed 2011-03-10 18:05 by pitrou. This issue is now closed.

Messages (6)
msg124898 - (view) Author: Mads Kiilerich (kiilerix) * Date: 2010-12-30 01:42
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.
msg124919 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-12-30 13:42
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.
msg130508 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-03-10 14:47
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.
msg130514 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-03-10 16:57
> 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.
msg130516 - (view) Author: Mads Kiilerich (kiilerix) * Date: 2011-03-10 17:18
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.
msg130519 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-03-10 18:05
> 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.
History
Date User Action Args
2011-03-10 18:05:05pitrousetmessages: + msg130519
2011-03-10 17:18:48kiilerixsetmessages: + msg130516
2011-03-10 16:57:06pitrousetmessages: + msg130514
2011-03-10 14:47:24loewissetnosy: + loewis
messages: + msg130508
2010-12-30 13:42:24pitrousetstatus: open -> closed
versions: + Python 3.3, - Python 2.7
nosy: pitrou, kiilerix
messages: + msg124919
resolution: duplicate

type: enhancement
2010-12-30 01:42:39kiilerixcreate