Zertifikat – Dentaku

Certificate Pinning funktioniert nicht

Wenn Webseiten verschlüsselte Verbindungen benutzen (https), dann wird zu Beginn des Kontakts dem Browser vom Server ein Zertifikat gezeigt, mit dem der Server versichert, dass er auch der richtige Server ist (und nicht irgendein Angreifer, der auf der Leitung steht). Die Ausstellung und Überprüfung dieser Zertifikate folgt einem hierarchischen Ansatz („X.509“), und die Liste der als vertrauenswürdig betrachteten Herausgeber sieht gar nicht so vertrauenswürdig aus, wie man sich das wünschen würde (siehe hier). Es gab immer wieder Fälle, in denen sehr neugierige Menschen sich von einer der zwielichtigeren Zertifizierungsstellen der Liste ein Zertifikat für eine bekannte Webseite organisiert haben. Sie konnten dann alles mithören ohne dass den Benutzern aufgefallen wäre, dass sie nicht direkt mit z.B. Google reden.

Eine Gegenmaßnahme für dieses Problem ist das Certificate Pinning: der Browser merkt sich für alle Webseiten, mit denen er sich schon einmal verbunden hat, das Zertifikat und schlägt Alarm, wenn ihm später ein anderes vorgezeigt wird (funktioniert natürlich nur unter der Annahme, dass die Verbindung nicht schon von Anfang an infiltriert ist, aber das nehmen wir einfach mal an).

Genau zu diesem Zweck habe ich jetzt ein paar Monate lang das Firefox-Plugin Certificate Patrol benutzt. Das Plugin funktioniert auch super, aber es bringt trotzdem keinen Sicherheitsgewinn.

Das liegt daran, dass viele größere Webseiten ihre Daten über Content Delivery Networks ausliefern, und dass die es mit den Zertifikaten nicht so genau nehmen: die über die ganze Welt verteilten Server, die Dateien für dieselbe Webseite ausliefern, scheinen oft jeder ein anderes Zertifikat zu benutzen.

Certificate Patrol bietet sogar noch die Möglichkeit, nicht schon bei einem bloßen Zertifikatswechsel zu warnen sondern erst dann, wenn das geänderte Zertifikat auch von einem anderen Herausgeber stammt, aber selbst diese geringe Integritätsbedingung halten viele CDNs nicht ein.

Wenn ich also mit Certificate Pinning im Web unterwegs bin, muss ich ununterbrochen Warnmeldungen lesen und wegklicken, lesen und wegklicken, lesen und wegklicken, und irgendwann nur noch wegklicken…

Ich werde deshalb Certificate Patrol wieder deinstallieren, denn wenn es mich irgendwann mal vor einem tatsächlichen Lauschangriff warnen würde, würde ich es wahrscheinlich nicht einmal lesen. 🙁

Das Sicherheitszertifikat der Seite verwendet einen schwachen Signaturalgorithmus

Meine Suchanfragen sagen mir, dass ich nicht der einzige bin, der ein Problem mit dieser Fehlermeldung hat. Zu der verstieg sich nämlich Google Chrome nach einem der letzten Updates, wenn ich per https auf meine eigene Seite zugriff.

Das Zertifikat meiner Seite ist von CAcert (dazu später nochmal mehr) und im August 2010 erstellt, es hätte also durchaus sein können, dass ich da eine technische Entwicklung verschlafen hätte. Ein generelles CAcert-Problem konnte ich mir nicht vorstellen, denn dann hätte man schnell auch woanders von der Sache gelesen.

Etwas googlen führte mich zu folgendem Bugreport gegen Chrome: Issue 108948: Chrome shouldn’t warn about insecure signatures algorithms of root certificates the user explicitly trusts. Daraus konnte ich für mich folgende Lösung erarbeiten:

Die Problembeschreibung in Chrome ist nicht ganz korrekt; mein eigenes Zertifikat ist mit einer SHA-1-Signatur unterzeichnet, die im Moment als sicher genug angesehen wird. Die Warnung wird aber auch ausgegeben, wenn eins der weiter oben in der Zertifizierungskette liegenden Zertifikate ein Sicherheitsproblem hat. Genau das war hier der Fall, es handelte sich aber um ein lokales Problem. Damit CAcert-Zertifikate überhaupt anerkannt werden können, hatte ich schon vor längerer Zeit deren Root-Zertifikate in meinen lokalen Schlüsselspeicher als vertrauenswürdige Zertifizierungsstelle importiert (wenn man sich mal ansieht, wer da alles sowieso schon vom Browser- und Betriebssystemhersteller eingetragen ist, dann ist das locker vertretbar). Zu der Zeit war das sogenannte „class-3 Intermediate Certificate“ mit einer MD5-Signatur versehen. MD5 sollte aber aus gutem Grund nicht mehr für diese Zwecke eingesetzt werden. Die aktuelle Version desselben Zertifikats trägt deshalb auch eine SHA-1-Signatur.

Eine Neuinstallation des class-3-Zertifikats hat das Problem daher behoben.