OpenSSL 1.0.2 LTS

veröffentlicht: 2015-02 Ende der Lebensdauer: 2019-12

OpenSSL 1.0.2 fügte Hostname-Verifizierung, ALPN-Unterstützung und elliptische Kurven hinzu.

• CentOS 7 (EOL 2024-06)
• Debian 8 Jessie (EOL 2020-07)
• Linux Mint 18.3 (EOL 2021-04)
• RHEL 7 (voller Support endet 2019-08, Wartung 2 Support endet 2024-06)
• SUSE Enterprise Linux 12-SP5 (allgemeiner Support endet 2024-10)
• Ubuntu 16.04 LTS / Xenial (allgemeiner Support endet 2021-04)

OpenSSL 1.1.0

veröffentlicht: 2016-08 Ende der Lebensdauer: 2019-09

OpenSSL 1.1.0 hat unsichere Cipher standardmäßig entfernt oder deaktiviert und Unterstützung für ChaCha20-Poly1305, BLAKE2 (Basisfunktionen), X25519 und CT hinzugefügt. Die Mehrheit der Strukturen wurde undurchsichtig gemacht und neue APIs wurden eingeführt. OpenSSL 1.1.0 ist nicht API-kompatibel mit 1.0.2.

• Debian 9 Stretch (Sicherheitssupport endete 2020-07, LTS bis 2022-06)
• Ubuntu 18.04 LTS / Bionic (allgemeiner Support endet 2023-04)

OpenSSL 1.1.1 LTS

veröffentlicht: 2018-08 Ende der Lebensdauer: 2023-09 (geplant)

OpenSSL 1.1.1 fügte TLS 1.3, SHA-3, X448 und Ed448 hinzu.

• Alpine (wechselte 2018 zurück zu OpenSSL [4])
• Arch Linux aktuell
• CentOS 8.0+
• Debian 10 Buster
• Debian 11 Bullseye (ETA 2021-06)
• Fedora 29+
• FreeBSD 11.3+
• Gentoo Linux stabil (stellte LibreSSL im Januar 2021 als Alternative ein [10])
• HardenedBSD (wechselte 2018 zurück zu OpenSSL [3])
• Linux Mint 19.3+
• macOS (python.org Installer)
• NetBSD 8.2+
• openSUSE 15.2+
• RHEL 8.0+
• Slackware aktuell
• SUSE Enterprise Linux 15-SP2
• Ubuntu 18.10+
• Ubuntu 20.04 LTS / Focal
• VoidLinux (wechselte im März 2021 zurück zu OpenSSL [5])
• Windows (python.org Installer, Conda)

Wichtige CI-Anbieter stellen Images mit OpenSSL 1.1.1 bereit.

• AppVeyor (mit Image Ubuntu2004)
• CircleCI (mit aktuellem cimg/base:stable oder cimg/base:stable-20.04)
• GitHub Actions (mit runs-on: ubuntu-20.04)
• GitLab CI (mit Debian Stretch, Ubuntu Focal, CentOS 8, RHEL 8 oder Fedora Runner)
• Packit
• TravisCI (mit dist: focal)
• Zuul

OpenSSL 3.0.0

veröffentlicht: n/a (geplant für Mitte/Ende 2021)

OpenSSL 3.0.0 befindet sich derzeit in der Entwicklung. Zu den wichtigsten Änderungen gehören die Neulizensierung unter der Apache-Lizenz 2.0 und eine neue API für Provider kryptografischer Algorithmen. Die meisten Änderungen sind interne Refactorings und beeinträchtigen die öffentlichen APIs nicht [8].

LibreSSL

erstellt: 2014-04 (geforkt von OpenSSL 1.0.1g)

• DragonFly BSD
• Hyperbola GNU/Linux-libre
• OpenBSD
• OpenELEC (eingestellt)
• TrueOS (eingestellt)

