Transport Layer Security (TLS) ist das Rückgrat moderner sicherer Kommunikation im Internet. Insbesondere für Datenbanken, die oft sensible Informationen speichern und über Netzwerke zugänglich sind, stellt TLS eine unverzichtbare Schutzmaßnahme dar. Die Auswahl der richtigen TLS-Bibliothek kann dabei entscheidend sein – sowohl für die Sicherheit als auch für die Performance und Wartbarkeit der gesamten Datenbanklösung. Im Jahr 2022 wurde eine ausführliche Untersuchung verschiedener TLS-Bibliotheken in populären Open-Source-Datenbanken durchgeführt, die wertvolle Einblicke bietet und Orientierungshilfe für Entwickler liefert. Ein zentrales Ergebnis dieser Untersuchung zeigt, dass OpenSSL nach wie vor die dominierende Rolle unter den TLS-Providern einnimmt. Trotz zahlreicher bekannter Sicherheitslücken und Schwachstellen hat sich OpenSSL in den meisten Datenbankprojekten als Standard etabliert. Dabei ist beachtenswert, dass die Nutzung von OpenSSL nicht immer direkt erfolgt.
Stattdessen setzen manche Projekte auf Bibliotheken oder Frameworks, die OpenSSL transitiv verwenden, wie beispielsweise Netty oder ASIO. Einige neuere Datenbanken implementieren sogar direkt eine Schnittstelle gegen OpenSSL – ein Zeichen dafür, dass OpenSSL trotz seiner Probleme immer noch als verlässliche und weit verbreitete TLS-Bibliothek gilt. Interessanterweise sind jedoch nicht alle Open-Source-Projekte diesem Weg gefolgt. Einige Datenbanken bevorzugen alternative TLS-Bibliotheken aus Gründen der Sicherheit, Codequalität oder Wartbarkeit. So hat das Team von ScyllaDB beispielsweise die Wahl getroffen, GnuTLS zu verwenden. Laut Aussagen der Entwickler wurde diese Entscheidung anhand von Bedenken bezüglich der Codequalität und der langfristigen Wartbarkeit von OpenSSL getroffen. Diese Wahl erwies sich im Nachhinein als klug, insbesondere im Licht der vielfach aufgedeckten Sicherheitsprobleme von OpenSSL.
Eine Analyse der Alternativen zeigt, dass LibreSSL, ein Fork von OpenSSL, wegen entferntem FIPS-Support und reduzierter optimierter Assembly-Routinen bisher wenig Verbreitung in der Datenbankwelt gefunden hat. Erwarteterweise hätte BoringSSL, bekannt als Google-Fork von OpenSSL mit Fokus auf Sicherheit und schlankem Code, stärker eingesetzt werden können. Dies bleibt eine spannende Beobachtung, denn gerade bei neuen Projekten, die Wert auf wartbaren und sicheren Code legen, wäre BoringSSL eine attraktive Option. Neben den klassischen C-basierten TLS-Implementierungen gibt es im Kontext moderner Programmiersprachen zudem nativ implementierte Lösungen. Dies ist besonders prominent bei Java und Go der Fall. Beide Sprachen besitzen eigene TLS-Stacks, die in ihren Ökosystemen weit verbreitet und etabliert sind. Der Einsatz dieser nativen TLS-Lösungen erleichtert die Entwicklung, da sie keine externe C-Abhängigkeit mit sich bringen und gut in die Sprachökosysteme integriert sind.
Go etwa vermeidet bewusst den Einsatz von cgo, um Plattformunabhängigkeit und einfachere Kompilierung zu gewährleisten. Netty, ein weit verbreitetes Netzwerkframework für Java, favorisiert wider Erwarten trotzdem häufig OpenSSL gegenüber dem TLS-Stack des JDK. Dies liegt wohl an speziellen Anforderungen oder Optimierungen, welche OpenSSL bietet. Andererseits setzen viele Java-Datenbanken, darunter Elasticsearch und Neo4j, primär auf das JDK-interne TLS, was die Vorteile einer nativen Lösung zeigt. Die Entscheidung für eine Bibliothek ist also stark kontextabhängig und hängt sowohl von Performance-Erwägungen als auch von Wartungsaspekten ab. Die Studie enthält eine umfangreiche Übersicht über die TLS-Bibliothek der wichtigsten populären Datenbanken. MySQL, PostgreSQL, MongoDB, Redis, Cassandra und viele andere setzen überwiegend auf OpenSSL. Dabei variieren die konkreten Integrationsformen von direkter Anbindung bis zur transitive Nutzung über andere Frameworks.
MariaDB fällt durch die Verwendung von WolfSSL auf – eine kommerzielle TLS-Bibliothek, die besonders für eingebettete Systeme optimiert ist. Ebenfalls interessant ist der Einsatz von GnuTLS bei ScyllaDB und die Generallösung von FoundationDB, das neben OpenSSL auch LibreSSL, BoringSSL und WolfSSL unterstützt – ein Zeichen für Flexibilität und die Möglichkeit, je nach Szenario die beste TLS-Option wählen zu können. Für Entwickler, die vor der Entscheidung stehen, welche TLS-Bibliothek sie für eine neue Datenbank oder ein datenbankähnliches Projekt verwenden sollten, liefert die Analyse wertvolle Empfehlungen. Grundsätzlich wird geraten, vorrangig auf die TLS-Implementierung des jeweiligen RPC-, Netzwerk- oder Event-Loop-Providers zurückzugreifen. Beispiele hierfür sind ASIO mit seiner TLS-Unterstützung oder Netty mit seiner SSL-Anbindung. Diese Lösungen sparen Entwicklungsaufwand und profitieren von der engen Verzahnung mit den jeweiligen Frameworks.
Steht keine solche Lösung zur Verfügung, empfehlen sich native TLS-Bibliotheken der jeweiligen Programmiersprache, etwa JDK-TLS bei Java oder die crypto/tls-Bibliothek in Go. Diese sind gut gewartet, sicher und bieten meist eine solide Performance. Als Alternative für speziellere Fälle wird die Kombination von libtls mit LibreSSL vorgeschlagen. LibreSSL eignet sich als moderne OpenSSL-Alternative mit Fokus auf Sicherheit, auch wenn sie in Benchmarks tendenziell langsamer ist als OpenSSL. Sobald aber die Performance-Anforderungen steigen und LibreSSL zu langsam wird, kann ein Wechsel zu libretls in Betracht gezogen werden, einer hochperformanten TLS-Bibliothek, die aus LibreSSL entstanden ist. Wenn es unumgänglich ist, OpenSSL direkt zu verwenden, sollte die Verwendung von BoringSSL in Erwägung gezogen werden. BoringSSL bietet einen schlankeren, wartbaren und sicherheitsorientierten Codebasis, der von Google stetig gepflegt wird und viele Probleme von OpenSSL beseitigt.
Darüber hinaus existieren weitere TLS-Implementierungen, die für spezielle Anwendungsfälle eine Rolle spielen können. BearSSL zum Beispiel ist für eingebettete Systeme interessant, insbesondere wenn das Budget keinen kommerziellen Anbieter wie WolfSSL zulässt. Die Bibliothek „Not Quite So Broken“ (libnqsb-tls) kann Sinn machen, wenn es unter keinen Umständen möglich ist, TLS-Bibliotheken nachträglich zu patchen. Diese Nischenlösungen kommen allerdings eher selten zum Einsatz und sind daher nur für Spezialfälle relevant. Ein wesentliches Ergebnis der Untersuchung ist, dass die Wahl der TLS-Bibliothek eng mit der Sprache, dem Netzwerk-Stack und der Architektur der Datenbanklösung verknüpft ist. Es existiert kein universeller Standard für alle Projekte. Sicherheit, Wartbarkeit und Performance stehen dabei immer im Spannungsverhältnis zueinander.
Die Entwickler müssen sorgfältig abwägen, ob sie die bestmögliche Sicherheit und Codequalität priorisieren oder besondere Performance-Optimierungen anstreben. Zudem spielt die Wartbarkeit eine bedeutende Rolle, insbesondere bei langfristigen Projekten, die regelmäßig auf neue Sicherheitslücken reagieren müssen. In Anbetracht der zahlreichen Sicherheitsvorfälle in den letzten Jahren bietet die Wahl einer gut gewarteten und modernen TLS-Bibliothek einen erheblichen Vorteil. Projekte wie BoringSSL zeigen, wie sich Traditionsbibliotheken verbessern lassen. Gleichzeitig demonstriert GnuTLS, dass alternative Ansätze mit Fokus auf stabile Codequalität erfolgreich sein können, wie am Beispiel von ScyllaDB zu sehen ist. Für die Zukunft ist zu erwarten, dass sich die TLS-Landschaft in Datenbanken weiter diversifizieren wird.
Neue Projekte könnten verstärkt auf native TLS-Bibliotheken der jeweiligen Programmiersprachen setzen, was die Entwicklung vereinfacht und die Abhängigkeit von Sicherheitslücken in externem C-Code reduziert. Gleichzeitig behalten etablierte und bewährte Bibliotheken wie OpenSSL und deren Forks eine wichtige Rolle, da sie über umfangreiche Funktionen und breite Unterstützung verfügen. Zusammenfassend liefert die 2022 durchgeführte Umfrage einen idealen Ausgangspunkt, um sich als Entwickler in der komplexen Welt der TLS-Bibliotheken zurechtzufinden. Jedes Projekt sollte seine Anforderungen an Sicherheit, Leistung und Wartbarkeit genau analysieren und die am besten geeignete TLS-Lösung auswählen, um den langfristigen Erfolg und die Sicherheit der Datenbank zu gewährleisten.
