In der Vergangenheit sind Zertifikate häufig abgelaufen, weil sie manuell aktualisiert werden mussten. Die Leute haben es einfach vergessen. Mit dem Aufkommen von Let's Encrypt und einem automatischen Update-Verfahren scheint das Problem behoben zu sein. Eine aktuelle
Geschichte mit Firefox zeigt jedoch, dass sie tatsächlich immer noch relevant ist. Zertifikate verfallen leider weiterhin.
Wenn jemand diese Geschichte verpasst hat, funktionieren fast alle Firefox-Erweiterungen am 4. Mai 2019 um Mitternacht plötzlich nicht mehr.
Wie sich herausstellte, trat ein massiver Fehler auf, weil Mozilla
das Zertifikat , mit dem die Erweiterungen signiert wurden,
abgelaufen war. Daher wurden sie als "ungültig" markiert und haben den Test nicht bestanden (
technische Details ). In Foren haben wir als Problemumgehung empfohlen, die Überprüfung von Erweiterungssignaturen in
about: config oder durch Übersetzen der Systemuhr zu deaktivieren.
Mozilla veröffentlichte schnell den Firefox 66.0.4-Patch, der das Problem mit einem ungültigen Zertifikat löst, und alle Erweiterungen werden auf ihre normale Form zurückgesetzt. Entwickler empfehlen, es zu installieren und keine Problemumgehungen zu verwenden, um die Signaturüberprüfung zu umgehen, da dies zu Konflikten mit dem Patch führen kann.
Diese Geschichte zeigt jedoch erneut, dass das Ablaufen von Zertifikaten bis heute ein dringendes Problem darstellt.
In diesem Zusammenhang ist es interessant, einen ziemlich originellen Blick darauf zu werfen, wie die Entwickler des
DNSCrypt- Protokolls mit dieser Aufgabe
umgegangen sind . Ihre Lösung kann in zwei Teile geteilt werden. Erstens handelt es sich um kurzfristige Zertifikate. Zweitens warnen Benutzer vor dem Ablauf langfristiger.
DNSCrypt
DNSCrypt - DNS-Verkehrsverschlüsselungsprotokoll. Es schützt die DNS-Kommunikation vor Intercepts und MiTM und ermöglicht es Ihnen, das Blockieren auf der Ebene von DNS-Abfragen zu umgehen.
Das Protokoll umschließt den DNS-Verkehr zwischen Client und Server in einem kryptografischen Entwurf, der an den UDP- und TCP-Transportprotokollen arbeitet. Um es zu verwenden, müssen sowohl der Client als auch der DNS-Resolver DNSCrypt unterstützen. Beispielsweise wurde es seit März 2016 auf seinen DNS-Servern und im Yandex-Browser aktiviert. Unterstützung wurde von mehreren anderen Anbietern angekündigt, darunter Google und Cloudflare. Leider gibt es nicht viele von ihnen (152 öffentliche DNS-Server sind auf der offiziellen Website aufgeführt). Das Programm
dnscrypt-proxy kann jedoch manuell auf Clients unter Linux, Windows und MacOS installiert werden. Es gibt
Serverimplementierungen .
Wie funktioniert DNSCrypt? Kurz gesagt, der Client nimmt den öffentlichen Schlüssel des ausgewählten Anbieters und überprüft mit seiner Hilfe seine Zertifikate. Es gibt bereits kurzfristige öffentliche Schlüssel für die Sitzung und die Kennung der Verschlüsselungssuite. Kunden wird empfohlen, für jede Anforderung einen neuen Schlüssel zu generieren, und Servern wird empfohlen, die Schlüssel
alle 24 Stunden zu ändern. Beim Schlüsselaustausch werden der X25519-Algorithmus, EdDSA zum Signieren und XSalsa20-Poly1305 oder XChaCha20-Poly1305 für die Blockverschlüsselung verwendet.
Frank Denis, einer der Protokollentwickler,
schreibt, dass der automatische Austausch alle 24 Stunden das Problem abgelaufener Zertifikate löste. Im Prinzip akzeptiert der dnscrypt-Proxy-Referenzclient Zertifikate mit einer beliebigen Gültigkeitsdauer, zeigt jedoch die Warnung "Die dnscrypt-Proxy-Schlüsselperiode für diesen Server ist zu lang" an, wenn sie länger als 24 Stunden gültig ist. Gleichzeitig wurde ein Docker-Image veröffentlicht, in dem ein schneller Wechsel der Schlüssel (und Zertifikate) implementiert wurde.
Erstens ist es für die Sicherheit äußerst nützlich: Wenn der Server kompromittiert wird oder der Schlüssel durchgesickert ist, kann der gestrige Datenverkehr nicht entschlüsselt werden. Der Schlüssel hat sich bereits geändert. Dies wird wahrscheinlich ein Problem für die Implementierung des „Frühlingsgesetzes“ sein, das Anbieter dazu zwingt, den gesamten Datenverkehr einschließlich des verschlüsselten Datenverkehrs zu speichern. Es versteht sich, dass es später bei Bedarf entschlüsselt werden kann, indem ein Schlüssel von der Site angefordert wird. In diesem Fall kann die Site sie jedoch einfach nicht bereitstellen, da sie kurzfristige Schlüssel verwendet und die alten löscht.
Vor allem aber, schreibt Denis, zwingen kurzfristige Schlüssel die Server, die Automatisierung vom ersten Tag an zu konfigurieren. Wenn der Server eine Verbindung zum Netzwerk herstellt und die Schlüsseländerungsskripte nicht konfiguriert sind oder nicht funktionieren, wird dies sofort erkannt.
Wenn die Automatisierung alle paar Jahre die Schlüssel ändert, können Sie sich nicht darauf verlassen, und die Benutzer können den Ablauf des Zertifikats vergessen. Bei einem täglichen Schlüsselwechsel wird dies sofort erkannt.
Wenn die Automatisierung normal konfiguriert ist, spielt es keine Rolle, wie oft die Schlüssel gewechselt werden: jedes Jahr, jedes Quartal oder dreimal am Tag. Wenn alles länger als 24 Stunden funktioniert, wird es für immer funktionieren, schreibt Frank Denis. Ihm zufolge hat die Empfehlung einer täglichen Schlüsseländerung in der zweiten Version des Protokolls zusammen mit dem vorgefertigten Docker-Image, das dies implementiert, die Anzahl der Server mit abgelaufenen Zertifikaten effektiv reduziert und gleichzeitig die Sicherheit verbessert.
Einige Anbieter haben jedoch aus technischen Gründen beschlossen, die Gültigkeitsdauer des Zertifikats auf mehr als 24 Stunden festzulegen. Dieses Problem wurde hauptsächlich mit einigen Codezeilen in dnscrypt-proxy gelöst: Benutzer erhalten 30 Tage vor Ablauf des Zertifikats eine Informationswarnung, 7 Tage vor Ablauf des Zertifikats eine weitere Nachricht mit einem höheren Schweregrad und eine kritische Nachricht, wenn das Zertifikat erhalten bleibt weniger als 24 Stunden. Dies gilt nur für Zertifikate, die zunächst eine lange Gültigkeitsdauer haben.
Mit solchen Nachrichten können Benutzer DNS-Betreiber über den bevorstehenden Ablauf des Zertifikats informieren, bevor es zu spät ist.
Wenn alle Firefox-Benutzer eine solche Nachricht erhalten hätten, hätte wahrscheinlich jemand die Entwickler informiert und sie hätten nicht zugelassen, dass das Zertifikat abläuft. "Ich erinnere mich nicht an einen einzelnen DNSCrypt-Server aus der Liste der öffentlichen DNS-Server, deren Zertifikat in den letzten zwei oder drei Jahren abgelaufen ist", schreibt Frank Denis. In jedem Fall ist es wahrscheinlich besser, Benutzer zuerst zu warnen und Erweiterungen nicht ohne Warnung zu deaktivieren.
