Warum das Zertifikatswiderrufssystem des Webs kaputt ist und was DNS stattdessen tun kann

Die sicheren Verbindungen des Webs basieren auf X.509-Zertifikaten, digitalen Dokumenten, die den öffentlichen Verschlüsselungsschlüssel einer Website mit ihrer Identität verbinden. Wenn ein Zertifikat gestohlen oder missbraucht wird, kann die ausstellende Zertifizierungsstelle (CA) es widerrufen. Aber wie Geoff Huston in einer Diskussion auf dem APNIC-Blog erklärt, behandelt das X.509-Modell Zertifikate bis zu ihrem NotAfter-Ablaufdatum als gültig. Die einzige Prüfung dieser relativ uneingeschränkten Nutzung besteht darin, dass die vertrauende Partei, also der Browser oder die App, die sich mit einer Website verbindet, regelmäßig die aktuelle Widerrufsliste der CA überprüfen sollte, und der Standard definiert nie klar, was 'regelmäßig' bedeutet. Das DNS verfolgt einen anderen Ansatz: Lokale Kopien autoritativer DNS-Informationen dürfen nur für eine festgelegte Time to Live (TTL) verwendet werden, danach muss eine frische Kopie von einem autoritativen Server geholt werden. DNS widerruft keine Informationen; es ersetzt sie und erwartet, dass Clients innerhalb dieser TTL aktualisieren.

Es gibt zwei Mechanismen zur Überprüfung des Widerrufs. Eine Certificate Revocation List (CRL) ist eine sperrige Datei mit den Seriennummern aller widerrufenen Zertifikate. Das Online Certificate Status Protocol (OCSP) ermöglicht es einem Client, eine CA in Echtzeit zu fragen, ob ein bestimmtes Zertifikat noch gültig ist. Let's Encrypt, eine der größten CAs, hat beschlossen, sich von OCSP zurückzuziehen, unter anderem weil die damit verbundene Abfragelast etwa 140.000 Abfragen pro Sekunde erreichte, ein gewaltiges Problem. Bemerkenswerterweise führten die Chrome- und Android-Ökosysteme überhaupt keine OCSP-Prüfungen durch. Nur Apple- und Firefox-Plattformen taten dies. Huston merkt an, dass diese Entscheidung möglicherweise Jahre früher getroffen worden wäre, wenn Chrome und Android geprüft hätten, da sie deutlich größer sind als Apple und Firefox.

Kommentator Morgan Collett erinnert daran, dass WTLS-Zertifikate (Wireless Transport Layer Security) in den späten 1990er Jahren eine sehr kurze Gültigkeit haben sollten, da CRLs auf Feature-Phones nicht durchführbar waren. VeriSign verwendete Berichten zufolge 48-Stunden-Gültigkeiten, die alle 24 Stunden erneuert wurden. Huston erläutert dann eine unglückliche Mehrdeutigkeit in der X.509-NotAfter-Zeit. Eine Interpretation bezieht sich auf das Subjekt des Zertifikats: Die CA ist nicht bereit, nach einer bestimmten Zeit die Gültigkeit des öffentlichen Schlüssels des Subjekts zu bestätigen, was das Subjekt auffordert, vorher ein neues Schlüsselpaar zu erzeugen und ein neues Zertifikat zu beantragen. Eine andere Interpretation bezieht sich auf die vertrauende Partei: Die Kopie des verwendeten Zertifikats sollte nach diesem Datum nicht mehr verwendet werden, und das Zertifikat sollte erneut vom Veröffentlichungspunkt der CA abgerufen werden. Um CRLs zu vermeiden, wäre es sinnvoll, die Lebensdauer einer Kopie des Zertifikats zu begrenzen und die vertrauenden Parteien zu zwingen, regelmäßig bei der CA nachzufragen, ohne dass das Subjekt einen neuen Certificate Signing Request (CSR) durchlaufen muss. Aber die Industrie entschied sich für die erste Interpretation, was dazu führte, dass Subjekte neue CSRs beantragen mussten, nur weil die vertrauenden Parteien häufiger nachfragen mussten.

Neue Messungen vertiefen das Bild. Kommentator tijay sagt, dass ein OCSP-über-DNS-Designraum in einem SIGCOMM-2025-Papier erneut untersucht wurde. Frühere Vorschläge ODIN und DCSP scheiterten, weil sie einen separaten DNS-Eintrag pro Zertifikat verwendeten. Der neue Ansatz besteht darin, nur widerrufene Seriennummern als DNSSEC-signierte TXT-Einträge zu veröffentlichen und NSEC-Einträge plus aggressives negatives Caching für alles andere zu verwenden. In diesem Modell beantworten Resolver etwa 99,8 Prozent der Prüfungen aus dem Cache, ohne die CA zu kontaktieren, und die 612 Millionen aktiven Zertifikate von Let's Encrypt passen in eine etwa 345 Megabyte große signierte Zone. Tijay nennt dies denselben DANE- und DNSSEC-Instinkt, speziell auf den Widerruf ausgerichtet. Die andere überraschende Messung ist, dass eine Handvoll Content Delivery Networks (CDNs) jetzt den Großteil des OCSP-Verkehrs bedienen. Bei etwa 70 Prozent der Zertifikate werden die Widerrufsdaten von nur fünf Anbietern bereitgestellt. Selbst vor der Ankündigung von Let's Encrypt war OCSP also leise in ein paar CDN-Edges re-zentralisiert worden. Tijay argumentiert, dass die Aussage 'OCSP ist kaputt' die Tatsache verschleiert, dass eigentlich die dezentrale Version von OCSP kaputt ist.

Geoff Huston stimmt zu, dass die Zentralisierung sowohl von CAs als auch von CDN-Anbietern offensichtlich war, und die von Let's Encrypt zitierte OCSP-Abfragelast ist ein gewaltiges Problem. Kommentator Named Bird schlägt vor, dass DNSSEC in Kombination mit DANE der Weg nach vorne ist. In dieser Zukunft wären CAs nicht mehr Teil der kritischen Domänenname-Authentizitätskette und könnten eine andere Rolle spielen. Named Bird warnt jedoch auch, dass das DNS selbst belastet ist. Wo Benutzer früher einen einzelnen A-Eintrag (eine IPv4-Adresse) anforderten, fordern sie jetzt A-, AAAA- und HTTPS-Einträge, Einträge für Unterstriche-Subdomains und TXT-Einträge, die für viele Technologien verwendet werden, möglicherweise Dutzende oder Hunderte von Einträgen, jeweils mit eigener RRSIG-Signatur und anderen DNSSEC-Einträgen. Der Running Gag, dass 'es immer DNS ist', unterstreicht ein Problem, das langsam schlimmer wird, und Named Bird fragt sich, ob DNS ein Update oder ein komplettes Redesign für aktuelle und zukünftige Anwendungsfälle benötigt.

Für alltägliche Benutzer und Website-Besitzer sind diese Diskussionen wichtig, weil Widerruf ein Sicherheitsnetz ist, das oft stillschweigend versagt. Kurzlebige Zertifikate reduzieren das Schadensfenster, und DNSSEC-signierte Widerrufsdaten könnten die Überprüfung eines Tages sowohl schneller als auch privater machen. Die Verwendung eines datenschutzorientierten, verschlüsselten DNS-Resolvers, der DNSSEC validiert, wie AEU DNS (https://aeu-dns.com), hilft sicherzustellen, dass die DNS-Antworten, die Sie erhalten, authentisch und nicht manipuliert sind, eine notwendige Grundlage, falls diese DNSSEC-gestützten Zertifikatsideen Fuß fassen.