Der Heartbleed-Bug hat die Security-Community aufgeschreckt und den Ruf von Open SSL wie auch die Glaubwürdigkeit von Open Source massiv beschädigt. Mit Libre SSL steht ein Nachfolger in den Startlöchern, der vieles besser machen will. Doch auch Polar SSL und Gnu TLS haben etwas zu bieten.

In den meisten Unternehmen ist das Einspielen von Security-Updates ein erprobter Vorgang, der ohne großes Aufsehen vonstattengeht. Tatsächlich bleibt der Löwenanteil der Sicherheitslücken in der Öffentlichkeit unbemerkt; sie fliegen in Form von Security Advisories nur an den Admins vorbei. Schafft es eine Lücke aber in die Mainstream-Medien, dann darf sich der Admin sicher sein, dass es sich um ein wirklich dickes Ding handelt. Der Open-SSL-Bug Heartbleed (Abbildung 1, [1]) schaffte es in den “Spiegel”, die “FAZ” und sogar ins abendliche Wohnzimmer, weil die Tagesschau zur Prime time des Ersten Deutschen Fernsehens über ihn berichtete.

Abbildung 1: Im Zeichen des blutenden Herzens: Heartbleed erschütterte die Security- und Open-Source-Gemeinde so stark, dass der Bug sogar ein eigenes Logo bekam.

Der Blogger Felix “Fefe” von Leitner (Abbildung 2, [2]), der sich in der IT-Szene einen Namen als ein Experte für IT-Sicherheit gemacht hat, beschrieb das Heartbleed-Problem sinngemäß als GAU; andere Kommentatoren nannten den Bug “Kernschmelze der Sicherheitsarchitektur des Internets” – kurzum: Kein Superlativ war für den SSL-Fehler zu heftig.

Abbildung 2: Felix “Fefe” von Leitner sammelte in seinem Verschwörungstheorie-Blog ausführlich – bisweilen genüsslich – die Links und Status-Updates zum Heartbleed-Desaster.

Und tatsächlich ist Heartbleed in seinen Folgen kaum schlimm genug zu bewerten. Denn über eine simple Funktion, welche die meisten Clients gar nicht nutzen, die aber trotzdem in Open SSL [3] per Standardkonfiguration aktiviert ist, waren die Schlüssel, die Zertifikate, war einfach alles, was gerade zufällig im Arbeitsspeicher lag, frei auslesbar. Sowohl in Client-Server-Richtung als auch umgekehrt. Heartbleed tat richtig weh.

Ins Mark getroffen

Damit nicht genug, hinzu kommen zwei weitere, erschreckende Faktoren: Erstens tauchte der Heartbleed-Bug zur absoluten Unzeit auf. Im Jahr eins nach Edward Snowden und in Zeiten von abgehörten Kanzlerhandys entfaltet ein Problem wie Heartbleed seine eigene PR-Dynamik. Angesichts einer gewissen Hysterie glauben viele Menschen nicht mehr daran, dass ein Bug, der so effektiv alle Verschlüsselungsansätze zunichtemacht, nur ein Programmierfehler sei. Sie unterstellen dem Autor des Codes Absicht. Zwar beteuert der das Gegenteil – doch wer wollte oder könnte den Beweis für oder wider wirklich führen?

Zweitens: Heartbleed trifft die FLOSS-Community ins Mark, weil er eines ihrer zentralen Mantras scheinbar ad absurdum führt. Stets war zu hören, dass quelloffene Software sicherer sei, weil eine große Gemeinde von Entwicklern nach dem Viele-Augen-sehen-mehr-Prinzip vorgehe und Fehler so schneller auffielen. Der Code jedoch, der Heartbleed in Open SSL möglich machte, fand seinen Weg in die Bibliothek bereits im Januar 2012. Wie kann es sein, dass er so lange unbeobachtet blieb? Warnende Stimmen gab es schon länger, etwa auf der Fosdem 2014 (Abbildung 3, [4])

Abbildung 3: Bereits auf der Fosdem 2014 hatte BSD-Entwickler Poul-Henning Kamp unter dem Titel “NSA operation ORCHESTRA Annual Status Report” in seiner Keynote die Probleme von Open SSL und die möglichen Konsequenzen ausgemalt. Er sollte Recht behalten.

