TLS wird dank BoringSSL sicherer

Bei OpenSSL kommt es immer wieder zu gravierenden Sicherheitslücken, beispielsweise dem berüchtigten Heartbleed Bug. Neben dem Missbrauchsrisiko sehen sich Nutzer bei Bekanntgabe einer neuen Sicherheitslücke auch erheblichen Betriebskosten für das schnelle Testen und Implementieren von Patches gegenüber. Unser Hauptziel beim Wechsel von OpenSSL zu BoringSSL war, die Wahrscheinlichkeit und die Auswirkungen von CVEs zu reduzieren und die Sicherheit unseres TLS-Terminierungssystems für unsere Kunden zu erhöhen.

BoringSSL ist ein Ableger von OpenSSL, der von Google erstellt und gepflegt wird. Aufgrund seiner geringeren Komplexität gilt BoringSSL grundsätzlich als sicherer als OpenSSL. OpenSSL ist nach wie vor das Rückgrat der SSL-Bibliotheken und in den vergangenen Jahren wurde viel daran optimiert, aber für uns und unsere Kunden bietet BoringSSL den besseren Schutz.

Der Wechsel

Unsere Arbeit startete vor etwa einem Jahr mit der ehrgeizigen Idee, OpenSSL für alle eingehenden Verbindungen auf unserer Edge zu ersetzen. Nach Abwägung einiger Alternativen hielten wir an unserem ursprünglichen Plan fest, auf BoringSSL umzusteigen. Dies bietet uns folgende Vorteile:

• Kleinere und modernere Codebasis

• Sicherere API

• „BoringSSL ist ein Ableger von OpenSSL und größtenteils mit dem Quellcode kompatibel“, was die Migration erleichtert.

• Umfangreiches Fuzzy Testing

• Von Großunternehmen genutzt und von Google verwaltet

• Mit OpenSSL vergleichbare Performance

Insgesamt war man sich einig, dass BoringSSL im Vergleich zu OpenSSL, wo unzählige veraltete Codezeilen nötig sind, eine gezieltere und damit eine sicherere Codebasis bietet.

Benötigte Codezeilen im Vergleich:

Wie bereits erwähnt, spielte es für uns eine wichtige Rolle, dass BoringSSL das gleiche Maß an Performance wie OpenSSL bot. Beim Performance-Vergleich zwischen den Bibliotheken wandten wir verschiedene Strategien an.

Vorab nahmen wir insbesondere im Hinblick auf kryptografische Vorgänge Performance-Bewertungen vor.

Key Exchange (ECDH Vorgang/Vorgänge) in verschiedenen TLS-Bibliotheken:

Sobald uns eine BoringSSL Binärdatei zum Testen vorlag, begannen wir mit Canary-Tests. Wir stellten also den neuen Code auf einigen wenigen Servern in der Produktivumgebung bereit. So konnten wir die Performance anhand realer, nur schwer zu simulierender Traffic-Muster vergleichen. Abschließend führten wir Überlastungstests durch, bei denen bestimmten Fastly Servern, darunter auch der Server, auf dem die Testbinärdatei ausgeführt wurde, zu Kontrollzwecken mehr Live-Traffic zugewiesen wurde.

Kein Zuckerschlecken

Es war von Anfang an klar, dass der Entwicklungsaufwand sehr hoch sein würde. Wir mussten auch davon ausgehen, dass eine so große Veränderung in unserem Netzwerk zusätzliche Anstrengungen seitens Operations und Kundensupport erfordern würde. Schließlich sollte der Wechsel ohne weitere Auswirkungen auf unsere Kunden erfolgen.

Außerdem wussten wir, dass wir uns von Folgendem verabschieden mussten: 

• Im Gegensatz zu OpenSSL gibt es bei BoringSSL keine regelmäßigen Releases. Daher müssen wir die Versionsverwaltung selbst in die Hand nehmen und Upstream-Änderungen nicht nur proaktiv verfolgen, sondern auch selbst entscheiden, ob sie relevant sind oder nicht.

• Tooling und Konfigurationsskripte 

• OCSP Stapling

• Unterstützung für bestimmte schwache Verschlüsselungen (z. B. CBC-Modi)

Probleme bei der Sitzungsfortsetzung

