CVE-2014-0160, besser bekannt als Heartbleed, führt dazu, dass sich zur Zeit gefühlt die halbe Welt mit Verschlüsselung und Code-Qualität beschäftigt. Gut so. Just zu Ostern überrascht Adam Langley – bei Google verantwortlich für die Google HTTPS-Infrastruktur und den Netzwerk-Stack in Google Chrome – mit der Ansage, dass Revoction Checking doch Banane sei.
Was ist Revocation Checking?
Beim Aufbau einer verschlüsselten Verbindung, z. B. zu secuvera.de, weist sich der Webserver mit einem Zertifikat aus. Das Zertifikat ist von einer dem Browser bekannten Registrierungsstelle signiert und wird damit als vertrauenswürdig eingestuft. Im Zertifikat steckt auch die Information zum Recovation Checking, also ob das Zertifikat aktiv zurückgezogen wurde (z. B. weil der private Schlüssel durch die Heartbleed Schwachstelle bekannt wurde). Dies geschieht entweder über eine Liste, die Certificate Revocation List (CRL) oder mit einer Online-Abfrage mittels des Online Certificate Status Protocol (OCSP)-Protokolls.
Worin liegt die Kritik?
Langley führt aus, dass „niemand“ (also kein Browser in den Standardeinstellungen) hart auf Recovation Checking prüft. Sofern der OCSP-Server nicht erreichbar ist, wird die Verbindung eben doch aufgebaut. Verfügbarkeit vor Vertraulichkeit und Integrität. Dadurch ergeben sich zig Probleme. Richtig. Aber was ist bitte die Quelle allen Übels, der „Root-Cause“? Der Soft-Check.
Warum liegt Langley falsch?
Ich stelle mir automatisch die Frage: Wenn Soft Checks Vertraulichkeit und Integrität kompromitieren, warum dann bitte keine Hard Checks? Der Browser fragt also beim OCSP-Server an, ob ein Zertifikat noch gültig ist und wenn keine Antwort kommt, gibt es auch keine Verbindung. Gegenargument von Langley:
„(..) if everyone did hard-fail then taking down an OCSP service would be sufficient to take down lots of Internet sites.“
Klar: Wenn der zentrale Infrastukturdienst weg ist, kann ich mich nicht mehr verbinden. Klingt für mich nach: Nachts ist es kälter als draußen. Ich bin mir sicher, dass eine CA in der Lage ist eine skalierende OCSP-Infrastruktur bereitzustellen. Deren Performanz ist schon jetzt bei einigen unserer Kunden ein Unique-Selling-Point.
Was kann man machen?
Klar. Hard-Checks anschalten. Im Firefox geht das so:
Als Browserhersteller würde ich das ja machen und zur Not dem Anwender die Möglichkeit geben sich doch zu verbinden. So wie bei allen anderen Zertifikatsfehlern auch.
Übrigens
Bei der verfügbaren vamigru für Windows Browser-Edition ist die Einstellung selbstverständlich sicher gesetzt.