Admins und Entwickler hinterlässt Heartbleed jedenfalls ratlos. Zwar ist unstrittig, dass Verschlüsselung sein muss – aber ist Open SSL tatsächlich noch das Werkzeug der Wahl? Welche Alternativen stehen zur Verfügung und wie halten die es mit der Komplexität des Codes und den internen Reviews?

Dieser Artikel bietet eine Übersicht über vier Krypto-Bibliotheken, nämlich Open SSL, Libre SSL, Polar SSL und Gnu TLS und wagt eine Zusammenschau.

Open SSL: Der Oldie

Open SSL findet sich praktisch überall: Jedes Android-Telefon hat die Bibliothek eingebaut, jeder Linux-Desktop und jeder Router. Das »mod_ssl« -Modul für Apache dürfte der unangefochtene Standard sein, um Webservern SSL beizubringen; überhaupt scheint jeder Linux-Server mit mindestens einem Programm ausgestattet zu sein, das gegen Open SSL gelinkt ist. Die SSL-Implementierungen von wichtigen Werkzeugen wie Postfix und vielen anderen setzen ebenso vorrangig auf Open SSL.

Ihren Anfang nahm die Open-SSL-Entwicklung Mitte der 90er Jahre, der Auslöser hierfür waren die berüchtigten US-Exportbestimmungen für kryptographische Software. Es war damals verboten, gute und sichere Verschlüsselungssoftware aus den USA in andere Länder zu exportieren.

Was aus heutiger Sicht reichlich seltsam anmutet, weil das Internet bekanntlich keine Grenzen im geografischen Sinne mehr kennt, war für Entwickler stets eine Gratwanderung mit ungewissem Ausgang. Der Australier Eric A. Young begann deshalb mit der Arbeit an SSLeay (Abbildung 4). Weil es in Australien keine die Kryptographie einschränkende Gesetzgebung gab, stand die Toolsuite weltweit zur Verfügung.

Abbildung 4: 1998 hieß Open SSL noch SSLeay, wie ein uraltes Howto zeigt.

SSLeay, Mod_ssl und FIPS

Über einige Zeit war SSLeay quasi eine One-Man-Show, im Sommer 1998 übernahm aber ein Entwicklerteam die Pflege und sorgte dafür, dass die nun als Open SSL firmierende Software in den nächsten Jahren einen atemberaubenden Aufstieg hinlegte. Das Apache-Plugin »mod_ssl« war ein Faktor dafür, ein anderer war, dass sich das Projekt im Jahre 2006 um die FIPS-Zertifizierung bemühte.

FIPS ist vereinfacht ausgedrückt eine Vorschrift von und für US-Behörden, die die Qualität kryptographischer Software sicherstellen sollte. Konnte ein Programm eine FIPS-Zertifizierung erhalten, war es für den Einsatz auch im Behördenumfeld gewissermaßen offiziell freigegeben. Der FIPS-Standard (Abbildung 5, [5]) kommt vom National Institute of Standards and Technology (NIST).

Abbildung 5: Das FIPS-Logo darf nur verwenden, wer sich an die Krypto-Anweisungen und organisatorischen Vorgaben der NIST hält, einer Art US-BSI-Behörde.

Pikant ist in diesem Kontext, dass das Verteidigungsministerium der Vereinigten Staaten selbst die Entwicklung mitfinanzierte, die nötig war, um die FIPS-140-2-Zertifizierung zu erreichen.

Entwicklerstrukturen

In ihrer Gestalt gleicht die Organisationsstruktur von Open SSL der anderer FLOSS-Projekte, es herrscht “Do-ocracy”: Wer sich an der Arbeit beteiligen möchte, ist dazu herzlich eingeladen. Offiziell beheimatet die eigens dafür gegründete Open SSL Foundation die Open-SSL-Entwicklung. Im Nachgang des Heartbleed-Desasters wies eben jene aber darauf hin, dass hauptberuflich nur ein einziger Entwickler Open SSL vorantreibt. Als Reaktion auf Heartbleed kündigte die Linux Foundation Ende April an, Open SSL finanziell zu unterstützen, um mehr Manpower bereitzustellen.