Auf halber Strecke – zumindest dachten wir das zu dem Zeitpunkt – stießen wir auf das erste Problem: OpenSSL und BoringSSL Sitzungen sind nicht kompatibel. Sitzungen, die in einer H2O Instanz unter Verwendung von BoringSSL begonnen wurden, konnten nicht von einer H2O Instanz unter Verwendung von OpenSSL übernommen werden und umgekehrt. Es war also nicht möglich, Ticket- und Cache-Sitzungen über mehrere Bibliotheken hinweg fortzusetzen.

So wie Fastlys Loadbalancer-Architektur aufgebaut ist, ist es wahrscheinlich, dass vom selben Kunden ausgehende Verbindungen unterschiedliche Zielserver erreichen. Folglich käme es bei der Implementierung des Wechsels zu einer Unmenge an bibliotheksübergreifenden Sitzungsfortsetzungsversuchen.

Da diese allerdings nur während der Implementierungsphase erfolgen würden, konnte das Problem gelöst werden, indem lediglich die TLS-Sitzungscaches segmentiert und der vorübergehende (teilweise) Verlust von TLS-Handshake-Fortsetzungen abgefangen wurden.

Probleme bei der Verschlüsselung

BoringSSL ist auch deshalb sicherer, weil die Unterstützung für einige ältere Cipher Suites eingestellt wurde. Der Wechsel zu BoringSSL hatte zur Folge, dass alle schwachen CBC-Verschlüsselungen automatisch wegfielen. Selbst wenn nur äußerst wenige Fastly Kunden auf diese Verschlüsselungen angewiesen sind, kann auch ein kleiner Traffic-Anteil in einem Großunternehmen viel bewirken. Bei unseren Tests spürten wir vor allem eine häufig genutzte Verschlüsselung auf, die den Wechsel zu BoringSSL untergrub. Wir führten ein simuliertes Cipher-Matching-Feature ein, wonach „als ob BoringSSL verwendet würde“ galt. So konnten wir den Verlust der Abwärtskompatibilität evaluieren.

Dieses Problem wurde von den Entwicklern von BoringSSL anerkannt, woraufhin sie eine einzige schwache CBC-Verschlüsselung („ECDHE-RSA-AES128-SHA256“) wiedereinführten. Nachdem Daten gesammelt, analysiert und erneut getestet worden waren, konnten wir fortfahren.

Wie aus der nachstehenden Grafik ersichtlich, ist die Anzahl der inkompatiblen Verschlüsselungen angesichts dieser einen schwachen CBC-Verschlüsselung vernachlässigbar. Und höchstwahrscheinlich blähen Bots und Scanner, die unsere TLS-Konfigurationen durchsuchen, diese Zahl ohnehin zusätzlich auf.

OCSP

Viele Clients verwenden das Online Certificate Status Protocol (OCSP) nicht mehr, um nach gesperrten Zertifikaten zu suchen. In Chrome verlässt sich Google auf CRLSets, weshalb die OCSP-Verifizierungsfunktion aus BoringSSL entfernt wurde. Zahlreiche Clients führen nach wie vor OCSP-Prüfungen durch, und standardmäßig beeinträchtigen blockierende Network Calls die Performance. OCSP Stapling geht einen Schritt weiter. Der Server kann hier die OCSP-Antwort im Handshake liefern und zusätzliche Network Calls auf diese Weise umgehen. Ohne dieses Feature auszukommen war für Fastly ein Ding der Unmöglichkeit. Deswegen haben wir sie kurzerhand zu BoringSSL hinzugefügt.

Fazit

Eine frühe und erfolgreiche Idee von uns war es, Funktionen, die auf OpenSSL-spezifische API-Funktionen angewiesen sind, vorbeugend so zu konvertieren, um sie so unabhängig wie möglich von TLS-Bibliotheken zu machen. 

Neben den erwarteten Mehrkosten stehen wir nun vor der zusätzlichen Aufgabe, alle kürzlich in BoringSSSL erfolgten Upstream-Änderungen zu analysieren und zu ermitteln, ob wir Aktualisierungen durchführen müssen oder sollten. Außerdem haben wir ein Auge auf noch mehr automatischen Verlust von Abwärtskompatibilität, wie es beispielsweise bei der oben erwähnten CBC-Verschlüsselung der Fall war.

Auch wenn BoringSSL einige zusätzliche Herausforderungen mit sich bringt, freuen wir uns insgesamt über unsere Entscheidung, in bessere TLS-Sicherheit zu investieren.