Früher liefen Zertifikate häufig ab, weil sie manuell aktualisiert werden mussten. Die Leute vergaßen einfach, dies zu tun. Mit dem Auftauchen von Let's Encrypt und dem automatischen Aktualisierungsprozess sollte das Problem gelöst sein. Aber die jüngste zeigt, dass es in Wirklichkeit nach wie vor aktuell ist. Leider laufen die Zertifikate weiterhin ab.
Falls jemand diese Geschichte verpasst hat: Um Mitternacht am 4. Mai 2019 hörten plötzlich fast alle Firefox-Erweiterungen auf zu funktionieren.
Wie sich herausstellte, trat der massenhafte Ausfall auf, weil bei Mozilla , das zur Signierung der Erweiterungen verwendet wurde, abgelaufen war. Daher wurden sie als „ungültig“ markiert und bestanden die Prüfung nicht (). In den Foren wurde als Übergangslösung empfohlen, die Überprüfung der Signaturen von Erweiterungen in about:config oder durch Zurücksetzen der Systemuhr zu deaktivieren.
Mozilla veröffentlichte umgehend den Patch Firefox 66.0.4, der das Problem mit dem ungültigen Zertifikat behebt, und alle Erweiterungen kehren in ihren normalen Zustand zurück. Die Entwickler empfehlen, ihn zu installieren und Umgehungslösungen für die Überprüfung der Signaturen zu verwenden, da diese mit dem Patch in Konflikt stehen könnten.
Dennoch zeigt diese Geschichte einmal mehr, dass die Ablauffrage von Zertifikaten nach wie vor ein aktuelles Problem ist.
In diesem Zusammenhang ist es interessant zu sehen, wie die Entwickler des Protokolls dieses Problem auf recht originelle Weise gelöst haben. Ihre Lösung kann in zwei Teile unterteilt werden. Erstens sind es kurzfristige Zertifikate. Zweitens die Warnung an die Benutzer über das Ablaufdatum von langfristigen.
DNSCrypt
DNSCrypt ist ein Protokoll zur Verschlüsselung von DNS-Verkehr. Es schützt die DNS-Kommunikation vor Abhör und Man-in-the-Middle-Angriffen und ermöglicht es, DNS-Anfragen zu umgehen.
Das Protokoll kapselt den DNS-Verkehr zwischen Client und Server in eine kryptografische Konstruktion und arbeitet über die Transportprotokolle UDP und TCP. Um es zu verwenden, müssen sowohl der Client als auch der DNS-Resolver DNSCrypt unterstützen. Zum Beispiel hat Yandex seit März 2016 es auf seinen DNS-Servern und im Browser aktiviert. Auch einige andere Anbieter, darunter Google und Cloudflare, haben ihre Unterstützung angekündigt. Leider sind es nicht so viele (auf der offiziellen Website sind 152 öffentliche DNS-Server aufgelistet). Aber das Programm Man kann es 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 mit diesem dessen Zertifikate. Dort befinden sich kurzfristige öffentliche Schlüssel für die Sitzung und eine Kennung der Verschlüsselungssätze. Es wird empfohlen, dass Clients für jede Anfrage einen neuen Schlüssel generieren, während Server die Schlüssel alle 24 Stunden wechseln. Bei der Schlüsselübergabe wird der Algorithmus X25519 verwendet, für die Signatur - EdDSA, für die Blockverschlüsselung - XSalsa20-Poly1305 oder XChaCha20-Poly1305.
Einer der Entwickler des Protokolls, Frank Denis , stellte fest, dass der automatische Wechsel alle 24 Stunden das Problem abgelaufener Zertifikate löste. Grundsätzlich akzeptiert der Referenz-Client dnscrypt-proxy Zertifikate mit jeder Gültigkeitsdauer, gibt jedoch die Warnung "Der Zeitraum der dnscrypt-proxy-Schlüssel für diesen Server ist zu lang" aus, wenn es länger als 24 Stunden gültig ist. Gleichzeitig wurde ein Docker-Image veröffentlicht, in dem ein schneller Schlüsselwechsel (und Zertifikate) implementiert wurde.
Erstens ist das äußerst nützlich für die Sicherheit: Wenn der Server kompromittiert wird oder der Schlüssel geleakt ist, kann der Datenverkehr von gestern nicht entschlüsselt werden. Der Schlüssel hat sich bereits geändert. Dies könnte ein Problem für die Umsetzung des "Jarowoj-Gesetzes" darstellen, das Anbieter zwingt, den gesamten Verkehr, einschließlich verschlüsselten, zu speichern. Es wird vermutet, dass es 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 bereitstellen, weil sie kurzfristige Schlüssel verwendet und alte löscht.
Aber das Wichtigste, schreibt Denis, ist, dass die kurzfristigen Schlüssel die Server von Anfang an zur Automatisierung zwingen. Wenn ein Server mit dem Netzwerk verbunden ist und die Skripte zum Wechseln der Schlüssel nicht eingerichtet oder nicht funktionsfähig sind, wird das sofort erkannt.
Wenn die Automatisierung die Schlüssel alle paar Jahre wechselt, kann man sich nicht darauf verlassen, und die Leute könnten das Ablaufdatum des Zertifikats vergessen. Bei einem täglichen Wechsel der Schlüssel wird dies sofort erkannt.
Es spielt keine Rolle, wie oft die Schlüssel gewechselt werden: jedes Jahr, jedes Quartal oder dreimal am Tag, solange die Automatisierung richtig eingestellt ist. Wenn alles über 24 Stunden funktioniert, wird es ewig 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 dem Docker-Image, das dies umsetzt, die Anzahl der Server mit abgelaufenen Zertifikaten effektiv reduziert und gleichzeitig die Sicherheit verbessert.
Einige Anbieter haben jedoch aus bestimmten technischen Gründen beschlossen, die Gültigkeitsdauer des Zertifikats auf mehr als 24 Stunden festzulegen. Dieses Problem wurde hauptsächlich mit einigen Codezeilen im dnscrypt-proxy gelöst: Die Benutzer erhalten eine Informationswarnung 30 Tage vor dem Ablauf des Zertifikats, eine weitere Nachricht mit höherem Ernstheitsgrad 7 Tage vor dem Ablauf und eine kritische Nachricht, wenn dem Zertifikat weniger als 24 Stunden bleiben. Dies betrifft nur Zertifikate, die ursprünglich eine lange Gültigkeit haben.
Solche Nachrichten geben den Benutzern die Möglichkeit, die DNS-Betreiber über das bevorstehende Ablaufdatum des Zertifikats zu informieren, bevor es zu spät ist.
Wenn alle Firefox-Benutzer eine solche Nachricht erhalten hätten, wäre sicherlich jemand den Entwicklern mitteilen und so ein Ablauf des Zertifikats hätte verhindert werden können. "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 ist es wahrscheinlich besser, die Benutzer zunächst zu warnen, als Erweiterungen ohne Vorwarnung zu deaktivieren.
Quelle: habr.com