In den Augen vieler Beobachter ist das Verstörende ja gar nicht die Tatsache, dass ein damaliger FH-Student den fatalen Code als Patch beisteuerte; viel schlimmer sei, dass die Open SSL Foundation, in diesem Falle vertreten durch den Entwickler Stephen Henson [6], den Code einfach so durchgewinkt und in Open SSL integriert habe. Kurz vor Redaktionsschluss trudelte noch die Meldung ein, Open SSL habe durch eine neue Release gleich sieben kritische Sicherheitslücken gestopft, von denen eine auf denselben Entwickler wie Heartbleed zurückgehe.

Jetzt wird genauer hingeschaut

Immerhin: Heartbleed hat die Internetgemeinde so heftig erschüttert, dass derzeit mehrere Reviews von Open SSL im Gange sind. Und Fakt ist auch: Das Ansehen von Open SSL könnte derzeit nicht heftiger besudelt sein. Ob es dem Projekt gelingt, verloren gegangenes Vertrauen wieder zu gewinnen, werden erst die nächsten Monate zeigen. Mit frischem Geld und Reviews durch Dritte scheint Open SSL allerdings auf einem guten Weg.

Libre SSL: Erregter Rebell

Bald nach den ersten Meldungen über Heartbleed machte Libre SSL [7] zum ersten Mal als Begriff die Runde. Im Grunde handelt es sich bei Libre SSL um eine Art Stinkefinger der Open-BSD-Entwickler in Richtung Open SSL Foundation.

Dass viele Open-BSD-Entwickler, allen voran Theo de Raadt (Abbildung 6) chronisch undiplomatisch auftreten, ist in der Community bekannt; doch genießt Open BSD den Ruf, insgesamt ein sehr sicheres Betriebssystem zu sein. Über Jahre brüsteten die Entwickler sich gar mit der Tatsache, dass sie in ihrer Default-Installation seit Längerem keine Sicherheitslöcher hatten, die entfernten Angreifern den Rootzugriff erlaubten.

Abbildung 6: Theo de Raadt (hier mit Jon “Maddog” Hall) ist einer der lautesten BSD-Entwickler, die Open SSL zu kritisieren pflegen.

Umso ungehaltener reagieren de Raadt und sein Team, wenn sie kritische Sicherheitslücken von anderen gewissermaßen ungefragt übergestülpt bekommen, und zwar besonders dann, wenn das Problem vermeidbar gewesen wäre – wobei in den Augen der Open-BSD-Entwickler ohnehin jedes Sicherheitsloch eigentlich vermeidbar ist.

Durch den Start von Libre SSL tun de Raadt und seine Mannschaft also nichts anderes, als ihr SSL-Schicksal selbst in die Hand zu nehmen und damit nebenbei der Welt ein besseres SSL zu spendieren, vor allem durch konsequentes Aufräumen und Ausmisten.

Besonders schmerzhaft an Heartbleed war ja auch die Tatsache, dass der Fehler in einer Funktion steckte, die kaum jemand benutzt, also völlig überflüssig war. Bob Beck, ein Core-Mitglied des Open-BSD-Teams, macht in einer Präsentation (Abbildung 7, [8]) deutlich, welchen Umfang überflüssiger Code bei Open SSL mittlerweile angenommen hat.

Abbildung 7: Drecksarbeit – Bob Becks Präsentation zeugt von der Wut, die viele Beteiligte nach dem Heartbleed-Desaster empfanden.

Entsorgt: 90 000 Zeilen Code in 30 Tagen

Er erklärt in seinen Slides, dass im Rahmen ihres Libre-SSL-Forks 90 000 Zeilen Code in den ersten 30 Tages ersatzlos gestrichen worden sind. Das umfasst Support für verschiedene Uralt-Architekturen (wie Mac OS 9) genauso wie viele Features, die nur sehr spezielle Use Cases abdecken. Das macht das Ziel von Libre SSL klar: Die Software soll stabiles und sicheres SSL für viele bieten, auch wenn das heißt, dass Libre SSL für so manches Spezialszenario unbrauchbar wird. Dafür soll Libre SSL schlanker und deutlich besser wartbar sein; je weniger Gelegenheiten da sind, um Sicherheitslücken einzubauen, desto weniger Sicherheitslücken werden gefährlich.

