Johannes Truschnigg - SRE & DevOps


Zur Suche ▼Zum Archiv ▼

Eintrag von 2009-04-19

OpenSSL vs. GnuTLS - der Teufel steckt im Detail


Weil starke Verschlüsselung vor allem im Internet so wichtig ist, bieten fast alle Protokolle und alle Dienste eine Möglichkeit, potenziell sensitive Daten so zu übertragen, dass nur bestimme Empfänger sie auch tatsächlich lesen und verstehen können. In den allermeisten Fällen setzt man dazu heute Transport Layer Security, kurz TLS oder oft auch noch immer SSL genannt, ein. Wer sich nach einem freien TLS-Stack umsieht, stößt recht schnell auf die zwei wohl populärsten Lösungen TLS/SSL-Lösungen überhaupt: OpenSSL und GnuTLS.

OpenSSL ist schon seit vor 1999 in Entwicklung, und hat Einzug in so ziemlich jedes Projekt gefunden, das freie Software ist und (optionale) Verschlüsselung für Netzwerktransfers zulässt. Apache zum Beispiel bietet mod_ssl zur Einbindung von OpenSSL zum sicheren Ausliefern von Websites. Postfix und Exim können OpenSSL für SMTP-over-TLS nutzen, sodass E-Mails verschlüsselt über die Leitungen gehen. Diese Liste ließe sich fast beliebig lang fortsetzen.

GnuTLS ist etwas jünger als OpenSSL und hat, wie schon am Namen unschwer zu erkennen ist, seine Wurzeln im GNU-Projekt. Der Hauptgrund für die Eigenentwicklung im Rahmen von GNU ist die mit der GNU General Public License (GPL) inkompatible Lizenz von OpenSSL. Allerdings unterstützt OpenSSL auch einige ältere Versionen der SSL/TLS-Spezifikationen, die mittlerweile als unsicher und damit veraltet gelten. Diese hat man bei GnuTLS erst gar nicht implementiert; eine versehentliche Aktivierung ist damit praktischerweise ausgeschlossen.

Auch aufgrund der rechtlichen Umstände fühlen sich immer mehr Projekte - allen voran solche, die ihren Quellcode unter GPL lizenzieren - dazu bewogen, auch GnuTLS-Unterstützung als Alternative zu OpenSSL anzubieten. Keine Ausnahme bildet hier das OpenLDAP-Projekt, welches seinen LDAP-Server slapd wahlweise entweder gegen OpenSSL oder GnuTLS linkt. Und das, obwohl die OpenLDAP-Suite selbst nicht unter GPL steht.

So kommt es, dass z. B. unter Debian GNU/Linux 5.0 (Codename "Lenny") slapd gegen libgnutls.so anstatt von libssl.so linkt. Eigentlich sollte das keine große Sache sein, und keine großen Ungewohntheiten oder Veränderungen verursachen. So dachte ich auch, bis ich eines Nachmittags fast drei Stunden damit zugebracht hatte, mein TLS-geschütztes privates Adressbuch in einem LDAP-Verzeichnis unter KDE 4.2.2 in KAddressbook/Kontact einzubinden.

Um das Problem verstehen zu können, muss man die Vorgeschichte zu KDE4 und TLS kennen: Während KDE3 auf Qt Softwares Qt3-Stack aufbaut, hat man sich bei KDE4 für das deutlich moderne und komplettere Nachfolgemodell Qt4 entschieden. Leider sind diesem Umstellungsprozess einige altbekannte Features zum Opfer gefallen, welche nun - langsam, aber stetig - wiederimplementiert werden. Immer noch auf der To-Do-Liste steht zur Stunde das unter KDE3 wirklich hervorragende Zertifikatsmanagement für SSL und TLS: es ist mit KDE in Version 4.2.2 immer noch nicht möglich, das Root-Zertifikat einer Certificate Authority so zu importieren, dass es automatisch für alle KDE4-Anwendungen Gültigkeit erlangt. Unter KDE 3.5 ist alles das eine Sache weniger Mausklicks. Ebenfalls schlimm bestellt ist es um den TLS-Support in einigen etwas weniger eifrig gepflegten Winkeln von KDE, so wie etwa dem LDAP-KIO-Slave. Das geht so weit, dass in manchen (meinem persönlichen Empfinden nach sogar eher vielen) Fällen Fehlermeldungen geworfen werden, die keinen Text - oder den in etwa gleich vielsagenden "Unknown Error" - enthalten, und man beim Debuggen oft kopfschüttelnd bis ratlos dasteht.

Wie sich allerdings nach schier endlosem Hin und Her herausstellen sollte, ist der TLS-Support von KDE4 zwar keinesfalls komfortabel zu verwalten, aber zumindest funktioniert er doch. Das Problem lag nämlich an einem anderen Glied der Kette: den ldap-utils meiner Distribution (Kubuntu 9.04). Diese linken nämlich, so wie Debian-Upstream auch, gegen GnuTLS anstatt OpenSSL. Dies bedingt, dass in der Konfigurationsdatei /etc/ldap/ldap.conf der Wert für TLS_CACERTDIR ignoriert wird, während ldap-utils (unter Gentoo etwa mit libssl.so statt gnutls.so verbandelt) diesen Eintrag durchaus ernstnehmen. Als etwas schmutzigen Workaround habe ich also alle Zertifikate in /etc/ssl/certs/ zu einer einzigen Datei konkateniert, und den Pfad zu dieser Datei als Wert für TLS-CACERT angegeben. Von da an war es KAddressbook auch unter Kubuntu mit KDE4 möglich, verschlüsselt mit meinem LDAP-Server zu kommunizieren.

direkter Link ▲

© 2007-2019 Johannes Truschnigg | valid xhmtl & css