Einige Distributionen wie FreeBSD und OPNsense verwenden statt OpenSSL LibreSSL als nicht-standardmäßige TLS-Bibliotheken. Gentoo hat LibreSSL im Januar 2021 aufgrund von Kompatibilitätsproblemen und geringem Testaufwand als Alternative zu OpenSSL eingestellt [10].

OpenBSD-Ports hat einen Port security/openssl/1.1, der dokumentiert ist als „[...] ist vorhanden, um Anwendungen zu unterstützen, die nicht mit LibReSSL kompatibel gemacht werden können“ [7]. Das Paket könnte von OpenBSD verwendet werden, um ein funktionierendes SSL-Modul bereitzustellen.

BoringSSL

erstellt: 2014-06

BoringSSL ist Googles Fork von OpenSSL. Er ist nicht für den allgemeinen Gebrauch bestimmt und wird daher von Python nicht unterstützt. Es gibt keine Garantien für API- oder ABI-Stabilität. Eingebundene Kopien von BoringSSL werden im Chrome/Chromium-Browser, Android und auf Apple-Plattformen verwendet [6].

TLS 1.3

OpenSSL 1.1.1 führte die Unterstützung für die neue TLS 1.3-Version ein. Die neueste Version des TLS-Protokolls hat einen schnelleren Handshake und ist sicherer als die Vorgängerversionen.

Thread- und Fork-Sicherheit

Ab der Version 1.1.0c ist OpenSSL vollständig fork- und thread-sicher. Bindings benötigen keine Workarounds oder zusätzlichen Callbacks mehr zur Unterstützung von Multithreading.

SHA-3

Seit 1.1.0 liefert OpenSSL SHA-3- und SHAKE-Implementierungen aus. Pythons integrierte SHA-3-Unterstützung basiert auf der Referenzimplementierung. Der interne Code _sha3 ist recht groß und die resultierende Shared Library fast 0,5 MB. Python könnte die integrierte Implementierung fallen lassen und sich stattdessen auf die libcrypto von OpenSSL verlassen.

Bisher hat die LibreSSL-Upstream-Entwicklung die Hinzufügung von SHA-3-Unterstützung verweigert [2].

OpenSSL-Downstream-Patches und Optionen

OpenSSL verfügt über mehr als 70 Konfigurations- und Build-Zeit-Optionen in Form von OPENSSL_NO_* Makros. Etwa 60 Optionen beeinflussen das Vorhandensein von Funktionen wie kryptografischen Algorithmen und TLS-Versionen. Einige Distributionen wenden Patches an, um Einstellungen zu ändern. Darüber hinaus können Standardwerte für Einstellungen wie Sicherheitsstufe, Cipher, TLS-Versionen und Signaturalgorithmen in der OpenSSL-Konfigurationsdatei festgelegt werden.

Dem Python-Kernteam fehlen die Ressourcen, um alle möglichen Kombinationen zu testen. Diese PEP schlägt vor, dass Python nur OpenSSL-Builds unterstützt, bei denen Standardfunktionen aktiviert sind. Anbieter sollen veraltete oder unsichere Algorithmen und TLS-Versionen mit Build-Zeit-Optionen wie OPENSSL_NO_TLS1_1_METHOD oder OpenSSL-Konfigurationsoptionen wie MinProtocol = TLSv1.2 deaktivieren.

Python geht davon aus, dass OpenSSL kompiliert wurde mit

• Standardalgorithmen von hashlib wie MD5, SHA-1, SHA-2-Familie, SHA-3/SHAKE-Familie, BLAKE2
• TLS 1.2- und TLS 1.3-Protokolle
• aktuelle Schlüsselvereinbarungs-, Signatur- und Verschlüsselungsalgorithmen für TLS 1.2 und 1.3 (ECDH, RSA, ECDSA, Curve25519, AES, Poly1309-ChaCha20, ...)
• Threading, Datei-I/O, Socket-I/O und Fehlermeldungen