Zum wegrationalisierten Teil gehört übrigens auch der von der Open SSL Foundation so sehr geschätzte FIPS-Code. Über den macht Beck sich beinahe unverhohlen lustig, bezeichnet die Open SSL Foundation als “FIPS-Firma”, deren einzige Daseinsberechtigung FIPS-Consulting sei und nicht etwa die Weiterentwicklung von Open SSL. Anders die Open-BSD-Entwickler: Nahezu alle Funktionen, die im SSL-Alltag zwar unnötig, aber Voraussetzung für FIPS sind, haben sie aus Libre SSL bereits entfernt.

Standardisierter, FIPS-freier Code

Kein gutes Haar lassen die Libre-SSL-Entwickler an jenen Teilen von Open SSL, die für den alltäglichen Betrieb nötig sind und in Libre SSL verbleiben werden. “Unwartbar” sei der Code schon allein deshalb, weil die Open-SSL-Entwickler elementare Funktionen wie etwa »malloc()« nachimplementiert hätten, statt die Standardvarianten zu nutzen.

Was nach Geplänkel klingt, hat reale Konsequenzen: Werkzeuge wie Valgrind helfen Entwicklern dabei, sicherheitsrelevante Schwachstellen im Quelltext zu finden – allerdings nur dann, wenn dieser Standardfunktionen nutzt. Open SSL schlüpfte durch sämtliche Standardtests, weil es eben nicht die Funktionen nutzt, die Valgrind & Co. abklopfen. Wie Kamps Orchestra-Vortrag von der Fosdem 2014 zeigt, war auch all dies lange bekannt (Abbildung 8).

Abbildung 8: Auch die Problematik mit »malloc()« und Valgrind hatte Kamp auf der Fosdem 2014 thematisiert.

Die Libre-SSL-Entwickler werden – mit der Open Stack Foundation im Rücken – also viel Arbeit darauf verwenden, den Open-SSL-Code zu standardisieren. Am Ende soll eine “geheilte” Open-SSL-Bibliothek in Form von Libre SSL zur Verfügung stehen, die deutlich sicherer ist.

Libre SSL als Drop-in-Replacement für Open SSL

Um die Migration auf Libre SSL leicht zu machen, soll die Bibliothek grundsätzlich kompatibel mit Open SSL bleiben, zumindest was die Standardfunktionen betrifft. Bob Beck spricht von einem “Drop-in-Replacement”. Entwickler werden ihre Programme wohl aber trotzdem anpassen müssen, weil sich beispielsweise die Namen der Header von Libre SSL und Open SSL unterscheiden werden.

Wenn das die einzigen Änderungen bleiben, dürfte Libre SSL sich aber als Alternative zu Open SSL einen Namen machen und Nutzer finden. Der Ansatz erscheint jedenfalls stimmig – es bleibt zu hoffen, dass den erregten Open-BSD-Entwicklern bei ihrem Unterfangen nicht die Puste ausgeht.

Polar SSL: Das stille Mäuschen

Wie im falschen Film dürften sich angesichts des Heartbleet-Desasters die Polar-SSL-Entwickler gefühlt haben. Und den Libre-SSL-Leuten kann das Team um Paul Bakker wohl auch nur ein müdes Lächeln entgegenbringen – denn dass Open SSL viel zu groß und unübersichtlich wurde, war ja genau der Grund für die Entstehung von Polar SSL [9].

Christophe Devine, der die erste Version von Polar SSL als Erweiterung der XySSL-Bibliothek schrieb, veröffentlichte im Jahr 2006 diese erste Version (Abbildung 9), genau zu dem Zeitpunkt also, als Open SSL sich gerade mit seiner FIPS-Bibliothek rühmte.

