Heartbleed und das Sperrproblem von SSL
Nach dem Beseitigen des Heartbleed-Problems sperrten viele Admins vorsorglich ihre SSL-Zertifikate und besorgten sich neue. Trotzdem bedeuten geklaute Server-Schlüssel auch weiterhin ein Problem – denn das Sperren funktioniert eigentlich nicht.
(Bild: SANS ISC )
SSL beziehungsweise genauer TLS hat ein ganz fundamentales Problem: Das für einen sicheren Betrieb erforderliche Sperren von Server-Zertifikaten funktioniert eigentlich nicht. Da im Zug der Aufräumarbeiten nach Heartbleed hunderttausende Admins ihre möglicherweise kompromittierten Zertifikate vorsorglich sperrten, gerät diese eigentlich schon länger bekannte Tatsache jetzt wieder ins Licht der Öffentlichkeit.
Browser haben zwei Mechanismen, mit denen sie überprüfen können, ob ein soeben empfangenes Zertifikat, das eigentlich noch gültig wäre, vom Aussteller in der Zwischenzeit gesperrt wurde. Die erste sind die Certificate Revocation Lists (CRLs), die jeder Herausgeber pflegt. Allerdings wachsen diese Sperrlisten rapide an; viele sind mehrere MByte groß. Ein solcher Download verzögert den Seitenaufbau nachhaltig – insbesondere auch, weil die Server der Belastung durch viele Millionen Internet-Surfer nicht standhalten würden. Besser skaliert da schon das schlankere Online Certificate Status Protocol (OCSP), über das der Browser beim Herausgeber den Status eines bestimmten, gerade benötigten Zertifikats abfragen kann.
Durch die Massensperrungen nach Heartbleed fiel auf, dass Googles Chrome diese OCSP-Nachfragen standardmäßig nicht durchführt und deshalb anders als etwa Firefox und Internet Explorer auf absichtlich mit gesperrten Zertifikaten betriebenen Servern keine Warnung anzeigte. Viele News-Seiten gaben darauf hin den Tipp, den OCSP-Check in den Einstellungen zu aktivieren. Sie ließen dabei außer acht, dass Google diesen Check vor einigen Jahren durchaus absichtlich abgeschaltet hat. Googles https-Spezialist Adam Langley rechtfertigt diese Entscheidung jetzt auch erneut mit einem Blog-Beitrag Nein, schaltet den Sperrlisten-Check nicht ein.
Hard versus Soft Fail
Sein zentrales Argument: Die OCSP-Checks verzögern zwar den Seitenaufbau deutlich, tragen aber zum Schutz vor Angriffen eigentlich nichts bei. Das liegt an der Art und Weise, wie diese Checks praktisch umgesetzt werden müssen. Erhält der Browser nämlich auf eine OCSP-Anfrage innerhalb eines bestimmten Zeitraums keine Antwort, reagiert er nicht etwa mit einer Fehlermeldung (Hard Fail), sondern er ignoriert das still schweigend (Soft Fail). Das machen alle Browser so, weil die Infrastruktur einfach nicht verlässlich genug ist und ansonsten ständige Fehlalarme drohen würden. Hinzu kommt noch, dass beim Hard Fail der Ausfall eines einzigen OCSP-Servers beträchtliche Teile des Internet lahmlegen würde – diese Server also einfache Ziele für DDoS-Attacken wären.
Das Problem mit dem Soft Fail ist, dass damit ein Angreifer lediglich die OCSP-Kommunikation unterbinden muss, um dem Browser mit seinem geklauten, aber eigentlich bereits gesperrten Zertifikat trotzdem einen gefälschten Server vorzuspielen. Und weil alle relevanten Angriffsszenarien, in denen etwa ein Man-in-the-Middle ein solches Zertifikat missbrauchen könnte, ohnehin das Umleiten von Netzwerkverkehr erfordern, bedeutet das keine zusätzliche Hürde für den Angreifer. Wenn der den Zugriff auf den Google-Server auf seinen eignen umleiten kann, kann er genau so gut die Abfrage beim OCSP-Server ins Nirvana schicken. Deren Nutzen ist also tatsächlich fragwürdig. Dabei wurde das Datenschutzproblem, dass der OCSP-Server sieht, welche https-Server man besucht, noch gar nicht angesprochen.
Die Zukunft
Chrome arbeitet statt dessen mit so genannten CRLSets, bei denen der Browser-Hersteller über den Update-Mechanismus zumindest die wichtigen Einträge der Sperrlisten an den Browser schickt. Das klappt natürlich bei Massensperrungen auch nicht mehr zuverlässig. Langley diskutiert als Alternativen noch ein paar Möglichkeiten, wie kurzlebige Zertifikate und das so genannte OCSP Stapling. Die haben aber derzeit noch keine praktische Bedeutung. Fakt ist also: Wir haben derzeit keine wirklich funktionierenden Sperrmechanismen für Server-Zertifikate. Das sollten wir schleunigst ändern. (ju)
