LibreSSL: Krypto muss nicht (ganz so) schwierig sein

LibreSSL: Krypto muss nicht (ganz so) schwierig sein

Für die meisten, die im Web surfen, sieht es ganz einfach aus: Man ist sicher, wenn das kleine Schloss-Symbol in der Adressleiste des Browsers zu sehen ist. Die Adresse beginnt mit "https://", der Browser hat die Verbindung mit Transport Layer Security (TLS) verschlüsselt. Warum es nicht ganz so einfach ist und wie aber gerade Simplizität für Sicherheit bei unseren Kunden sorgt, erfahren Sie hier.

Jedem, der technisch tiefer in die Internet-Kryptographie einsteigt, wird schnell klar, dass das Thema sehr vielschichtig, interessant und sicherlich nicht einfach ist. Eine Herausforderung ist schlicht die Komplexität des Gesamtsystems.

Das fängt damit an, dass der Webbrowser ein Zertifikat von dem Server erhält, mit dem "er reden möchte". Bereits hier gibt es eine hohe Komplexität: Zuerst muss sichergestellt werden, dass das Zertifikat für die Webseite überhaupt gültig ist. Dann muss geprüft werden, ob das Zertifikat verwendet werden darf, um Webseiten zu authentifizieren. Danach muss noch die Zertifikatskette geprüft werden. Und tatsächlich gab es an allen diesen Stellen bereits kritische Fehler. Und das ist nur der Anfang vom Anfang einer gesicherten Verbindung.

Wem kann ich vertrauen?

Webbrowser vertrauen einer Webseite, indem sie deren Zertifikat prüfen. Das Zertifikat ist von einer Zertifizierungsstelle signiert. Der Browser hat eine Liste von Zertifizierungsstellen, denen er vertraut. Es gibt aber kein etabliertes System, welches sagt, welche Zertifizierungsstelle für welche Domain ein Zertifikat ausstellen darf oder ausgestellt hat. Und wer ein Zertifikat kauft, muss für eine bessere Prüfung bei dessen Erstellung auch mehr Geld zahlen. Hier wird oft an der Sicherheit gespart.

Die Folge ist, dass Zertifizierungsstellen fälschlich Zertifikate für Domains signiert haben, für die bereits jemand anderes zuständig ist. Dies ist schon öfter vorgekommen, unter anderem gab es bisher mindestens vier falsche Zertifikate für google.com. Es gibt also prinzipielle Probleme bei dem im Internet verwendeten "Ausweissystem".

Sicherheit ist nichts Endgültiges

Die Standards, die Kryptographie im Internet regeln, benötigen immer wieder Updates. Ein Grund dafür ist, dass hier zum Beispiel gewisse Verschlüsselungsverfahren vorgeschrieben werden. Durch Analysen von Experten gelten aber viele Krypto-Algorithmen, die früher als sicher angesehen wurden, inzwischen als schwach. Damit müssen natürlich die Standards und auch die Software, die diese implementiert, angepasst werden.

Aber nicht nur in Krypto-Algorithmen werden Schwachstellen entdeckt, viel häufiger ist es die konkrete Vorgehensweise bei der Anwendung der Kryptographie, die Probleme bereitet: Wenn man zum Beispiel als Angreifer beim Aufbau einer Verbindung dazwischenfunken kann, so dass beide Partner schwache statt starke Verschlüsselung verwenden, ist das ein Fehler im Design des Krypto-Protokolls. Derartige Fehler gab es schon öfter. Auch hier wurden die Standards angepasst, so dass die Fehler inzwischen behoben sind. Bis alle Stellen im Internet nur noch die neuen Standards einsetzen, dauert es meist lange.

Unnötig komplex

Kryptographie im Web hat also immer wieder Probleme gehabt. Bisher wurden immer schnell gute Lösungen dafür gefunden. Wenn man aber einen Schritt zurück tritt, entdeckt man neben den Problemen, die eingangs erwähnt wurden (und die vermutlich nie ganz verschwinden werden) ein weiteres: Komplexität bei der Verwendung von Kryptosystemen. Und zwar unnötige Komplexität.

Software ist wie ein Baukastensystem. Man muss nicht jedes Rad neu erfinden, sondern es gibt Sammlungen von Funktionalität, die man in der eigenen Software wiederverwenden kann. Eine solche Sammlung heißt Bibliothek.

OpenSSL ist (im Kern) so eine Bibliothek. Viele Programme verwenden OpenSSL, um verschlüsselt im Internet zu kommunizieren. OpenSSL war bisher die beste Wahl für diese Aufgabe, da hier alle wichtigen Funktionen vereint waren.

Auch wenn sich der Großteil des Internets auf diese Bibliothek verlassen hat, heißt das nicht, dass diese angenehm zu verwenden gewesen ist. Ein Beispiel: Um den Namen eines Servers in einem Zertifikat zu prüfen, sind immerhin neun Zeilen Code nötig, bis vor kurzem sogar mehrere Dutzend. Und man muss ein ziemlich gutes Verständnis von der Materie haben, um so eine Prüfung wirklich korrekt zu programmieren. Dabei existiert prinzipiell kein Grund, warum so eine Prüfung so schwierig sein muss.

OpenSSL hatte historisch immer wieder kritische Sicherheitslücken, die bekannteste ist Heartbleed: Eine Erweiterung von SSL um eine Heartbeat-Funktionalität, die in so gut wie allen Fällen nicht benötigt wurde. Diese wies einen Fehler auf, der es möglich machte, über das Web den geheimen Schlüssel eines Servers auszulesen. Die Folge: Alle aktuellen Verbindungen waren unsicher und die alten im Nachhinein zu entschlüsseln, bis man die Software patcht und neue Zertifikate bereitstellt. Viel schlimmer geht es nicht.

LibreSSL soll Krypto sicherer machen

Obwohl der Name es nahelegt, hat OpenSSL nichts mit OpenBSD zu tun. Die OpenBSD-Entwickler haben mit LibreSSL ihr eigenes Projekt begonnen, um eine bessere Alternative zu OpenSSL zu bieten. Konkretes Ziel des LibreSSL-Projektes war es, den OpenSSL-Quellcode zu verschlanken und zu vereinheitlichen, um letztlich mehr Sicherheit zu erreichen. Außerdem sollte die Benutzung einfacher sein, mit weniger Möglichkeiten, Dinge falsch zu machen, unter anderem durch sichere Standardeinstellungen.
Diese Ziele wurden schon jetzt erreicht. Obwohl die wesentliche Funktionalität weiterhin vorhanden ist, wurde der Umfang von über einer Million Zeilen Text und Code um circa die Hälfte verringert. Das zeigt den angesammelten Ballast ganz plastisch.

Produktbild High Resistance Firewall genugateDie High Resistance Firewall genugate setzt von Anfang an auf LibreSSL

Die oben erwähnte Prüfung beispielsweise, zu der bisher neun Zeilen Code nötig waren, kommt jetzt mit einer Zeile aus. Es wurde also viel unnötiges entfernt, der Quelltext vereinfacht und vereinheitlicht. Die Folgen waren sofort sichtbar: In bisher eineinhalb Jahren wurden nur noch halb so viele Sicherheitsprobleme gemeldet, diese waren zudem weniger kritisch.

Realistisch betrachtet wird es bei einer Software dieser Komplexität vermutlich immer Bugs geben. Gerade deshalb ist es aber unbedingt nötig, den Quelltext klein und übersichtlich zu halten, so dass Code-Audits leicht durchgeführt und automatische Code-Analysewerkzeuge verwendet werden können. Ebenso ist es nötig, dass die Software so geschrieben ist, dass Bugs möglichst geringe Auswirkungen haben. Hier helfen in LibreSSL bereits umgesetzte Verbesserungen beim Speicher-Management und eine bessere und konsequente Fehlerbehandlung.

Wir setzen zur Sicherheit unserer Kunden bei unserer High Resistance Firewall genugate von Anfang an auf LibreSSL. Die aktuelle Entwicklung bestätigt, dass hier die richtige Entscheidung getroffen wurde.

Lesen Sie auch: Auf bewährten Pfaden: Separation, Microkernel und Virtualisierung

 

Bildquelle: © adrian_ilie825 -  Fotolia.com


Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.