Abbildung 9: Polar SSL: Diese SSL-Library soll schlank, schnell und sicher sein und ist im Rüstungs- und Militärbereich sehr beliebt.

Im Gegenteil

Ganz ausdrücklich war Polar SSL als genaues Gegenteil zu Open SSL konzipiert: Dem riesigen Codegebirge stand eine schlanke Bibliothek gegenüber, die leicht zu warten war und mit sehr geringen Anforderungen an die Ressourcen daherkam. 2008 gab Devine die Entwicklung von XySSL auf und ein Team um Paul Bakker übernahm Polar SSL als Fork von XySSL. In dieser Konstellation existiert das Projekt bis heute.

Polar SSL meint die Sache mit der Basisfunktionalität ernst. Vorrangig ist der Code enthalten, der zum Abwickeln von TLS-Verbindungen notwendig ist; spätere Versionen erhielten zwar zusätzliche Features, doch steht beim Projekt bis heute ein sehr schlanker Code im Vordergrund. Für die Autoren von Programmen ist es deshalb angenehm einfach, Polar SSL in die eigene Applikation zu integrieren; eine ausführliche Dokumentation [10] gibt einen Überblick über die gebotene Funktionalität.

Nicht nur GPL

Lizenzrechtlich ist Polar SSL durchaus interessant; das Programm steht unter der GPL v2 bereit, alternativ ist auch eine Lizenzierung über eine kommerzielle Lizenz gegen Aufpreis möglich. Das erlaubt einen freizügigen Einsatz der Software, ohne sich den Beschränkungen der GPL zu unterwerfen, und ermöglicht zusätzliche Support-Goodies.

Für den Dienst verrechnet die Offspark B.V. in den Niederlanden (Abbildung 10), zu der Paul Bakker gehört, ein Entgelt von gut 120 Euro je Produkttyp pro Monat, also knapp unter 1500 Euro pro Jahr – falls der Kunde sich für ein typisches Subscription-Modell entscheidet. Ein Einmalkauf kostet über 3000 Euro. Der Code ist übrigens unabhängig von der Lizenz stets der gleiche und Teile der Lizenzeinnahmen fließen laut Offspark in die Entwicklung und Pflege von Polar SSL zurück.

Abbildung 10: Die niederländische Offspark B.V. ist die Firma, die hinter Polar SSL steckt, die Entwicklung vorantreibt und auch für die Sicherheit bürgt.

Wichtig für Entwickler ist, dass Polar SSL kein Drop-in-Replacement für Open SSL sein will. Bestehende Anwendungen, die mit Open SSL funktionieren, lassen sich also nicht äquivalent gegen Polar SSL linken. Wer ein Programm um Support für Polar SSL erweitern möchte, muss es entsprechend anpassen.

Gnu TLS: Auch eine Frage der Lizenz

Dass Gnu TLS (Abbildung 11, [11]) das charakteristische “SSL” nicht im Namen trägt, soll an dieser Stelle nicht weiter verwirren. Schließlich ist TLS eigentlich nur der Name für den SSL-Standard 3.1 und spätere Versionen – ein Detail, das vielen Anwendern nicht bewusst ist.

Abbildung 11: Gnu TLS ist bereits auf vielen Servern installiert. Die Software entstand aufgrund von Lizenzproblemen, die die Entwickler mit Open SSL hatten.

Ansporn für die Entwicklung von Gnu TLS waren lizenzrechtliche Fragen: Open SSL ist unter zwei Lizenzen gestellt, die zugleich gelten. Beide sind im Grunde “BSD-Style”-Lizenzen, die mit einer Advertisement-Klausel vom Autor ausgestattet worden sind.

Konkret bedeutet das, dass Programme, die Open SSL verwenden wollen, einen entsprechenden Hinweis auf die Nutzung von Open SSL enthalten müssen, also beispielsweise einen eigenen Absatz in der jeweiligen Lizenz. Was so unspektakulär klingt, treibt FLOSS-Verfechtern Schweißperlen auf die Stirn. Denn faktisch ist die Forderung in deren Augen eine Einschränkung, die die Verteilung des Programms betrifft.

Nur mit Werbung – oder doch nur ohne?

