New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python SSL stack doesn't have a default CA Store #57864
Comments
For the certificate store: Can we eventually agree to bind a default CA-store to a Mozilla verified one? Integrating default mozilla CA-store with Python builds could be a nice way, it's just a matter of integrating into the build-system the download/fetching of default Mozilla store. At least the language base it's default on a trusted entity to manage, cross-platform, the CA-store for TLS/SSL. The mainteinance of the CA-store would be delegated to Mozilla that has been demonstrated to be independent and very security conscious, removing dirty CA-store (like Diginotar after Iranian compromise). That way 90% of case of of SSL/TLS certificate validation will be managed and by default it would be possible to enable secure SSL/TLS client checking like described in http://bugs.python.org/issue13647 . |
Mozilla CA are available on: https://www.mozilla.org/projects/security/certs/ The warranty and security process of Mozilla handling of SSL CA root certs is described on: I think that Python language could reasonably base it's default root CA on the Mozilla ones that are the most recognized for security and transparency in the world. |
I'm not sure Python should be in the business of distributing CA certificates. I think it's better left to the application or Linux distribution. |
I propose to change the scope of this request to: ssl module should provide a way to access the OS CA bundle. |
Copy of a message by Christian Heimes on a duplicate report: For effective SSL server cert validation a bundle of trustworthy CA certs is required. Most system ship such a bundle but it's not always possible to access the bundle from Python / OpenSSL. Windows and Mac OS X come into my mind. wget and curl ship a copy of Mozilla's CA cert bundle. The site http://curl.haxx.se/docs/caextract.html explains how to extract the CA certs in PEM format. I suggest that we ship the CA bundle with Python and use a lookup chain:
|
Éric's suggestion is also implemented in python-requests if I remember correctly. It allows for user-specified PEM files and tries to find the operating system bundle. This would be a wonderful inclusion in the standard library. |
Aren't load_verify_locations() and set_default_verify_paths() sufficient? http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.load_verify_locations |
I think we can improve the situation with shipping our own CA certs. Almost every operating system or distribution comes with a set of CA certs. I lots of Linux distributions and most BSD systems. All except FreeBSD install CA certs by default. A fresh FreeBSD systems doesn't have certs but Here is a full list: cert_paths = [
# Debian, Ubuntu, Arch, SuSE
# NetBSD (security/mozilla-rootcerts)
"/etc/ssl/certs/",
# Debian, Ubuntu, Arch: maintained by update-ca-certificates
"/etc/ssl/certs/ca-certificates.crt",
# Red Hat 5+, Fedora, Centos
"/etc/pki/tls/certs/ca-bundle.crt",
# Red Hat 4
"/usr/share/ssl/certs/ca-bundle.crt",
# FreeBSD (security/ca-root-nss package)
"/usr/local/share/certs/ca-root-nss.crt",
# FreeBSD (deprecated security/ca-root package, removed 2008)
"/usr/local/share/certs/ca-root.crt",
# FreeBSD (optional symlink)
# OpenBSD
"/etc/ssl/cert.pem",
# Mac OS X
"/System/Library/OpenSSL/certs/cert.pem",
] I'd like to add the list to our ssl.py and add an API to check and load certs from that files, directories and other places (Windows). |
Why would we ship our own CA certs if every OS comes with CA certs?
Kudos to FreeBSD.
I don't think it's a good idea to maintain a list of hard-coded |
On Jul 08, 2013, at 11:56 AM, Antoine Pitrou wrote:
I agree. I don't think we should be shipping certs, but if we do, then it |
re: cert_paths = [...] This approach is rather problematic, there's no guarantee that a path trusted on one system is trusted on another. I saw this in setuptools branch, where it does: for path in cert_path:
if os.path.exists(path)
return path Let's say you're user1 on osx and your native true path is "/System/Library/OpenSSL/certs/cert.pem", can you guarantee that someone else, user2, cannot sneak their hacked files into "/etc/pki/" (presumably missing altogether) or "/usr/local/share/"? Because if user2 can do that, suddenly user1 verifies all traffic against hacked ca list. |
All these paths are on directories that are supposed to be read-only for untrusted users. You can't protect yourself against a malicious admin anyway. For Python 3.4 the ssl module uses the cert path that are configured with OpenSSL. The paths and configuration are outside our control. |
I don't think we're planning to distribute our own store of certs. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: