standard library do not use ssl as recommended

[kiilerix]

BPO	10795
Nosy	@loewis, @pitrou

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2010-12-30.13:42:24.235>
created_at = <Date 2010-12-30.01:42:39.367>
labels = ['type-feature', 'library']
title = 'standard library do not use ssl as recommended'
updated_at = <Date 2011-03-10.18:05:05.375>
user = 'https://bugs.python.org/kiilerix'

bugs.python.org fields:

activity = <Date 2011-03-10.18:05:05.375>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2010-12-30.13:42:24.235>
closer = 'pitrou'
components = ['Library (Lib)']
creation = <Date 2010-12-30.01:42:39.367>
creator = 'kiilerix'
dependencies = []
files = []
hgrepos = []
issue_num = 10795
keywords = []
message_count = 6.0
messages = ['124898', '124919', '130508', '130514', '130516', '130519']
nosy_count = 3.0
nosy_names = ['loewis', 'pitrou', 'kiilerix']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue10795'
versions = ['Python 3.3']

[kiilerix]

As discussed on bpo-1589 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.

[pitrou]

There are open issues for specific modules: bpo-8808 for imaplib, bpo-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.

[loewis]

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.

[pitrou]

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.

[kiilerix]

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.

[pitrou]

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.