Mozilla zukünftig mit zentralen Sperrlisten

Mozilla erklärt seine Pläne für das Widerrufen von SSL-Zertifikaten. Wichtigster Bestandteil des aktuellen Entwurfs ist eine Widerrufsliste namens OneCRL, die Mozilla zukünftig selber pflegen will. Damit soll das derzeit schwer angeschlagene, hierarchische Zertifikats-System für gesicherte https-Verbindungen gerettet werden.

Ein Zertifikat bestätigt die Identität eines Servers. Vorfälle wie Heartbleed, bei denen Dritte die identitätsstiftenden, geheimen Schlüssel stehlen konnten, demonstrieren nachdrücklich, dass man für ein solches Konzept eine funktionierende Möglichkeit braucht, derzeit noch gültige Zertifikate zu widerrufen. Eine solche gibt es jedoch derzeit faktisch nicht.

Der aktuelle Stand der Technik ist das Online Certificate Status Protocol (OCSP). Dabei fragen Browser beim Herausgeber eines Zertifikats nach, ob es denn wirklich noch gültig ist. Das Problem dabei: Kommt keine Antwort, drücken alle Browser beide Augen zu und akzeptieren das Zertifikat trotzdem (Soft-Fail). Das ist eigentlich aberwitzig, weil das wichtigste Angriffsszenario mit gefälschten Zertifikaten ohnehin einen Angreifer in der Position eines Man-in-the-Middle erfordert. Und der könnte alle ihm missliebigen OCSP-Anfragen beziehungsweise -Antworten ausfiltern.

Ein Hard-Fail, bei dem jede ausbleibende Antwort zu einem Fehler führt, lässt sich wegen der damit rapide ansteigenden Fehlerhäufigkeit praktisch nicht realisieren. Darüber führte es zu einem dramatischen Ansteigen der Verzögerungen beim Laden von https-Seiten – schließlich muss der Browser warten, bis er alle Antworten beisammen hat. Und dazu gehören auch die OCSP-Antworten für alle eingebundenen Elemente und der jeweiligen Intermediate-Zertifikate. Außerdem bedeutet OCSP, dass ein Anwender den CAs ständig mitteilt, welche (https-)Seiten er aufruft. Der Schutz durch OCSP ist durch das Soft-Fail minimal; die damit verbunden Probleme hingegen substantiell. Google hat es deshalb in Chrome bereits abgeschaltet.

Auch Mozilla will deshalb OCSP in Zukunft nicht mehr für CA- und Intermediate-Zertifikate benutzen, sondern nur noch bei Zertifikaten für Endpunkte (End Entities, EE). Bevorzugt will man dabei dann auch das sogenannte OCSP Stapling einsetzen, das formal unter dem Namen TLS Certificate Status Request in RFC 6066 spezifiziert ist. Dabei präsentiert der Server zusammen mit dem Zertifikat auch gleich eine digital signierte OCSP-Bescheinigung des Ausstellers. Die holt er selber regelmäßig dort ab. Da sie ebenfalls von der CA unterschrieben sind, kann sie der Server-Betreiber auch nicht fälschen. Das schlägt zwei Fliegen mit einer Klappe: Zum einen verringert es die Last- und Latenzprobleme, die zusätzliche OCSP-Anfragen der Clients mit sich bringen. Zum anderen offenbaren Anwender ihr Surfverhalten nicht mehr den CAs.

Auch OCSP Stapling hat jedoch das Problem des Soft-Fails: Ein MiTM kann den OCSP-Staple-Teil der Kommunikation herausfiltern und der Client steht vor der gleichen Situation wie beim regulären OCSP. Eine neuere Zertifikats-Erweiterung soll dem ein Ende machen: Mit dem Flag "OCSP must staple" signalisiert der Zertifikats-Herausgeber, dass das Zertifikat ohne die signierte OCSP-Bescheinigung ungültig ist. Diese Erweiterung wird allerdings gerade erst von der IETF als TLS Feature Extension standardisiert.

Es kommt also Bewegung in die verfahrene Situation: Auch Google pflegt bereits seit einiger Zeit eigene, zentrale Widerrufslisten namens CRLSets, die es seinem Browser aktiv zuschiebt. Somit bewegen sich Google und Mozilla im Wesentlichen in die gleiche Richtung: weg vom Client-orientierten OCSP hin zu zentralen Widerrufslisten der Browser-Hersteller. (ju)