OpenSSL 3.0 entfernt Algorithmen
Mit Veröffentlichung von Version 3.0 wurden diverse symmetrische Chiffren, Hashing-Algorithmen und Schlüsselableitungsfunktionen aus dem Standardumfang von OpenSSL entfernt, welche allgemein als veraltet, nicht mehr zeitgemäß oder unsicher gelten, und heute üblicherweise nicht mehr verwendet werden.
Betroffen sind die symmetrischen Chiffren der Algorithmen Blowfish, RC4, RC2, DES, CAST, IDEA, SEED, sowie der ohnehin auch bislang nur auf Anforderung einkompilierte Algorithmus RC5, die Hashing-Algorithmen RIPEMD160, MD4, MD2, MDC2 und Whirlpool, sowie die Schlüsselableitungsfunktion PBKDF1.
Doch im Alltag kommt es immer wieder zu Situationen, in denen diese betagten Algorithmen doch noch benötigt werden, zu erkennen an Fehlermeldungen wie dieser:
$ openssl enc -pbkdf2 -des-cbc -pass 'pass:test1234' </dev/null; echo
Error setting cipher DES-CBC
80020D0BB57F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:355:Global default library context, Algorithm (DES-CBC : 15), Properties ()
Salted__� 7�aM�
OpenSSL 3.0 führt Provider ein
Die betroffenen Algorithmen sind aber nicht gänzlich verschwunden, sie wurden in OpenSSL 3.0 und neuer lediglich vom standardmäßig aktiven Default-Provider in den neuen Legacy-Provider verschoben.
Die geladenen und aktiven Provider lassen sich mittels openssl list -providers
anzeigen:
$ openssl list -providers
Providers:
default
name: OpenSSL Default Provider
version: 3.2.1
status: active
Einige aktuelle Software ist sich des mit OpenSSL 3.0 eingeführten Provider-Konzepts bewusst und bietet die Möglichkeit, den Legacy-Provider zu aktivieren. So erlaubt bspw. Node.js bereits seit Version 17, den Legacy-Provider mittels des Befehlzeilenparameters --openssl-legacy-provider
zu aktivieren, und auch solche OpenSSL-eigene Unterbefehle, welche regelmäßig mit Legacy-Algorithmen in Kontakt kommen, bringen entsprechende Parameter mit (bspw. openssl pkcs12 -legacy
).
Leider ist jedoch die meiste Software, die mit derart veralteten Algorithmen hantiert, tendenziell ebenfalls oft betagt, oder zumindest eher schlecht gewartet. Und so sind derartige Einstellungsmöglichkeiten gerade in diesen Fällen eher rar gesät.
Systemweite Aktivierung des Legacy-Providers
Ist eine Software weder über Parameter noch Konfiguration zur Nutzung des Legacy-Providers zu bewegen, und die Möglichkeit einer Code-Anpassung liegt irgendwo zwischen überfordernd und den Aufwand nicht wert, so bleibt nur noch die Möglichkeit, den Legacy-Provider systemweit zu aktivieren.
Dem Systemverantwortlichen muss dabei natürlich bewusst bleiben, dass dieser Schritt die System- und Datensicherheit negativ beeinflussen kann, und weitere Überprüfungen wie bspw. der oft applikations- oder dienstweise konfigurierten und somit von den Systemeinstellungen abweichenden Ciphersuites für ein- und ausgehende TLS-Verbindungen, sind anzuraten.
Variante 1: Systeme mit crypto-policies
Unter den Linux-Distributionen erlauben Fedora seit Version 21, RHEL und RHEL-basierte Distributionen seit Version 8, Ubuntu seit Version 20.04 LTS, Debian derzeit zumindest in sid/unstable, openSUSE Tumbleweed seit 20201216, SLE und openSUSE Leap seit Version 15.4, und auch viele andere Distributionen eine systemweite Konfiguration der Kryptographie aller wichtiger Systemkomponenten mittels Fedora crypto-policies.
Eigentlich dient crypto-policies dazu, das System auf eines der mitgelieferten oder nachinstallierten Krypto-Policy-Profile umzukonfigurieren, eine insbesondere für Unternehmen wichtige Funktion zum Rollout unternehmensweit einheitlicher Konfiguration oder Umsetzung gesetzlicher Anforderungen.
Allerdings erlaubt crypto-policies es auch, individuelle Konfigurations-Snippets mit dem gewählten Policy-Profil zusammenzuführen, was wir uns hier zunutze machen wollen.
Zunächst schreiben wir ein neues Konfigurations-Snippet zur Zusammenführung mit der OpenSSL-Konfiguration nach /etc/crypto-policies/local.d/opensslcnf-enable_legacy_provider.config
, und führen anschließend als root update-crypto-policies --set
ohne Angabe eines Policy-Profils aus (das bisherige Profil wird beibehalten).
$ sudo cp /dev/stdin /etc/crypto-policies/local.d/opensslcnf-enable_legacy_provider.config <<__EOF
[provider_sect]
legacy = legacy_sect
[legacy_sect]
activate = 1
__EOF
$ sudo update-crypto-policies --set
update-crypto-policies --set LEGACY
aktiviert werden kann. Auch das Profil "LEGACY" kommt mit Implikationen für die System- und Datensicherheit und sollte nur aktiviert werden, wenn dies notwendig ist und die Auswirkungen verstanden sind.Variante 2: Systeme ohne crypto-policies
Ist eine Konfiguration mittels crypto-policies nicht möglich oder unerwünscht, so kann die OpenSSL-Konfigurationsdatei openssl.cnf
direkt angepasst werden.
Diese befindet sich bei Linux je nach Distribution meist unter /etc/pki/tls/
oder /etc/ssl/
, unter macOS findet man sie unter /System/Library/OpenSSL/
(sowie ggf. die einer MacPorts-Installation unter /usr/local/etc/openssl/
).
Im Zweifelsfall hilft openssl version -a | grep ^OPENSSLDIR:
bei der Lokalisierung.
Unter Windows ist die Lokalisierung der openssl.cnf
etwas komplizierter, da fast alle Programmpakete ihre eigene Kopie von OpenSSL mitbringen.
Um den Legacy-Provider zu aktivieren, muss zunächst die TOML-Sektion [provider_sect]
um den Eintrag legacy = legacy_sect
ergänzt werden, anschließend wird eine neue Sektion [legacy_sect]
angelegt und in dieser activate = 1
gesetzt.
Ggf. sind die hier hinzuzufügenden Zeilen dort bereits in auskommentierter Form enthalten, sodass sie einfach durch Entfernen führender #
-Zeichen aktiviert werden können.
Die betreffenden Abschnitte sollten anschließend ungefähr so aussehen:
...
[provider_sect]
default = default_sect
legacy = legacy_sect
[default_sect]
activate = 1
[legacy_sect]
activate = 1
...
Überprüfung des Erfolgs
Nach erfolgter Konfiguration sollte der Legacy-Provider aufgelistet und als aktiv gekennzeichnet sein, und die veralteten Algorithmen wieder zur Verfügung stehen:
$ openssl list -providers
Providers:
default
name: OpenSSL Default Provider
version: 3.2.1
status: active
legacy
name: OpenSSL Legacy Provider
version: 3.2.1
status: active
$ openssl enc -pbkdf2 -des-cbc -pass 'pass:test1234' </dev/null; echo
Salted__`%�h��s��c3�>Z�
Alle Prozesse, welche noch mit der alten OpenSSL-Konfiguration gestartet wurden, müssen neugestartet werden, um die Einstellungen zu übernehmen – um sicherzugehen empfiehlt sich daher ein Systemneustart.