This PEP proposes for CPython’s standard library to support only OpenSSL1.1.1 LTS or newer. Support for OpenSSL versions past end-of-lifetime,incompatible forks, and other TLS libraries are dropped.
Python makes use of OpenSSL inhashlib,hmac, andssl modules. OpenSSLprovides fast implementations of cryptographic primitives and a full TLSstack including handling of X.509 certificates. Thessl module is used bystandard library modules likeurllib and 3rd party modules likeurllib3to implement secure variants of internet protocols.pip uses thesslmodule to securely download packages from PyPI. Any bug in thessl module’sbindings to OpenSSL can lead to a severe security issue.
Over time OpenSSL’s public API has evolved and changed. Version 1.0.2introduced new APIs to verify and match hostnames. OpenSSL 1.1.0 madeinternal structs opaque and introduced new APIs that replace direct access ofstruct members. Version 3.0.0 will deprecate more APIs due to internalreorganization that moves cryptographic algorithms out of the core and intoproviders. Forks like LibreSSL and BoringSSL have diverged in differentdirections.
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.1with some missing features and broken tests.
Due to limited resources and time it becomes increasingly hard to supportmultiple versions and forks as well as test and verify correctness. Besidesmultiple incompatible APIs there are build time flags,distribution-specific patches, and local crypto-policy settings that add toplethora of combinations. On the other hand, the Python core team has onlya couple of domain experts who are familiar with TLS and OpenSSL internalsand even fewer who are active maintainers.
Requiring OpenSSL 1.1.1 would allow us to give the vast majority of users abetter experience, reduce our maintenance overhead and thus free resourcesto implement new features. Users would be able to rely on the presence ofnew features and consistent behavior, ultimately resulting in a more robustexperience.
OpenSSL 1.1.1 is the default variant and version of OpenSSL on almost allsupported platforms and distributions. It’s also the only version that stillreceives security support from upstream[9].
No macOS and Windows user will be affected by the deprecation. The python.orginstaller and alternative distributions like Conda ship with most recentOpenSSL version.
As of October 2020 and according to DistroWatch[1] most current BSD andLinux distributions ship with OpenSSL 1.1.1 as well. Some older releases oflong-term support (LTS) and enterprise distributions have older versions ofOpenSSL or LibreSSL. By the time Python 3.10 will be generally available,several of these distributions will have reached end of lifetime, end ofgeneral 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.
released: 2015-02end of lifetime: 2019-12
OpenSSL 1.0.2 added hostname verification, ALPN support, and elliptic curves.
released: 2016-08end of lifetime: 2019-09
OpenSSL 1.1.0 removed or disabled insecure ciphers by default and addedsupport for ChaCha20-Poly1305, BLAKE2 (basic features), X25519 and CT. Themajority of structs were made opaque and new APIs were introduced. OpenSSL1.1.0 is not API compatible with 1.0.2.
released: 2018-08end of lifetime: 2023-09 (planned)
OpenSSL 1.1.1 added TLS 1.3, SHA-3, X448 and Ed448.
Major CI providers provide images with OpenSSL 1.1.1.
Ubuntu2004)cimg/base:stable orcimg/base:stable-20.04)runs-on:ubuntu-20.04)dist:focal)released: n/a (planned for mid/late 2021)
OpenSSL 3.0.0 is currently under development. Major changes includerelicensing to Apache License 2.0 and a new API for cryptographic algorithmsproviders. Most changes are internal refactorings and don’t affect publicAPIs.[8]
created: 2014-04 (forked from OpenSSL 1.0.1g)
Some distributions like FreeBSD and OPNsense also feature LibreSSLinstead of OpenSSL as non-standard TLS libraries. Gentoo discontinuedLibreSSL as an alternative to OpenSSL in January 2021[10] due tocompatibility issues and little testing.
OpenBSD ports has a portsecurity/openssl/1.1 which is documented as“[…] is present to provide support for applications which cannot be madecompatible with LibReSSL”[7]. The package could be used by OpenBSD toprovide a working ssl module.
created: 2014-06
BoringSSL is Google’s fork of OpenSSL. It’s not intended for general use andtherefore not supported by Python. There are no guarantees of API or ABIstability. Vendored copies of BoringSSL are used in Chrome/Chromium browser,Android, and on Apple platforms[6].
OpenSSL 1.1.1 introduced support for the new TLS 1.3 version. The latestversion of the TLS protocol has a faster handshake and is more secure thanthe previous versions.
Starting with release 1.1.0c, OpenSSL is fully fork and thread safe.Bindings no longer need any workarounds or additional callbacks to supportmultithreading.
Since 1.1.0, OpenSSL ships with SHA-3 and SHAKE implementations.Python’s builtin SHA-3 support is based on the reference implementation. Theinternal_sha3 code is fairly large and the resulting shared library closeto 0.5 MB. Python could drop the builtin implementation and rely on OpenSSL’slibcrypto instead.
So far LibreSSL upstream development has refused to add SHA-3 support.[2]
OpenSSL features more than 70 configure and build time options in the formofOPENSSL_NO_* macros. Around 60 options affect the presence of featureslike cryptographic algorithms and TLS versions. Some distributions applypatches to alter settings. Furthermore, default values for settings likesecurity level, ciphers, TLS version range, and signature algorithms canbe 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 havestandard features enabled. Vendors shall disable deprecated or insecurealgorithms and TLS versions with build time options likeOPENSSL_NO_TLS1_1_METHOD or OpenSSL config options likeMinProtocol=TLSv1.2.
Python assumes that OpenSSL is built with
Weak algorithms (MD5, SHA-1 signatures) and short keys (RSA < 2024 bits) maybe disabled at runtime. Algorithms may also be blocked when they aredisabled by a crypto policy such as FIPS. The PEP is not more specific onpurpose to give room for new features as well as countermeasures againstvulnerabilities. As a rule of thumb, Python should be able to connect toPyPI and the test suite should pass.
LibreSSL is a fork of OpenSSL. The fork was created off OpenSSL 1.0.1g bymembers of the OpenBSD team in 2014 in light of the heartbleed vulnerability.Since its inception several features deemed problematic or insecure wereremoved or replaced (SSL 2.0, SSL 3.0, improved CPRNG) or backportedfrom OpenSSL and BoringSSL.
At the moment LibreSSL is not fully API compatible with OpenSSL 1.1.1. Thelatest release LibreSSL 3.3.2 is missing features and behaves differentlyin some cases. Mentionable missing or incompatible features include
SSL_CERT_* environment variablesThis PEP proposed to remove any and all LibreSSL related workarounds fromPython. In the future Python will not actively prohibit LibreSSL supportwith configure and compile time checks. But Python will not accept patchesthat add non-trivial workarounds or disable tests either.
There are currently no plans to support BoringSSL.
This PEP does not provide a set of formal rules and conditions under whichan OpenSSL version is supported.
In general Python aims to be compatible with commonly used and officiallysupported OpenSSL versions. Patch releases of Python may not be compatiblewith new major releases of OpenSSL. Users should not expect that a new majoror minor release of Python works with an OpenSSL version that is past itsend-of-lifetime. Python core development may backport fixes for new releasesor extend compatibility with EOLed releases as we see fit.
The new ABI stability and LTS policies of OpenSSL[9] should help, too.
It was suggested to keep support for OpenSSL 1.1.0 for compatibility withDebian 9 (Stretch). The proposal was rejected since it would complicated codecleanup and testing. Stretch is already out of regular security support andclose to end of long-term support. By the time of Python 3.10 final release,Debian Buster and Debian Bullseye will be available.
Instead Python 3.10 will gain additional documentation and a newconfigure option--with-openssl-rpath=auto to simplify use of customOpenSSL builds[11].
Python 3.10 will no longer support TLS/SSL and fast hashing on platformswith OpenSSL 1.0.2 or LibreSSL. The first draft of this PEP was published atthe beginning of the 3.10 release cycles to give vendors like Linuxdistributors or CI providers sufficient time to plan.
Python’s internal copy of theKeccak Code Package and the internal_sha3 module will be removed. This will reduce source code size byabout 280kB and code size by roughly 0.5MB. Thehashlib will solely relyon OpenSSL’s SHA-3 implementation. SHA-3 and SHAKE will no longer be availablewithout OpenSSL.
The author of this PEP is a contributor to OpenSSL project and employed bya 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.
This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.
Source:https://github.com/python/peps/blob/main/peps/pep-0644.rst
Last modified:2025-02-01 08:55:40 GMT