Früher liefen Zertifikate oft ab, weil sie manuell aktualisiert werden mussten. Die Leute vergaßen einfach, dies zu tun. Mit dem Auftauchen von Let’s Encrypt und automatisierten Aktualisierungsprozessen sollte das Problem gelöst sein. Doch die jüngste zeigt, dass das Problem in Wirklichkeit nach wie vor besteht. Leider laufen die Zertifikate weiterhin ab.
Falls jemand diese Geschichte verpasst hat, hörten um Mitternacht am 4. Mai 2019 plötzlich fast alle Erweiterungen von Firefox auf zu funktionieren.
Wie sich herausstellte, war ein massives Versagen aufgetreten, weil bei Mozilla , das zur Signierung der Erweiterungen verwendet wurde, abgelaufen war. Daher wurden sie als "ungültig" markiert und bestanden die Überprüfung nicht (). In den Foren wurde empfohlen, entweder die Überprüfung der Erweiterungssignaturen in about:config oder die Systemuhrzeit zurückzustellen.
Mozilla veröffentlichte schnell ein Update für Firefox 66.0.4, das das Problem mit dem ungültigen Zertifikat behebt, und alle Erweiterungen kehren zur Normalität zurück. Die Entwickler empfehlen, es zu installieren und Es gibt keine Umgehungsmöglichkeiten für die Überprüfung von Signaturen, da diese mit dem Patch in Konflikt geraten könnten.
Dennoch zeigt diese Geschichte einmal mehr, dass das Ablaufen von Zertifikaten auch heute noch ein aktuelles Problem darstellt.
In diesem Zusammenhang ist es interessant zu betrachten, wie die Entwickler des Protokolls diese Herausforderung auf eine recht originelle Weise gemeistert haben. . Ihre Lösung lässt sich in zwei Teile unterteilen. Erstens, die kurzzeitigen Zertifikate. Zweitens, die Warnung der Nutzer vor dem Ablauf der langfristigen Zertifikate.
DNSCrypt
DNSCrypt ist ein Protokoll zur Verschlüsselung von DNS-Verkehr. Es schützt die DNS-Kommunikationen vor Lauschangriffen und Man-in-the-Middle-Angriffen und ermöglicht es, DNS-Anfragen zu umgehen, die auf Blockierungen basieren.
Das Protokoll verschlüsselt den DNS-Verkehr zwischen dem Client und dem Server in eine kryptografische Struktur, basierend auf den Transportprotokollen UDP und TCP. Um es zu verwenden, müssen sowohl der Client als auch der DNS-Resolver DNSCrypt unterstützen. So hat beispielsweise Yandex seit März 2016 dieses Protokoll auf seinen DNS-Servern und im Browser implementiert. Auch andere Anbieter, darunter Google und Cloudflare, haben ihre Unterstützung angekündigt. Leider gibt es nicht viele davon (auf der offiziellen Website sind 152 öffentliche DNS-Server aufgeführt). Doch das Programm lässt sich manuell auf Clients unter Linux, Windows und MacOS installieren. Es gibt auch .
Wie funktioniert DNSCrypt? Kurz gesagt, der Client nimmt den öffentlichen Schlüssel des gewählten Anbieters und überprüft damit seine Zertifikate. Dort befinden sich bereits kurzfristige öffentliche Schlüssel für die Sitzung und eine Verschlüsselungsalgorithmus-ID. Es wird empfohlen, dass Clients für jede Anfrage einen neuen Schlüssel generieren und Server ihre Schlüssel alle 24 Stunden. Bei der Schlüsselverteilung wird der Algorithmus X25519 verwendet, zur Signierung EdDSA und für die Blockverschlüsselung XSalsa20-Poly1305 oder XChaCha20-Poly1305.
Einer der Entwickler des Protokolls, Frank Denis. , dass der automatische Austausch alle 24 Stunden das Problem abgelaufener Zertifikate gelöst hat. Im Prinzip akzeptiert der Standard-Client dnscrypt-proxy Zertifikate mit jeder Gültigkeitsdauer, gibt jedoch eine Warnung aus: „Die Gültigkeitsdauer der dnscrypt-proxy-Schlüssel für diesen Server ist zu lang“, wenn sie länger als 24 Stunden gültig sind. Gleichzeitig wurde ein Docker-Image veröffentlicht, in dem ein schneller Schlüsselwechsel (und Zertifikate) implementiert wurde.
Zunächst ist dies äußerst hilfreich für die Sicherheit: Wenn der Server kompromittiert ist oder der Schlüssel geleakt wurde, kann der gestrige Datenverkehr nicht entschlüsselt werden. Der Schlüssel wurde bereits geändert. Wahrscheinlich wird dies ein Problem für die Umsetzung des „Jarowaja-Gesetzes“ darstellen, das Anbieter zwingt, gesamten Datenverkehr, einschließlich verschlüsselter Daten, zu speichern. Es wird angenommen, dass dieser später bei Bedarf entschlüsselt werden kann, indem der Schlüssel von der Website angefordert wird. In diesem Fall kann die Website jedoch einfach nicht bereitgestellt werden, da sie kurzlebige Schlüssel verwendet und alte entfernt.
Doch das Wichtigste, so Denis, ist, dass kurzlebige Schlüssel die Server ab dem ersten Tag zur Automatisierung zwingen. Wenn ein Server mit dem Netzwerk verbunden ist, und die Skripte zum Wechseln der Schlüssel nicht konfiguriert oder funktionsfähig sind, wird dies sofort bemerkt.
Wenn die Automatisierung die Schlüssel nur alle paar Jahre wechselt, kann man sich nicht darauf verlassen, und Menschen könnten das Ablaufdatum des Zertifikats vergessen. Bei täglichen Schlüsselwechseln wird dies sofort erkannt.
Gleichzeitig ist es unwichtig, wie oft die Schlüsselwechsel durchgeführt werden, solange die Automatisierung richtig eingerichtet ist: einmal im Jahr, einmal im Quartal oder dreimal täglich. Wenn alles länger als 24 Stunden funktioniert, wird es für immer funktionieren, schreibt Frank Denis. Seiner Meinung nach hat die Empfehlung, die Schlüssel täglich zu wechseln, in der zweiten Version des Protokolls zusammen mit einem fertigen Docker-Image, das dies umsetzt, die Anzahl der Server mit abgelaufenen Zertifikaten erheblich reduziert und gleichzeitig die Sicherheit verbessert.
Einige Anbieter haben aus technischen Gründen dennoch beschlossen, die Gültigkeitsdauer des Zertifikats auf mehr als 24 Stunden festzulegen. Dieses Problem wurde hauptsächlich durch einige Codezeilen im dnscrypt-proxy gelöst: Benutzer erhalten 30 Tage vor Ablauf des Zertifikats eine Informationswarnung, eine ernsthaftere Mitteilung 7 Tage vor Ablauf und eine kritische Nachricht, wenn weniger als 24 Stunden bis zum Ablauf verbleiben. Dies gilt nur für Zertifikate, die ursprünglich eine längere Gültigkeitsdauer hatten.
Solche Mitteilungen geben den Benutzern die Möglichkeit, die DNS-Betreiber über das bevorstehende Ablaufdatum des Zertifikats zu informieren, solange es noch nicht zu spät ist.
Wahrscheinlich hätten die Entwickler von Firefox von den Nutzern gehört, wenn alle eine solche Meldung erhalten hätten, und sie hätten das Ablaufen des Zertifikats verhindert. "Ich kann mich an keinen DNSCrypt-Server aus der Liste der öffentlichen DNS-Server erinnern, dessen Zertifikat in den letzten zwei oder drei Jahren abgelaufen ist," schreibt Frank Denis. In jedem Fall wäre es besser, die Nutzer zuerst zu warnen, als Erweiterungen ohne Vorwarnung zu deaktivieren.
Quelle: habr.com