Schwache Algorithmen (MD5, SHA-1-Signaturen) und kurze Schlüssel (RSA < 2024 Bit) können zur Laufzeit deaktiviert werden. Algorithmen können auch blockiert werden, wenn sie durch eine Krypto-Richtlinie wie FIPS deaktiviert sind. Die PEP ist absichtlich nicht spezifischer, um Raum für neue Funktionen sowie Gegenmaßnahmen gegen Schwachstellen zu geben. Als Faustregel sollte Python in der Lage sein, sich mit PyPI zu verbinden, und die Testsuite sollte erfolgreich durchlaufen.

LibreSSL-Unterstützung

LibreSSL ist ein Fork von OpenSSL. Der Fork wurde 2014 im Lichte der Heartbleed-Schwachstelle aus OpenSSL 1.0.1g von Mitgliedern des OpenBSD-Teams erstellt. Seit seiner Einführung wurden mehrere als problematisch oder unsicher eingestufte Funktionen entfernt oder ersetzt (SSL 2.0, SSL 3.0, verbesserter CPRNG) oder von OpenSSL und BoringSSL zurückportiert.

Derzeit ist LibreSSL nicht vollständig API-kompatibel mit OpenSSL 1.1.1. Die neueste Version LibreSSL 3.3.2 fehlen Funktionen und verhält sich in einigen Fällen anders. Erwähnenswerte fehlende oder inkompatible Funktionen sind:

• SHA-3, SHAKE, BLAKE2
• SSL_CERT_* Umgebungsvariablen
• Sicherheitslevel-APIs
• Session-Handling-APIs
• Key-Logging-API
• verifizierte Zertifikatsketten-APIs
• OPENSSL_VERSION Makro

Diese PEP schlug vor, alle LibreSSL-bezogenen Workarounds aus Python zu entfernen. Zukünftig wird Python LibreSSL-Unterstützung nicht mehr aktiv mit Konfigurations- und Kompilierungsprüfungen verhindern. Python wird jedoch keine Patches akzeptieren, die nicht-triviale Workarounds hinzufügen oder Tests deaktivieren.

BoringSSL

Derzeit sind keine Pläne zur Unterstützung von BoringSSL vorhanden.

Formale Festlegung der unterstützten OpenSSL-Versionen

Diese PEP stellt keine formellen Regeln und Bedingungen auf, unter denen eine OpenSSL-Version unterstützt wird.

Im Allgemeinen strebt Python die Kompatibilität mit gängigen und offiziell unterstützten OpenSSL-Versionen an. Patch-Releases von Python sind möglicherweise nicht mit neuen Hauptversionen von OpenSSL kompatibel. Benutzer sollten nicht davon ausgehen, dass eine neue Haupt- oder Nebenversion von Python mit einer OpenSSL-Version funktioniert, die ihr Lebensende überschritten hat. Die Kernentwicklung von Python kann nach eigenem Ermessen Korrekturen für neue Versionen zurückportieren oder die Kompatibilität mit EOL-Versionen erweitern.

Die neuen ABI-Stabilitäts- und LTS-Richtlinien von OpenSSL [9] sollten ebenfalls hilfreich sein.

Unterstützung für OpenSSL 1.1.0 beibehalten

Es wurde vorgeschlagen, die Unterstützung für OpenSSL 1.1.0 aus Kompatibilitätsgründen mit Debian 9 (Stretch) beizubehalten. Der Vorschlag wurde abgelehnt, da er die Codebereinigung und Tests erschwert hätte. Stretch hat bereits den regulären Sicherheitssupport überschritten und steht kurz vor dem Ende des Long-Term-Supports. Bis zur endgültigen Veröffentlichung von Python 3.10 werden Debian Buster und Debian Bullseye verfügbar sein.

Stattdessen erhält Python 3.10 zusätzliche Dokumentation und eine neue Konfigurationsoption --with-openssl-rpath=auto, um die Verwendung benutzerdefinierter OpenSSL-Builds zu vereinfachen [11].