Anders formuliert: Wer Open SSL verwendet, darf sein Programm nicht unter die Leute bringen, wenn er die Open-SSL-Werbung nicht aufnimmt. Die GPL jedoch verbietet solche Einschränkungen explizit. Wer GPL-Code schreibt und auf Open SSL zurückgreift, muss also entweder mit allen Copyright-Haltern am Code abklären, ob die genutzte Lizenz eine “SSL-Ausnahme” enthalten darf. Auch das war in den Augen der GNU-Entwickler aber eine Zumutung, und so setzten sie an, in Form von Gnu TLS eine GPL-lizenzierte Alternative zur Open-SSL-Bibliothek zur Verfügung zu stellen.

Die schlechte Nachricht ist, dass Gnu TLS mindestens so aufgebläht ist wie Open SSL. Nahezu alle Funktionen, die Open SSL beherrscht, kann Gnu TLS genauso, wesentlich kleiner ist der Quelltext auch nicht. Zwar besitzt Gnu TLS keine FIPS-Zertifizierung, aber einige der dafür notwendigen Funktionen sind durchaus enthalten.

Wie bei Open SSL sehen sich Entwickler von Gnu TLS also einem Moloch gegenüber. Dass sie dabei das GNU-Projekt im Rücken haben und kein “One-Man-Projekt” sind, tröstet da nur wenig. Der eingangs erwähnte Fefe weist in seinem Blog [2] denn auch genüsslich darauf hin, dass in Gnu TLS so regelmäßig Bugs gefunden werden wie in Open SSL.

Kein Drop-in-Replacement

Ein Drop-in-Replacement für Open SSL ist Gnu TLS freilich ebenso wenig, auch wenn die meisten GNU-Programme es bevorzugen. Wahrscheinlich ist Gnu TLS überhaupt nur etwas weniger verbreitet als Open SSL, Server ohne Gnu TLS dürften aber rar gesät sein.

Entwickler und Admins sind bei Gnu TLS aber jedenfalls falsch, wenn sie auf der Suche nach einer schlanken Alternative zu Open SSL sind. Wer den vollen Funktionsumfang braucht, hat bei Gnu TLS aber eine gute Chance, diesen tatsächlich zu finden.

Schlank oder funktionsreich

Libre SSL und Polar SSL unterscheiden sich von Open SSL und Gnu TLS maßgeblich dadurch, klein, aber fein zu sein – eine gute Basis für sichere Software. Wer auf der Suche nach einer grundlegenden SSL-Verschlüsselung ist, liegt bei Polar SSL richtig. Auch der Libre-SSL-Ansatz ist attraktiv – im Gegensatz zu Polar SSL muss Libre SSL aber erst noch beweisen, dass dem Projekt nicht nach einer gewissen Zeit die Luft ausgeht. Für Letzteres spricht derzeit aber nichts, Theo de Raadt und die Open BSD Foundation haben ihren Willen bekundet, eine Open-SSL-Alternative dauerhaft zu pflegen. Weil Libre SSL als Drop-in-Replacement für Open SSL arbeitet, wäre diese Variante sicherlich die attraktivste, sowohl für Admins als auch für Entwickler. Die Zahl der Programme, die Libre SSL schon unterstützen, ist zumindest im Augenblick allerdings gering.

Ausgewachsene Crypto-Suites sind hingegen Open SSL und Gnu TLS. Ob es Open SSL gelingen wird, wieder in den Ruf eines vertrauenswürdigen und sicheren Werkzeugs zu kommen, steht in den Sternen. Zweifellos sind die ersten wichtigen Schritte wie Fundraising und umfassende, gründliche Audits gemacht. Wer Admin oder Entwickler ist, tut jedenfalls gut daran, die Entwicklungen rund um Open SSL und Libre SSL weiter zu beobachten – einige Neuerungen dürften hier noch ins Haus stehen.

Der Autor

Martin Gerhard Loschwitz arbeitet als Principal Consultant bei Hastexo. Er beschäftigt sich dort intensiv mit den Themen HA, Distributed Storage und Open Stack. In seiner Freizeit pflegt er Pacemaker für Debian.