Wegweiser duch Crypto-Bibliotheken und -Services

© schiffner, Photocase

Im Dickicht

Der Einsatz von Crypto-Bibliotheken kann manchmal etwas umständlich sein. Dass hiervon gleich eine ganze Handvoll existieren, erleichert die Sache nicht unbedingt. Der folgende Artikel versucht, ein wenig Licht ins Dunkel zu bringen und erklärt den Einsatz der Network Security Services (NSS) und OpenSSL im Zusammenhang mit X.509-Zertifikaten.
RAID-Technologie verspricht höhere Performance und mehr Sicherheit beim permanenten Speichern von Daten. Die ADMIN-Redaktion gibt einen Überblick über ... (mehr)

Linux lässt einem bei nahezu allem die Wahl zwischen einer Vielzahl von Alternativen, warum sollte dies also bei Crypto-Frameworks anders sein? Auf proprietären Systemen hat man sich meistens auf ein bestimmtes Framework festgelegt (beispielsweise die CryptoAPI bei Microsoft Windows) und passt die Standard-Applikationen daraufhin an, bei Linux existieren neben den bekannten OpenSSL und den Network Security Services auch noch BeeCrypt, Cyrus SASL, libgcrypt, GnuTLS und diverse andere Implementierungen.

Große Auswahl

Dabei versuchen nahezu alle Frameworks das gleiche Problem zu lösen oder ähnliche Lösungen für bestimmte Anwendungsfälle anzubieten, also beispielsweise eine Implementierung für das TLS/SSL-Protokoll, für S/MIME, für Crypto-Algorithmen und Hash-Funktionen, Zufallszahlen-Generatoren und Ähnliches. Hier den Überblick zu behalten, ist nicht wirklich einfach. Zumal es dem Entwickler einer Anwendung natürlich freigestellt ist, welches Crypto-Framework er für seine Applikation verwendet. Ob die Auswahl des Frameworks auf dem System, auf dem die Anwendung einmal laufen wird, zu Problemen führt, ist nicht wirklich sichergestellt.

Ein kleines Beispiel: Die Anwendung nutzt die Network Security Services und erwartet Benutzerzertifikate in einem Berkley-DB basierten Zertifikatsspeicher. Der Benutzer hat sein X.509-Zertifikat aber als PEM-codierte Datei auf dem Dateisystem liegen und weiß nichts von einer Berkley-DB. Hier ist erst einmal etwas Handarbeit gefragt, bevor schließlich das Benutzerzertifikat als PKCS#12 Datei in die Berkely-DB geschoben werden kann. Das Fedora-Projekt hat sich vor einiger Zeit zum Ziel gesetzt, diesen Wildwuchs etwas einzudämmen und ein Crypto-Framework gesucht, das einen breiten Funktionsumfang, hohe Portabilität und ein flexibles Lizenzierungsmodell bietet. Betrachtet man die Anforderungen, so kommen hierfür eigentlich nur OpenSSL und die Network Security Services (NSS) infrage.

OpenSSL ist in der OpenSource-Community sehr gut bekannt und hat die erste OpenSource-Implementierung für SSL zur Verfügung gestellt, hat einen hohen Verbreitungsgrad auf Unix-artigen Systemen und verwendet ein duales Lizenzierungsmodell – es kommen die BSD-artigen Lizenzen SSLeay und OpenSSL zum Einsatz. NSS ist das ältere Framework und hat von Haus aus einen höheren Funktionsumfang als OpenSSL. Der Zertifikatsspeicher besteht aus einer Berkeley-Datenbank, anders als bei OpenSSL, wo Zertifikate in regulären Dateien abgelegt sind. NSS verwendet ein dreistufiges Lizenzierungsmodell, bestehend aus der Mozilla, der GNU General und der GNU Lesser General Public License.

OpenSSL oder NSS

Heute setzt der Großteil der Fedora-Applikationen NSS als Crypto-Framework ein, andere Anwendungen benutzen OpenSSL oder lassen dem Benutzer die Wahl zwischen dem einen oder dem anderen Framework. Ein gutes Beispiel hierfür ist der bekannte Webserver Apache. TLS/SSL-Support stellt dieser seit jeher über das Modul »mod_ssl« zur Verfügung. Vor einiger Zeit bereits wurde daneben das Modul »mod_nss« für den Einsatz der Network Security Services entwickelt. Dem Admin steht es frei, das eine oder das andere Modul einzusetzen. Ähnlich ist es auch auf der Client-Seite. OpenLDAP kann beispielsweise mit OpenSSL-basierten, aber auch mit NSS-Zertifikaten umgehen. Das Ziel ist dabei, immer mehr Applikationen auf NSS umzustellen. Bis es so weit ist, sollte man also mit beiden Frameworks umgehen können. Besonders interessant ist hierbei die Verwaltung von X.509-Zertifikaten. Die folgenden Beispiele geben eine kurze Einführung in die verfügbaren Tools der beiden Frameworks und wie sich mit deren Hilfe, Zertifikate sowohl von NSS als auch von OpenSSL nutzen lassen.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023