PEP-644: Require OpenSSL 1.1 or newer (#1692)
Signed-off-by: Christian Heimes <christian@python.org>
This commit is contained in:
Christian Heimes
GitHub
parent
c9a0f76dd4
commit
08abdc8d14
|
|
@ -0,0 +1,349 @@
|
|||
PEP: 644
|
||||
Title: Require OpenSSL 1.1 or newer
|
||||
Author: Christian Heimes <christian@python.org>
|
||||
BDFL-Delegate: n/a
|
||||
Discussions-To: https://discuss.python.org/t/pep-644-require-openssl-1-1-or-newer/5584
|
||||
Status: Draft
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 27-Oct-2020
|
||||
Python-Version: 3.10
|
||||
Post-History: 27-Oct-2020
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This PEP proposes for CPython’s standard library to support only OpenSSL
|
||||
1.1.1 LTS or newer. Support for OpenSSL versions past end-of-lifetime,
|
||||
incompatible forks, and other TLS libraries are dropped.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
Python makes use of OpenSSL in `hashlib`, `hmac`, and `ssl` modules. OpenSSL
|
||||
provides fast implementations of cryptographic primitives and a full TLS
|
||||
stack including handling of X.509 certificates. The `ssl` module is used by
|
||||
standard library modules like `urllib` and 3rd party modules like `urllib3`
|
||||
to implement secure variants of internet protocols. `pip` uses the `ssl`
|
||||
module to securely download packages from PyPI. Any bug in the ssl module's
|
||||
bindings to OpenSSL can lead to a severe security issue.
|
||||
|
||||
Over time OpenSSL's public API has evolved and changed. Version 1.0.2
|
||||
introduced new APIs to verify and match hostnames. OpenSSL 1.1.0 made
|
||||
internal structs opaque and introduced new APIs that replace direct access of
|
||||
struct members. Version 3.0.0 will deprecate more APIs due to internal
|
||||
reorganization that moves cryptographic algorithms out of the core and into
|
||||
providers. Forks like LibreSSL and BoringSSL have diverged in different
|
||||
directions.
|
||||
|
||||
Currently Python versions 3.6 to 3.9 are compatible with OpenSSL 1.0.2,
|
||||
1.1.0, and 1.1.1. For the most part Python also works with LibreSSL >= 2.7.1
|
||||
with some missing features and broken tests.
|
||||
|
||||
Due to limited resources and time it becomes increasingly hard to support
|
||||
multiple versions and forks as well as test and verify correctness. Besides
|
||||
multiple incompatible APIs there are build time flags,
|
||||
distribution-specific patches, and local crypto-policy settings that add to
|
||||
plethora of combinations. On the other hand, the Python core team has only
|
||||
a couple of domain experts who are familiar with TLS and OpenSSL internals
|
||||
and even fewer who are active maintainers.
|
||||
|
||||
Requiring OpenSSL 1.1.1 would allow us to give the vast majority of users a
|
||||
better experience, reduce our maintenance overhead and thus free resources
|
||||
to implement new features. Users would be able to rely on the presence of
|
||||
new features and consistent behavior, ultimately resulting in a more robust
|
||||
experience.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
OpenSSL 1.1.1 is the default variant and version of OpenSSL on almost all
|
||||
supported platforms and distributions. It’s also the only version that still
|
||||
receives security support from upstream [9]_.
|
||||
|
||||
No macOS and Windows user will be affected by the deprecation. The python.org
|
||||
installer and alternative distributions like Conda ship with most recent
|
||||
OpenSSL version.
|
||||
|
||||
As of October 2020 and according to DistroWatch [1]_ most current BSD and
|
||||
Linux distributions ship with OpenSSL 1.1.1 as well. Some older releases of
|
||||
long term support (LTS) and enterprise distributions have older versions of
|
||||
OpenSSL or LibreSSL. By the time Python 3.10 will be generally available,
|
||||
several of these distributions will have reached end of lifetime, end of
|
||||
general support, or moved from LibreSSL to OpenSSL.
|
||||
|
||||
Other software has dropped support for OpenSSL 1.0.2 as well. For example
|
||||
PyCA cryptography 3.2 (2020-10-25) removed compatibility with OpenSSL 1.0.2.
|
||||
|
||||
|
||||
OpenSSL 1.0.2 LTS
|
||||
-----------------
|
||||
|
||||
released: 2015-02
|
||||
end of lifetime: 2019-12
|
||||
|
||||
OpenSSL 1.0.2 added hostname verification, ALPN support, and elliptic curves.
|
||||
|
||||
- CentOS 7 (EOL 2024-06)
|
||||
- Debian 8 Jessie (EOL 2020-07)
|
||||
- Linux Mint 18.3 (EOL 2021-04)
|
||||
- RHEL 7 (full support ends 2019-08, maintenance 2 support ends 2024-06)
|
||||
- SUSE Enterprise Linux 12-SP5 (general supports ends 2024-10)
|
||||
- Ubuntu 16.04 LTS / Xenial (general support ends 2021-04)
|
||||
|
||||
|
||||
OpenSSL 1.1.0
|
||||
-------------
|
||||
|
||||
released: 2016-08
|
||||
end of lifetime: 2019-09
|
||||
|
||||
OpenSSL 1.1.0 removed or disabled insecure ciphers by default and added
|
||||
support for ChaCha20-Poly1305, BLAKE2 (basic features), X25519 and CT. The
|
||||
majority of structs were made opaque and new APIs were introduced. OpenSSL
|
||||
1.1.0 is not API compatible with 1.0.2.
|
||||
|
||||
- Debian 9 Stretch (estimated EOL 2022-06)
|
||||
- Ubuntu 18.04 LTS / Bionic (general support ends 2023-04)
|
||||
|
||||
|
||||
OpenSSL 1.1.1 LTS
|
||||
-----------------
|
||||
|
||||
released: 2018-08
|
||||
end of lifetime: 2023-09 (planned)
|
||||
|
||||
OpenSSL 1.1.1 added TLS 1.3, SHA-3, X448 and Ed448.
|
||||
|
||||
- Alpine (switched back to OpenSSL in 2018 [4]_)
|
||||
- Arch Linux current
|
||||
- CentOS 8.0+
|
||||
- Debian 10 Buster
|
||||
- Fedora 29+
|
||||
- FreeBSD 11.3+
|
||||
- Gentoo Linux stable
|
||||
- HardenedBSD (switched back to OpenSSL in 2018 [3]_)
|
||||
- Linux Mint 19.3+
|
||||
- macOS (python.org installer)
|
||||
- NetBSD 8.2+
|
||||
- openSUSE 15.2+
|
||||
- RHEL 8.0+
|
||||
- Slackware current
|
||||
- SUSE Enterprise Linux 15-SP2
|
||||
- Ubuntu 18.10+
|
||||
- Ubuntu 20.04 LTS / Focal
|
||||
- Windows (python.org installer, Conda)
|
||||
|
||||
|
||||
OpenSSL 3.0.0
|
||||
-------------
|
||||
|
||||
released: n/a (planned for early 2021)
|
||||
|
||||
OpenSSL 3.0.0 is currently under development. Major changes include
|
||||
relicensing to Apache License 2.0 and a new API for cryptographic algorithms
|
||||
providers. Most changes are internal refactorings and don’t affect public
|
||||
APIs. [8]_
|
||||
|
||||
|
||||
LibreSSL
|
||||
--------
|
||||
|
||||
created: 2014-04 (forked from OpenSSL 1.0.1g)
|
||||
|
||||
- DragonFly BSD
|
||||
- Hyperbola GNU/Linux-libre
|
||||
- OpenBSD
|
||||
- OpenELEC (discontinued)
|
||||
- TrueOS (discontinued)
|
||||
- VOID Linux (currently moving back to OpenSSL [5]_)
|
||||
|
||||
Some distributions like FreeBSD, Gentoo, and OPNsense also feature LibreSSL
|
||||
instead of OpenSSL as non-standard TLS libraries.
|
||||
|
||||
OpenBSD ports has a port `security/openssl/1.1` which is documented as
|
||||
"[...] is present to provide support for applications which cannot be made
|
||||
compatible with LibReSSL" [7]_. The package could be used by OpenBSD to
|
||||
provide a working ssl module.
|
||||
|
||||
|
||||
BoringSSL
|
||||
---------
|
||||
|
||||
created: 2014-06
|
||||
|
||||
BoringSSL is Google’s fork of OpenSSL. It’s not intended for general use and
|
||||
therefore not supported by Python. There are no guarantees of API or ABI
|
||||
stability. Vendored copies of BoringSSL are used in Chrome/Chromium browser,
|
||||
Android, and on Apple platforms [6]_.
|
||||
|
||||
|
||||
Benefits
|
||||
========
|
||||
|
||||
TLS 1.3
|
||||
-------
|
||||
|
||||
OpenSSL 1.1.1 introduced support for the new TLS 1.3 version. The latest
|
||||
version of the TLS protocol has a faster handshake and is more secure than
|
||||
the previous versions.
|
||||
|
||||
Thread and fork safety
|
||||
----------------------
|
||||
|
||||
Starting with release 1.1.0c, OpenSSL is fully fork and thread safe.
|
||||
Bindings no longer need any workarounds or additional callbacks to support
|
||||
multithreading.
|
||||
|
||||
SHA-3
|
||||
-----
|
||||
|
||||
Since 1.1.0, OpenSSL ships with SHA-3 and SHAKE implementations.
|
||||
Python's builtin SHA-3 support is based on the reference implementation. The
|
||||
internal `_sha3` code is fairly large and the resulting shared library close
|
||||
to 0.5 MB. Python could drop the builtin implementation and rely on OpenSSL's
|
||||
`libcrypto` instead.
|
||||
|
||||
So far LibreSSL upstream development has refused to add SHA-3 support. [2]_
|
||||
|
||||
|
||||
Compatibility
|
||||
=============
|
||||
|
||||
OpenSSL downstream patches and options
|
||||
--------------------------------------
|
||||
|
||||
OpenSSL features more than 70 configure and build time options in the form
|
||||
of `OPENSSL_NO_*` macros. Around 60 options affect the presence of features
|
||||
like cryptographic algorithms and TLS versions. Some distributions apply
|
||||
patches to alter settings. Furthermore default values for settings like
|
||||
security level, ciphers, TLS version range, and signature algorithms can
|
||||
be set in OpenSSL config file.
|
||||
|
||||
The Python core team lacks resources to test all possible combinations.
|
||||
This PEP proposes that Python only supports OpenSSL builds that have
|
||||
standard features enabled. Vendors shall disable deprecated or insecure
|
||||
algorithms and TLS versions with build time options like
|
||||
`OPENSSL_NO_TLS1_1_METHOD` or OpenSSL config options like
|
||||
`MinProtocol = TLSv1.2`.
|
||||
|
||||
Python assumes that OpenSSL is built with
|
||||
|
||||
- hashlib’s default algorithms such as MD5, SHA-1, SHA-2 family,
|
||||
SHA-3/SHAKE family, BLAKE2
|
||||
- TLS 1.2 and TLS 1.3 protocols
|
||||
- current key agreement, signature, and encryption algorithms for TLS 1.2
|
||||
and 1.3 (ECDH, RSA, ECDSA, Curve25519, AES, Poly1309-ChaCha20, ...)
|
||||
- threading, file I/O, socket I/O, and error messages
|
||||
|
||||
Weak algorithms (MD5, SHA-1 signatures) and short keys (RSA < 2024 bits) may
|
||||
be disabled at runtime. Algorithms may also be blocked when they are
|
||||
disabled by a crypto policy such as FIPS. The PEP is not more specific on
|
||||
purpose to give room for new features as well as countermeasures against
|
||||
vulnerabilities. As a rule of thumb, Python should be able to connect to
|
||||
PyPI and the test suite should pass.
|
||||
|
||||
LibreSSL support
|
||||
----------------
|
||||
|
||||
LibreSSL is a fork of OpenSSL. The fork was created off OpenSSL 1.0.1g by
|
||||
members of the OpenBSD team in 2014 in light of the heartbleed vulnerability.
|
||||
Since its inception several features deemed problematic or insecure were
|
||||
removed or replaced (SSL 2.0, SSL 3.0, improved CPRNG) or backported
|
||||
from OpenSSL and BoringSSL.
|
||||
|
||||
At the moment LibreSSL is not fully API compatible with OpenSSL 1.1.1. The
|
||||
latest release LibreSSL 3.3.2 is missing features and behaves differently
|
||||
in some cases. Mentionable missing or incompatible features include
|
||||
|
||||
- SHA-3, SHAKE, BLAKE2
|
||||
- `SSL_CERT_*` environment variables
|
||||
- security level APIs
|
||||
- session handling APIs
|
||||
- key logging API
|
||||
- verified cert chain APIs
|
||||
- OPENSSL_VERSION macro
|
||||
|
||||
This PEP proposed to remove any and all LibreSSL related workarounds from
|
||||
Python. In the future Python will not actively prohibit LibreSSL support
|
||||
with configure and compile time checks. But Python will not accept patches
|
||||
that add non-trivial workarounds or disable tests either.
|
||||
|
||||
|
||||
BoringSSL
|
||||
---------
|
||||
|
||||
There are currently no plans to support BoringSSL.
|
||||
|
||||
|
||||
Rejected Ideas
|
||||
==============
|
||||
|
||||
Formalize supported OpenSSL versions
|
||||
------------------------------------
|
||||
|
||||
This PEP does not provide a set of formal rules and conditions under which
|
||||
an OpenSSL version is supported.
|
||||
|
||||
In general Python aims to be compatible with commonly used and officially
|
||||
supported OpenSSL versions. Patch releases of Python may not be compatible
|
||||
with new major releases of OpenSSL. Users should not expect that a new major
|
||||
or minor release of Python works with an OpenSSL version that is past its
|
||||
end-of-lifetime. Python core development may backport fixes for new releases
|
||||
or extend compatibility with EOLed releases as we see fit.
|
||||
|
||||
The new ABI stability and LTS policies of OpenSSL [9]_ should help, too.
|
||||
|
||||
|
||||
Backwards Compatibility
|
||||
=======================
|
||||
|
||||
Python 3.10 will no longer support TLS/SSL and fast hashing on platforms
|
||||
with OpenSSL 1.0.2 or LibreSSL. This PEP is published at the beginning of
|
||||
the 3.10 release cycles. It gives vendors like Linux distributors or CI
|
||||
providers roughly 11 months to react.
|
||||
|
||||
|
||||
Disclaimer and special thanks
|
||||
=============================
|
||||
|
||||
The author of this PEP is a contributor to OpenSSL project and employed by
|
||||
a major Linux distributor that uses OpenSSL.
|
||||
|
||||
Thanks to Alex Gaynor, Gregory P. Smith, Nathaniel J. Smith, Paul Kehrer,
|
||||
and Seth Larson for their review and feedback on the initial draft.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [1] https://distrowatch.com/
|
||||
.. [2] https://github.com/libressl-portable/portable/issues/455
|
||||
.. [3] https://hardenedbsd.org/article/shawn-webb/2018-04-30/hardenedbsd-switching-back-openssl
|
||||
.. [4] https://lists.alpinelinux.org/~alpine/devel/%3CCA%2BT2pCGFeh30aEi43hAvJ3yoHBijABy_U62wfjhVmf3FmbNUUg%40mail.gmail.com%3E
|
||||
.. [5] https://github.com/void-linux/void-packages/issues/20935
|
||||
.. [6] https://forums.swift.org/t/rfc-moving-swiftnio-ssl-to-boringssl/18280
|
||||
.. [7] https://openports.se/security/openssl/1.1
|
||||
.. [8] https://www.openssl.org/docs/OpenSSL300Design.html
|
||||
.. [9] https://www.openssl.org/policies/releasestrat.html
|
||||
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
||||
This document is placed in the public domain or under the
|
||||
CC0-1.0-Universal license, whichever is more permissive.
|
||||
|
||||
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
sentence-end-double-space: t
|
||||
fill-column: 70
|
||||
coding: utf-8
|
||||
End:
|
||||
Loading…
Reference in New Issue