OpenSSL: Legacy-Provider systemweit aktivieren

In OpenSSL 3.0 wurden zahlreiche als veraltet oder unsicher geltende Algorithmen entfernt. Doch einige Software ist auf diese Algorithmen weiterhin angewiesen. Dieses Mini-Tutorial zeigt, wie man sie wieder aktiviert.

· 3 Minuten zu lesen
🇬🇧
This article is also available in English.

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
⚠️
Der Legacy-Provider von OpenSSL ist in allen dem Autor vertrauten Distributionen unabhängig von dem in crypto-policies enthaltenen Krypto-Policy-Profil "LEGACY", welches mittels 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.