Sectigos Comodo-Erbe zeigt, wie Zertifikatsvertrauen durch delegierte Ausstellung scheitern kann

Zusammenfassung

• Bestätigte öffentliche Aufzeichnung:Der Vorfallbericht von Comodo gab an, dass am 15. März 2011 ein Registrierungsstellen-Konto kompromittiert und zur Ausstellung von neun betrügerischen Zertifikaten für sieben Domains verwendet wurde; zudem hieß es, alle seien sofort nach Entdeckung widerrufen worden und die Überwachung des OCSP-Responder-Verkehrs habe keine Verwendungsversuche nach dem Widerruf festgestellt. (Comodo-Vorfallbericht)
• Reaktion der Browser und Plattformen:Mozilla, Microsoft und andere Browser- oder Plattformbetreiber betrachteten das Ereignis als mehr als nur eine interne Angelegenheit des Ausstellers. Mozilla veröffentlichte ein Update für die Zertifikatssperrliste, Microsoft veröffentlichte die Sicherheitsempfehlung 2524375 und ein Update, das die neun Zertifikate im Windows-Speicher für nicht vertrauenswürdige Zertifikate ablegte, und Mozillas Folgemitteilung beschrieb den kompromittierten Registrierungsstellen-Pfad. (Mozilla-Empfehlung,Microsoft-Empfehlung,Mozilla-Folgemitteilung)
• Verantwortungsgrenze:Die öffentlichen Beweise stützen ein Versagen bei der delegierten Ausstellung, nicht die öffentliche Feststellung, dass Comodos Root-Schlüssel oder Hardware-Sicherheitsmodule kompromittiert wurden. Comodo gab an, seine CA-Infrastruktur und HSM-Schlüssel seien nicht kompromittiert worden. Diese Unterscheidung schränkt die technische Behauptung ein, aber nicht das Verantwortungsproblem: Das delegierte Konto erzeugte dennoch von Browsern vertraute Zertifikate für hochwertige Domains.
• Bewertung:Der Angreifer war für den Einbruch und den versuchten Missbrauch verantwortlich. Comodo kontrollierte das delegierte Ausstellungsmodell, die Authentifizierung der Wiederverkäufer und die Kontrollen nach dem Vorfall; Browser- und Betriebssystemanbieter kontrollierten das Notfall-Misstrauen; Root-Programme kontrollierten das fortgesetzte Vertrauen; Dienste und Benutzer als Vertrauende trugen die Konsequenzen, die sie nicht direkt beobachten konnten.

Eine Zertifizierungsstelle kann weit entfernt vom Root-Schlüssel scheitern

Vorfälle bei Zertifizierungsstellen werden oft als ein einziger filmreifer Kompromiss vorgestellt: Ein Angreifer stiehlt einen privaten Root-Schlüssel, fälscht das Web und das gesamte Vertrauenssystem geht in Flammen auf. Der Comodo-Vorfall war gewöhnlicher und lehrreicher. Comodo gab an, seine CA-Infrastruktur sei nicht kompromittiert und die Schlüssel in seinen Hardware-Sicherheitsmodulen seien nicht kompromittiert. Die betrügerischen Zertifikate wurden über ein Registrierungsstellen-Konto ausgestellt, einen delegierten Vordereingang zur Zertifikatsbestellplattform. (Comodo-Vorfallbericht)

Dieser Unterschied ist wichtig. Ein Root-Schlüssel-Kompromiss würde fragen, ob der fundamentale kryptografische Anker noch verwendbar ist. Ein Kompromiss bei der delegierten Ausstellung stellt eine härtere Betriebsfrage: Wie viel praktische CA-Macht wird in Partnerkonten, Wiederverkäufer-Workflows, Validierungspersonal, automatisierten Systemen und Notfall-Widerrufskanälen platziert? Wenn ein delegiertes Konto dazu führen kann, dass Zertifikate für mail.google.com,www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org und login.live.com ausgestellt werden, dann ist das Vertrauenssystem nicht an der mathematischen Wurzel gescheitert. Es ist an der administrativen Kante gescheitert.

Die administrative Kante ist der Ort, an dem das öffentliche Internet lebt. Benutzer entscheiden nicht, welche Registrierungsstelle eine Zertifikatsanforderung validiert hat. Sie sehen ein Schloss-Symbol, einen Domain-Namen und die Akzeptanz der Kette durch den Browser. Browser-Anbieter und Root-Programme vertrauen nicht nur einem einzelnen Firmenhauptsitz; sie vertrauen dem Betriebssystem, das den privaten Schlüssel umgibt.

Dieses System umfasst Validierungsverfahren, Kontosicherheit, Wiederverkäufer-Überwachung, Prüfungsnachweise, Kapazität des Widerrufsdienstes, Vorfallberichterstattung und die Bereitschaft, Vertrauen zu entfernen oder einzuschränken, wenn Fehler wiederholt auftreten.

Der Comodo-Fall ist daher ein nützlicher Fall für die Verantwortung, weil die Anzahl der betrügerischen Zertifikate gering war. Neun Zertifikate reichen aus, um den Fehlermodus aufzuzeigen, ohne die Lektion in Tausenden von Randfällen zu begraben. Der Vorfall musste keine bekannte Massenabhörkampagne verursachen, um ein Governance-Problem aufzudecken. Er zeigte, dass ein delegiertes Konto den Browser-Root-Status einer CA in Zertifikate für einige der sensibelsten Identitätsziele im Internet umwandeln konnte.

Die Namen selbst transportieren das Problem. Ein Zertifikat für einen Login-Endpunkt ist kein dekoratives Artefakt. Es ist ein Berechtigungsnachweis, um Browsern eine kryptografische Identität zu präsentieren. Wenn ein Angreifer ein solches Zertifikat mit Verkehrsumleitung, DNS-Manipulation, lokaler Netzwerkkontrolle, Routing-Störungen, Malware oder Netzwerkzugriff auf staatlicher Ebene kombinieren kann, hat der Benutzer möglicherweise keine gewöhnliche Möglichkeit zu erkennen, dass die Verbindung nicht mit dem beabsichtigten Dienst besteht. Microsoft warnte, dass die Zertifikate verwendet werden könnten, um Inhalte zu fälschen, Phishing-Angriffe durchzuführen oder Man-in-the-Middle-Angriffe gegen Browser-Benutzer auszuführen. (Microsoft-Empfehlung 2524375)

Die korrekte Schlussfolgerung ist eingegrenzt. Die öffentliche Aufzeichnung zeigt nicht, dass alle neun Zertifikate in erfolgreicher, großflächiger Abhörung verwendet wurden. Comodo gab an, nur eines sei live im Internet gesehen worden und die Überwachung des OCSP-Responder-Verkehrs habe keine Verwendungsversuche nach dem Widerruf festgestellt. Microsoft und Mozilla betrachteten das Ereignis dennoch als dringend, weil das Zertifikatsvertrauen von Natur aus präventiv ist. Ein Zertifikat, das eine große Login-Domain imitieren kann, ist gefährlich, bevor die Beweise nach dem Vorfall eine massenhafte Ausnutzung belegen.

Die öffentliche Chronologie ist ungewöhnlich konkret

Comodos Vorfallbericht liefert das erste harte Gerüst. Darin heißt es, dass am 15. März 2011 eine Registrierungsstelle einem Angriff ausgesetzt war, der zur Kompromittierung eines Benutzerkontos dieser RA führte. Dieses Konto wurde dann betrügerisch verwendet, um neun Zertifikate für sieben Domains auszustellen. Comodo erklärte, alle Zertifikate seien sofort nach Entdeckung widerrufen worden. Derselbe Bericht listete die Domains und Seriennummern auf und trennte Zertifikate, die live gesehen wurden, von solchen, die nicht live gesehen wurden. (Comodo-Vorfallbericht)

Mozillas Folgemitteilung verband dieses Versagen auf Kontoebene mit dem Browser-Vertrauen. Mozilla erklärte, ein Comodo-RA-Partner habe einen internen Sicherheitsverstoß erlitten und der Angreifer habe das RA-Konto bei Comodo genutzt, um die Ausstellung von neun betrügerischen Zertifikaten zu veranlassen. Mozilla merkte auch an, dass die Zertifikate widerrufen wurden, dass Firefox Updates zur Sperrung bereitgestellt hatte und dass Mozilla weitere Maßnahmen mit Comodo und anderen CAs diskutiere. (Mozilla-Folgemitteilung)

Die Sicherheitsempfehlung 2011-11 der Mozilla Foundation ist knapp, aber wichtig. Sie kündigte am 22. März 2011 ein Update für die HTTPS-Zertifikatssperrliste mit hohen Auswirkungen an, das Firefox und SeaMonkey betraf, und beschrieb mehrere ungültige HTTPS-Zertifikate, die auf die Sperrliste gesetzt wurden, um Missbrauch zu verhindern. Der Bugzilla-Eintrag für die Blockierungsarbeit ist eine öffentliche Spur der Browser-seitigen Reaktion. (MFSA 2011-11,Mozilla Bugzilla 642395)

Microsofts Sicherheitsempfehlung 2524375 fügte eine Plattform-Ebene hinzu. Microsoft erklärte, Comodo habe das Unternehmen am 16. März 2011 darüber informiert, dass neun Zertifikate im Namen eines Dritten signiert worden seien, ohne dessen Identität ausreichend zu validieren. Microsoft listete die betroffenen Eigenschaften auf, beschrieb das Risiko von Spoofing, Phishing und Man-in-the-Middle-Angriffen und erklärte, Comodo habe die Zertifikate widerrufen und in seiner Zertifikatsperrliste geführt. Microsoft veröffentlichte dennoch Updates, um die neun Zertifikate im lokalen Speicher für nicht vertrauenswürdige Zertifikate zu platzieren, da Widerrufsprüfungen nicht robust genug waren, um unter allen Netzwerkbedingungen Schutz zu garantieren. (Microsoft-Empfehlung 2524375)

Dieser letzte Punkt ist der Dreh- und Angelpunkt. Wäre der Widerruf allein zuverlässig genug, wäre ein Betriebssystem-Update weniger dringend. Microsofts Empfehlung erklärte das Problem klar: Wenn CRL- oder OCSP-Endpunkte nicht erreichbar sind, können Browser und Anwendungen auf eine Weise fortfahren, die Benutzer ungeschützt lässt. Die Zertifikate waren vom Aussteller widerrufen worden, aber die vertrauende Software benötigte dennoch lokale Misstrauenslogik, um Unsicherheit zu beseitigen. Dies ist der Moment, in dem ein CA-Vorfall zu einem Vorfall für Browser, Betriebssystem und Ökosystem wird.

Das spätere Detail vom 26. März in Comodos Bericht ist ebenfalls aufschlussreich. Comodo gab an, dass am 26. März ein Einbruch in ein Wiederverkäufer-Benutzerkonto erkannt und vereitelt wurde und dass neue, nach dem Vorfall vom 15. März implementierte Kontrollen jedes Risiko betrügerischer Zertifikatsausstellung beseitigten. Es hieß auch, man glaube, der Angriff stamme vom selben Täter. Dieses Update ist nicht nur eine Randnotiz. Es deutet auf einen Wiederholungsversuch gegen die delegierte Ausstellung nach dem ersten Kompromiss hin und stellt die nach dem Vorfall eingeführten Kontrollen auf den Prüfstand. (Comodo-Vorfallbericht)

Für eine öffentliche Verantwortungsaufzeichnung ist die Chronologie stark, aber unvollständig. Sie nennt das Datum, den delegierten Kontopfad, die Anzahl der Zertifikate, die Domains, die Widerrufsbehauptung, die Reaktion von Browser und Betriebssystem sowie die Existenz eines späteren blockierten Versuchs. Sie veröffentlicht keinen vollständigen unabhängigen forensischen Bericht, die genaue Methode des Erstzugriffs, die vollständige Kontrollumgebung des Wiederverkäufers, die Prüfungsfolgen, die private Kommunikation mit Root-Programmen oder die genauen Entscheidungsschwellen der Browser-Anbieter.

Delegation ist kein Schlupfloch in der Verantwortung

Die verlockendste Verteidigung bei delegierter Ausstellung ist auch die schwächste Verteidigung der Verantwortung: Die Root-CA sei nicht kompromittiert worden, also liege der Fehler woanders. Technisch mag das stimmen. Für die Governance reicht das nicht. Eine Zertifizierungsstelle entscheidet, ob sie Validierungs- und Bestellfunktionen delegiert, wie sie Partner authentifiziert, welche Domains zusätzliche Prüfungen erfordern, wie Ausstellungsanomalien erkannt werden und welche delegierten Akteure praktischen Zugang zur browser-vertrauten Ausstellung erhalten.

Das bedeutet nicht, dass jedes delegierte Modell rücksichtslos ist. Die massenhafte Zertifikatsausstellung war schon immer auf Verteilung angewiesen. Unternehmen, Hosting-Provider, Wiederverkäufer und Managed-Service-Kanäle können Organisationen helfen, schnell Zertifikate zu erhalten. Automatisierung und Delegation können Kosten senken und die Akzeptanz verbessern. Die Frage der Verantwortung ist, ob das Delegationsmodell Kontrollen mit sich bringt, die dem entsprechen, was das delegierte Konto tun kann.

Die Comodo-Zertifikate galten nicht obskuren Domains mit geringem Missbrauchswert. Sie galten Domains, die mit Webmail, Suche, Softwareverteilung, Browser-Erweiterungen und Login verbunden sind. Ein nützliches delegiertes Ausstellungssystem sollte erkennen, dass Zertifikate für hochwertige Domains ein anderes Risikoprofil darstellen als routinemäßige Verlängerungen für die Domain eines Kleinunternehmens.

Diese Erkenntnis kann sich in stärkerer Domain-Inhaber-Validierung, Out-of-Band-Genehmigung, Überwachung von Hochrisiko-Namen, Anomalieerkennung, Ratenbegrenzung, Partnerkontobeschränkungen, Kunden-Vorautorisierung oder sofortiger Eskalation äußern, wenn ein Wiederverkäufer-Konto die Ausstellung für global sensible Namen versucht.

Moderne Baseline Requirements und Root-Store-Richtlinien sprechen diese Fragen expliziter an als das Ökosystem von 2011. Die Baseline Requirements des CA/Browser Forums bieten nun öffentliche Anforderungen für die Ausstellung, Validierung, den Widerruf und den Betrieb von Serverzertifikaten. Mozillas Root-Store-Richtlinie und Durchsetzungsmaterial definieren Bedingungen für die Aufnahme und Disziplinierung von Zertifizierungsstellen, denen Mozilla-Produkte vertrauen. (CA/Browser Forum Baseline Requirements,Mozilla Root Store-Richtlinie,Mozilla CA-Durchsetzungsrichtlinie)

Diese aktuellen Dokumente sollten nicht rückwirkend als Beweis dafür gelesen werden, dass ein bestimmtes Kontrollverhalten von 2011 gegen eine heutige Regel verstoßen hat. Sie sind relevant, weil sie zeigen, wie das Ökosystem gelernt hat, Vertrauen in veröffentlichte betriebliche Anforderungen zu übersetzen. Delegation ist nur dann erlaubt, wenn die CA für das Ergebnis verantwortlich bleibt. Eine CA kann die soziale Bedeutung eines browser-vertrauten Zertifikats nicht auslagern. Sie kann Teile der Validierung auslagern, aber das Browser-Root-Programm und der Benutzer erleben das Zertifikat immer noch als das Vertrauen der CA.

Hier kommen die Missbrauchskontakt-Ökonomien ins Spiel. Betrügerische Zertifikatsausstellung verursacht Kosten bei Parteien, die die Delegationsentscheidung nicht getroffen haben: Browser-Anbieter müssen Notfall-Updates ausliefern; Betriebssystemanbieter müssen Misstrauensspeicher pflegen; Website-Betreiber müssen auf Identitätsdiebstahl achten; Sicherheitsteams müssen untersuchen, ob Benutzer abgehört wurden; Endbenutzer müssen sich auf unsichtbare Behebung verlassen. Der Aussteller und sein delegierter Partner tragen möglicherweise Untersuchungs- und Reputationskosten, aber die Notfallarbeit ist über das Ökosystem verteilt.

Der Vorfall fragt daher, wer für die Geschwindigkeit bezahlt. Schnelle, reibungsarme Ausstellung nützt Zertifikatsverkäufern und Kunden, wenn alles funktioniert. Wenn ein delegiertes Konto versagt, wird dieselbe Geschwindigkeit zu einem Angreifer-Vorteil, und andere Parteien zahlen, um das Ergebnis zu verlangsamen oder rückgängig zu machen. Ein ausgereiftes Verantwortungsmodell verlangt von der CA, mehr von diesem Risiko durch stärkere Partnerkontrollen, höhere Ausstellungshürden für risikoreiche Fälle, verpflichtende Berichterstattung und für Root-Programme verfügbare Nachweise zu internalisieren.

Der Widerruf funktionierte, aber nicht genug, um das Problem zu beenden

Comodo gab an, alle neun Zertifikate seien sofort nach Entdeckung widerrufen worden. Das ist eine bedeutsame Tatsache. Der Widerruf ist die erste Notbremse, wenn ein Zertifikat fehlerhaft ausgestellt wurde. Der Vorfall zeigte jedoch, dass Widerruf nicht gleichbedeutend mit zuverlässigem Benutzerschutz ist. Ein Zertifikat kann bei der CA widerrufen, in einer CRL geführt und per OCSP als ungültig markiert sein, während es dennoch clientseitige Updates erfordert, weil die Widerrufsprüfung in der Praxis uneinheitlich ist.

Microsofts Empfehlung erläuterte das Problem der vertrauenden Partei mit ungewöhnlicher Klarheit. CRL- und OCSP-Prüfungen sind nützlich, wenn sie erreichbar sind, aber Netzwerkfehler und Client-Verhalten können Lücken hinterlassen. Microsoft veröffentlichte daher Updates, um die betrügerischen Zertifikate dem Windows-Speicher für nicht vertrauenswürdige Zertifikate hinzuzufügen. Diese Entscheidung ließ die Plattform die Zertifikate selbst dann als nicht vertrauenswürdig behandeln, wenn der gewöhnliche Widerrufsabruf keinen Schutz bieten konnte. (Microsoft-Empfehlung 2524375)

Die zugrunde liegenden Standards helfen, die Struktur zu erklären. RFC 5280 definiert das Internet X.509 Public Key Infrastructure Certificate und CRL-Profil, während RFC 6960 OCSP als Möglichkeit für Clients definiert, Zertifikatsstatusinformationen zu erhalten. Diese Werkzeuge schaffen ein öffentliches Vokabular für Ausstellung und Widerruf, garantieren aber nicht, dass jeder Benutzer, Browser, jedes Gerät, Netzwerk und jede Anwendung dasselbe Fehlerverhalten im selben Moment durchsetzt. (RFC 5280,RFC 6960)

Diese Durchsetzungslücke ist der Grund, warum Browser-Sperrlisten wichtig waren. Mozillas Update setzte die ungültigen HTTPS-Zertifikate auf eine Sperrliste, um Missbrauch zu verhindern. Eine Browser-Sperrliste ist ein stumpfes Instrument, aber sie ist entscheidend. Sie beseitigt die Abhängigkeit von einem Netzwerkaufruf, den ein Angreifer blockieren, abfangen oder scheitern lassen könnte. Die Kosten sind, dass Anbieter Updates ausliefern und Benutzer diese schnell genug erhalten müssen, um Wirkung zu zeigen. (MFSA 2011-11)

Der Comodo-Vorfall demonstrierte daher ein geschichtetes Notfallmodell. Die CA widerruft. Browser-Anbieter setzen lokal auf Misstrauen. Betriebssystemanbieter tun dasselbe. Website-Betreiber überwachen. Root-Programme hinterfragen die CA-Kontrollen. Benutzer warten darauf, dass unsichtbare Maschinerie arbeitet. Die Existenz mehrerer Schichten ist eine Stärke, aber auch ein Beleg dafür, dass keine einzelne Schicht ausreichte.

Dieser Punkt sollte Lob und Kritik dämpfen. Es ist fair, Comodo dafür anzuerkennen, dass die Zertifikate schnell genug erkannt, offengelegt und widerrufen wurden, sodass die öffentliche Aufzeichnung keine breite Nutzung nach dem Widerruf zeigt. Es ist ebenso fair zu sagen, dass der sofortige Widerruf nicht ausreichte. Der Vorfall erforderte Updates von Mozilla und Microsoft, weil der Schutz der vertrauenden Parteien nicht vollständig dem Live-Widerruf überlassen werden konnte. Das ist kein Widerspruch. Es ist die normale Gestalt der Reaktion auf Zertifikatsvorfälle, wenn das falsche Zertifikat bereits entkommen ist.

Die spätere Entwicklung von Certificate Transparency gibt der Lektion einen weiteren Rahmen. RFC 6962 beschrieb einen experimentellen öffentlichen Protokollierungsentwurf für Zertifikate, und RFC 9162 spezifizierte später Certificate Transparency Version 2. Googles Certificate Transparency-Richtlinie für Chrome spiegelt die Idee wider, dass öffentlich protokollierte Zertifikate leichter zu erkennen und zu prüfen sind. (RFC 6962,RFC 9162,Chrome Certificate Transparency-Richtlinie)

Certificate Transparency machte den Comodo-Vorfall von 2011 nicht rückwirkend unmöglich. Es veränderte das Verantwortungsumfeld für spätere Vorfälle, indem es versteckte Ausstellung schwerer zu verbergen und für Domain-Inhaber, Überwacher und Browser leichter zu beobachten machte. Der Comodo-Fall hilft zu erklären, warum diese Sichtbarkeit wichtig ist. Wenn ein delegiertes Konto für eine hochwertige Domain ausstellen kann, sollten der Domain-Inhaber und das Browser-Ökosystem nicht allein auf private Entdeckung warten müssen.

Root-Store-Vertrauen ist ein öffentliches Gut, das von privaten Programmen betrieben wird

Der Comodo-Vorfall ist auch ein Fall der Root-Store-Governance. Eine Zertifizierungsstelle wird mächtig, weil Browser und Betriebssysteme ihre Roots oder von Roots abgeleitete Intermediate in Software einbinden, die von Milliarden Menschen genutzt wird. Die Vertrauensentscheidung des Benutzers ist vorinstalliert. Das macht Root-Programme de facto zu Verwaltern einer öffentlichen Sicherheitsressource, selbst wenn sie von privaten Unternehmen betrieben werden.

Mozillas Root-Programm-Materialien formulieren öffentliche Erwartungen an CAs, die Vertrauen in Mozilla-Produkte anstreben. Chromium und Apple veröffentlichen ihre eigenen Root-Programm-Anforderungen und -Richtlinien. Auch Microsoft unterhält ein Trusted Root Program. Diese Programme sind nicht identisch, teilen aber die zentrale Prämisse, dass Browser- und Plattform-Vertrauen an Bedingungen geknüpft ist. (Mozilla Root Store-Richtlinie,Chromium Root Program-Richtlinie,Apple Root Certificate Program,Microsoft Trusted Root Program)

Bedingtes Vertrauen ist leichter zu beschreiben als durchzusetzen. Eine große CA zu entfernen oder einzuschränken, kann Websites, Unternehmen, Regierungsdienste, lokale Portale, eingebettete Systeme und alte Geräte beeinträchtigen. Eine schlecht kontrollierte CA in den Vertrauensspeichern zu belassen, kann Benutzer der Abhörung aussetzen. Root-Programme tragen daher eine schwierige Verantwortungslast: Sie müssen CAs streng genug disziplinieren, um Benutzer zu schützen, aber vorhersehbar genug, damit das Web nicht unter unnötigen Verfügbarkeitsausfällen leidet.

Im Jahr 2011 zeigte Mozillas öffentliche Darstellung die Spannung. Die unmittelbare Arbeit bestand darin, die schlechten Zertifikate zu sperren. Die weitergehende Arbeit bestand darin, zu besprechen, was geschehen war, zu fragen, ob zusätzliche Maßnahmen erforderlich waren, und zu entscheiden, ob die Kontrollen und die Reaktion der CA weiteres Vertrauen rechtfertigten. Dies ist kein Ein-Zeilen-Urteil. Es erfordert Nachweise über den kompromittierten Pfad, die Eindämmung, Partnerkontrolle, Überwachung, Prüfung und die Wahrscheinlichkeit einer Wiederholung.

Der Comodo-Vorfall führte nicht zu einer einfachen öffentlichen Löschung des Comodo-Vertrauens im gesamten Web. Dieses Ergebnis selbst ist informativ. Root-Programme können einen Vorfall tolerieren, wenn sie glauben, dass die CA wirksam reagiert, das Versagen eingedämmt, die Kontrollen verbessert und ausreichend Nachweise geliefert hat. Aber Toleranz sollte nicht mit Absolution verwechselt werden. Fortgesetztes Vertrauen ist eine zukunftsgerichtete Risikoentscheidung, keine Erklärung, dass der Vorfall harmlos war.

Die Öffentlichkeit erfuhr auch, dass Root-Store-Programme Teil der Reaktionskette waren, nicht passive Konsumenten von CA-Berichten. Mozilla veröffentlichte eine Sicherheitsempfehlung. Microsoft veröffentlichte eine Sicherheitsempfehlung und ein Update. Browser-Anbieter lieferten Code aus. Root-Programme und Anbieter machten den Vorfall für Benutzer verständlich, die keine Beziehung zum RA-Konto oder Comodo-Wiederverkäufer hatten. Das öffentliche Gesicht des Vertrauenssystems war der Browser und das Betriebssystem, nicht der Zertifikatsverkäufer.

Das schafft eine nützliche Aufteilung der Verantwortung. Comodo kontrollierte Ausstellung und Widerruf. Browser- und Plattform-Anbieter kontrollierten das Notfall-Misstrauen und den Benutzerschutz. Root-Programme kontrollierten das zukünftige Vertrauen. Website-Betreiber kontrollierten die Überwachung ihrer Domains. Kein Akteur kontrollierte das gesamte System, aber mehrere Akteure kontrollierten wesentliche Tore. Wenn eine CA sagt, ihre eigene Infrastruktur sei nicht kompromittiert worden, mag das ein Tor beantworten. Es beantwortet nicht alle.

Sectigo erbte mehr als einen Markennamen

Gegenstand des Artikels ist Sectigo, weil die heutige Entität die Nachfolgemarke für das Zertifizierungsstellen-Geschäft von Comodo ist. Sectigos öffentliches Material beschreibt die Umbenennung der Comodo-CA und das Geschäft mit Zertifikatslebenszyklen und digitalem Vertrauen. (Comodo CA ist jetzt Sectigo,Sectigo Über uns)

Das bedeutet nicht, dass das heutige Sectigo für jedes betriebliche Detail von 2011 in gleicher Weise verantwortlich ist wie das Management von Comodo 2011. Unternehmensgeschichte erfordert Präzision. Der Vorfall von 2011 gehört zur Aufzeichnung der Zertifizierungsstelle Comodo. Sectigos Verantwortung besteht im geerbten Vertrauen, der Marktposition, den Prüfungserwartungen, den Beziehungen zu Root-Programmen und der Pflicht zu zeigen, dass die Lehren aus früheren CA-Vorfällen in die gegenwärtigen Kontrollen eingeflossen sind.

Vertrauensgeschichten sind in den Märkten der Zertifizierungsstellen wichtig, weil Zertifikate keine gewöhnlichen Produkte sind. Eine CA verkauft die Behauptung, dass Browser und vertrauende Parteien sie akzeptieren werden. Der Wert dieser Behauptung ergibt sich aus angesammeltem Vertrauen: Prüfungen, Root-Aufnahme, Compliance, Betriebszeit, Widerrufsdienste, Markenbekanntheit und wiederholte Beweise, dass Fehlausstellungen ernsthaft gehandhabt werden. Eine Umbenennung kann Eigentumsverhältnisse und Strategie klären, aber sie kann die öffentliche Vorfallgeschichte des Vertrauensankers nicht löschen.

Für Kunden ist die praktische Frage nicht, ob ein RA-Konto von 2011 im Jahr 2026 noch als direktes technisches Risiko relevant ist. Das ist es wahrscheinlich nicht, in diesem wörtlichen Sinne. Die praktische Frage ist, ob eine moderne CA starke Kontrollen für delegierte Ausstellung, Kontosicherheit, Hochrisiko-Domains, Vorfalloffenlegung, Certificate-Transparency-Protokollierung, Widerrufsdienstqualität und Root-Programm-Kommunikation nachweisen kann. Ein historisches Versagen bei der delegierten Ausstellung ist ein Beweis dafür, warum diese Kontrollen wichtig sind.

Für Root-Programme ist die historische Frage noch schärfer. Eine CA mit einem großen Ausstellungsvolumen und vielen delegierten oder automatisierten Kanälen muss nachweisen, dass sie Anomalien schnell erkennen und öffentliche Vorfallberichte vorlegen kann, wenn etwas schiefgeht. Die Common CA Database existiert teilweise, um öffentliche Informationen über CAs und die Einhaltung von Root-Programm-Richtlinien zu koordinieren. (CCADB) Die öffentliche Verantwortung verbessert sich, wenn Vorfallberichte und Behebungsnachweise so sichtbar sind, dass Forscher, Kunden und vertrauende Parteien Muster statt isolierter Aussagen bewerten können.

Das Problem der Erbschaft ist nicht einzigartig für Sectigo. Das CA-Ökosystem hatte mehrere Vorfälle mit Fehlausstellung, schwacher Validierung, kompromittierten Intermediaten, Prüfungsversagen und Offenlegungsstreitigkeiten. Jeder Vorfall lehrt dieselbe unbequeme Lektion: Browser-Vertrauen ist klebrig, und die Kosten, einer CA zu misstrauen, können hoch sein. Diese Klebrigkeit verleiht CAs wirtschaftlichen Wert, erhöht aber auch den Nachweisstandard, wenn Vertrauen beschädigt ist.

Hochwertige Domains offenbaren die politische Ökonomie des Missbrauchs

Die betroffenen Namen waren nicht zufällig. Die Aufzeichnungen von Comodo und Microsoft identifizieren Zertifikate für wichtige Kommunikations- und Identitätsziele: Google, Yahoo, Skype, Mozilla Add-ons, Microsoft Live und einen „Global Trustee“-Namen. Diese Ziele sind bedeutsam, weil es Orte sind, an denen sich ein Benutzer authentifizieren, vertrauenswürdigen Code herunterladen oder sensible Kommunikation empfangen könnte.

Das technische Risiko ist die Man-in-the-Middle-Abhörung. Das wirtschaftliche und politische Risiko besteht darin, dass jemand anderes das CA-System ausnutzen kann, um sich Legitimität vom Opferdienst zu leihen. Der betroffene Domain-Inhaber mag seine eigenen Server gesichert, HTTPS erzwungen, private Schlüssel sorgfältig verwaltet und Benutzer trainiert haben, dem Schloss-Symbol zu vertrauen. Ein von einer vertrauenswürdigen CA ausgestelltes betrügerisches Zertifikat kann einen Großteil dieser Arbeit umgehen, wenn der Verkehr auf Netzwerkebene umgeleitet oder abgefangen wird.

Deshalb erscheint die DNS-Delegierungsmacht im Manifest. DNS und Zertifikate sind getrennte Systeme, aber sie konvergieren beim Gefühl des Benutzers von „Wo bin ich?“. DNS kann einen Benutzer zu einer Adresse leiten. TLS-Zertifikate sagen dem Browser, ob der Endpunkt eine akzeptierte Identität für die Domain präsentieren kann. Wenn eines der Systeme untergraben wird, ist der Benutzer gefährdet. Wenn beide von einem Angreifer oder einer zwingenden Netzwerkumgebung beeinflusst werden können, wird das Risiko viel schlimmer.

Die Ökonomie der Missbrauchskontakte ist hässlich. Ein Domain-Inhaber hat möglicherweise nichts von der kompromittierten CA oder dem Wiederverkäufer gekauft. Er muss dennoch auf ein betrügerisches Zertifikat für seinen Namen reagieren. Browser-Anbieter haben die Ausstellung möglicherweise nicht verursacht. Sie müssen dennoch Updates ausliefern. Benutzer haben möglicherweise alles richtig gemacht. Sie sind dennoch auf Widerruf, Sperrlisten und Plattform-Updates angewiesen. Die Partei, die von einem Markt mit reibungsarmer Ausstellung profitiert, ist nicht immer die Partei, die die Notfallkosten trägt, wenn die Ausstellung scheitert.

Moderne CT-Überwachung hilft Domain-Inhabern, nicht autorisierte Zertifikate schneller zu sehen, aber Sichtbarkeit ist nur ein Teil der Ökonomie. Jemand muss immer noch Protokolle überwachen, Warnungen sichten, die CA kontaktieren, Widerruf anfordern, Kunden bei Bedarf benachrichtigen und bewerten, ob der Verkehr abgefangen worden sein könnte. Für eine große Plattform ist diese Arbeit machbar. Für eine kleine Organisation ist sie eine weitere versteckte Sicherheitssteuer. Ein CA-Vorfall mit einer kleinen Domain kann für diese Organisation genauso existenziell sein, wie ein Vorfall mit einer großen Domain für das Ökosystem peinlich ist.

Der Comodo-Fall handelt daher nicht nur von berühmten Internetmarken. Berühmte Marken machten das Ereignis sichtbar. Dasselbe delegierte Ausstellungsmodell hätte einer Dissidenten-Nachrichtenseite, einer kleinen Bank, einem lokalen Regierungsdienst, einem Gesundheitsportal oder einer Anbieter-Loginseite mit viel weniger öffentlicher Prüfung schaden können. Vertrauenssysteme müssen daran gemessen werden, wie sie die am wenigsten sichtbaren vertrauenden Parteien schützen, und nicht nur daran, wie schnell sie koordinieren, wenn das Ziel global berühmt ist.

Gute Vorfallreaktion ließ dennoch unbeantwortete Fragen

Comodos öffentliche Reaktion enthielt nützliche Fakten: das Datum, den RA-Konto-Einbruch, die neun Zertifikate, Domain-Namen und Seriennummern, den sofortigen Widerruf, die Formulierung zur OCSP-Überwachung, das Dementi eines Kompromisses der CA-Infrastruktur und der HSMs sowie den späteren blockierten Versuch. Browser- und Plattform-Anbieter fügten öffentliche Empfehlungen hinzu. Für 2011 ist das eine bessere Aufzeichnung als bei vielen Vorfällen.

Dennoch lässt die öffentliche Aufzeichnung unbeantwortete Fragen, die für die Verantwortung wichtig sind. Welches genaue Kontrollversagen erlaubte die Nutzung des RA-Kontos? Welche Authentifizierung und Autorisierung waren vor und nach dem 15. März erforderlich? Gab es Hochrisiko-Domain-Prüfungen, und wenn nicht, warum nicht? Welche Überwachung bemerkte die betrügerische Ausstellung? Wie lange existierten die Zertifikate vor dem Widerruf? Welche Parteien wurden in welcher Reihenfolge benachrichtigt? Welche unabhängigen Prüfungsnachweise überprüften die Kontrollen? Was geschah mit der delegierten Partnerbeziehung?

Einige dieser Antworten mögen privat mit Browser-Root-Programmen oder Prüfern geteilt worden sein. Private Nachweise können angemessen sein, wenn sie sensible Details enthalten. Aber öffentliches Vertrauen wird nicht vollständig im Privaten aufgebaut. Benutzer und vertrauende Parteien können die Zuverlässigkeit einer CA nicht beurteilen, wenn jedes bedeutsame Behebungsdetail vertraulich ist. Die Kunst besteht darin, genügend Nachweise zu veröffentlichen, um Kontrollverbesserungen zu zeigen, ohne Angreifern eine Bedienungsanleitung zu liefern.

Der blockierte Versuch vom 26. März macht dies besonders wichtig. Comodo erklärte, neue Kontrollen hätten die betrügerische Ausstellung während des späteren Versuchs verhindert. Das ist eine starke und nützliche Behauptung. Die Öffentlichkeit erhielt jedoch nur eine kompakte Beschreibung dieser Kontrollen.

Eine robustere öffentliche Vorfall-Nachlese hätte die Kategorien der Kontrollen ohne sensible Einzelheiten erläutert: stärkere Wiederverkäufer-Authentifizierung, Erkennung von Ausstellungsanomalien, Genehmigung für Hochrisiko-Domains, Rotation von Partner-Zugangsdaten, Prüfungsüberprüfung, zusätzliche Überwachung und Root-Programm-Berichterstattung.

Die Lektion ist nicht, dass Comodos öffentliche Reaktion einzigartig mangelhaft war. Sie ist, dass CA-Vorfälle einen anderen Postmortem-Stil erfordern als gewöhnliche Software-Schwachstellen. Eine vom Browser vertraute CA ist Teil einer gemeinsamen Identitätsinfrastruktur. Wenn sie fehlerhaft ausstellt, müssen ihre Wiederherstellungsnachweise nicht nur ihre eigenen Kunden zufriedenstellen, sondern auch Domain-Inhaber, die nie mit ihr Verträge geschlossen haben, Browser-Benutzer, die nie von ihr gehört haben, und Root-Programme, die die nachgelagerten Vertrauensfolgen tragen.

Was der Vorfall in der Vertrauensdiskussion verändert hat

Das Comodo-Ereignis steht in einer breiteren Periode, in der die Web-PKI zunehmend weniger bereit war, CA-Vertrauen als unsichtbare Hintergrundinstallation zu behandeln. 2011 brachte auch den DigiNotar-Kompromiss, ein viel schwereres CA-Versagen, das zu breitem Misstrauen führte. Zusammen trieben solche Ereignisse das Ökosystem zu stärkerem öffentlichem Vorfallmanagement, CT, besserer Root-Programm-Durchsetzung und detaillierteren Baseline Requirements.

Es wäre zu einfach zu sagen, Comodo allein habe diese Reformen verursacht. Es wäre auch zu einfach, Comodo außen vor zu lassen. Das Ereignis bot ein klares Beispiel für betrügerische Ausstellung durch delegierte Autorität, die auf hochwertige Domains abzielte und Notfallmaßnahmen von Browser und Betriebssystem erforderte. Genau das ist die Art von Vorfall, die verborgene Vertrauensbeziehungen sichtbar macht.

Die heutige Standards- und Richtlinienlandschaft spiegelt diesen Wandel wider. Die Baseline Requirements des CA/Browser Forums geben der Domain-Validierung und dem Widerruf eine formellere öffentliche Grundlage. Mozilla, Chromium, Apple und Microsoft veröffentlichen Erwartungen an Root-Programme. CT-Protokollierung gibt Domain-Inhabern und Browsern eine öffentliche Datenquelle für ausgestellte Zertifikate. Die CCADB bietet Root-Programm-Koordination und öffentliche CA-Informationen. Keiner dieser Mechanismen ist perfekt, aber zusammen machen sie es einer CA schwerer, einen Vorfall nur als privates Kundendienstproblem zu behandeln. (CA/Browser Forum Baseline Requirements,CCADB,Chrome Certificate Transparency-Richtlinie)

Die verbleibende Schwäche ist die Verantwortung durch Erschöpfung. Das Ökosystem kann eine Flut von Richtlinien, Prüfungen, Bug-Threads, Mailinglisten-Beiträgen, Vorfallberichten und Root-Programm-Issues produzieren. Nur eine kleine Gemeinschaft liest sie genau. Das schafft ein Transparenzparadoxon: Informationen mögen öffentlich sein, aber die praktische Verantwortung hängt immer noch von Experten ab, die Zeit haben, sie zu beobachten. Eine CA kann Offenlegungsformulare erfüllen, während die breitere Öffentlichkeit nicht verstehen kann, was schiefgegangen ist.

Daniel Kades Risikorahmen durchschneidet diesen Papierkram, indem er fragt, wer die Variablen der Konsequenz kontrollierte. Im Comodo-Fall ist die Antwort nicht mystisch. Comodo kontrollierte die delegierte Ausstellung, die Wiederverkäufer-Authentifizierung, den Widerruf und die öffentliche Reaktion. Browser- und Plattform-Anbieter kontrollierten das lokale Misstrauen und die Updates. Root-Programme kontrollierten die fortlaufende Aufnahme. Domain-Inhaber kontrollierten die Überwachung und die Kundenkommunikation. Angreifer kontrollierten die böswillige Handlung. Benutzer kontrollierten fast nichts.

Diese letzte Tatsache ist der Grund, warum die CA-Rechenschaftspflicht strikt sein muss. Benutzern wird gesagt, sie sollen auf HTTPS achten, Warnungen vermeiden und ihrem Browser vertrauen. Wenn das CA-System stromaufwärts versagt, können Benutzer das Wiederverkäufer-Konto, den RA-Einbruch, den OCSP-Responder, die CRL, die Sperrliste oder die Root-Programm-Diskussion nicht überprüfen. Sie verlassen sich auf institutionelle Kontrollen. Institutionelle Kontrollen verdienen institutionelle Verantwortung.

Ein besserer Verantwortungstest für delegierte Ausstellung

Ein ernsthafter Verantwortungstest für den nächsten Vorfall bei delegierter Ausstellung sollte vor der Anzahl der Zertifikate beginnen. Erstens sollte die CA nachweisen können, welche delegierten Konten welche Zertifikate unter welcher Authentifizierung, mit welchen Hochrisiko-Namensbeschränkungen und welcher unabhängigen Genehmigung anfordern können. Zweitens sollte die CA nachweisen können, dass sie Anomalien bei Anfragen erkennt, die große Plattformen, sensible Login-Namen, öffentliche Domains, Finanzdienste, Softwareverteilung, Gesundheitssysteme und andere hochwertige Ziele betreffen.

Drittens sollte die CA die Widerrufsgeschwindigkeit und -zuverlässigkeit nachweisen können. Das bedeutet, nicht nur zu sagen, dass ein Zertifikat widerrufen wurde, sondern zu erklären, wie vertrauende Parteien geschützt wurden, als Widerrufsprüfungen fehlschlugen oder blockiert wurden. Browser- und Plattform-Anbieter benötigen möglicherweise dennoch lokale Misstrauens-Updates, aber die CA sollte einen Notfall-Kontaktweg und ein Nachweispaket für diese Anbieter bereithalten.

Viertens sollte die CA in der Lage sein, einen eingegrenzten Vorfallbericht zu veröffentlichen, der besagt, was geschehen ist, was nicht geschehen ist, was unbekannt bleibt und welche Kontrollen geändert wurden.

Fünftens sollten Root-Programme erklären können, warum fortgesetztes Vertrauen nach einem Vorfall angemessen ist. Diese Erklärung muss keine privaten Prüfungsunterlagen preisgeben, sollte aber die Kategorien der geprüften Nachweise nennen: Eindämmung, Partnerkontrolle, Validierungsänderungen, Prüfungsnachbereitung, Überwachung, Leistung des Widerrufsdienstes und Transparenz des Vorfalls. Sechstens sollten Domain-Inhaber praktische Möglichkeiten haben, nicht autorisierte Ausstellung zu überwachen und CAs schnell zu erreichen, wenn Warnungen erscheinen.

Der Comodo-Vorfall zeigt, warum jedes Stück wichtig ist. Der Angreifer benötigte nicht Comodos Root-Schlüssel. Ein delegiertes Konto reichte aus. Der Widerruf beseitigte nicht die Notwendigkeit von Browser- und Betriebssystemmaßnahmen. Öffentliche Empfehlungen beseitigten nicht jede Frage zu Partnerkontrollen. Die geringe Anzahl der Zertifikate machte den Vorfall nicht klein, denn die Ziele waren identitätskritische Domains und das betroffene Vertrauen war global.

Für Sectigo ist die geerbte Lektion geradlinig. Eine moderne Zertifizierungsstelle verdient Vertrauen nicht nur durch massenhafte Ausstellung, sondern durch den Nachweis, dass kein Partner, Wiederverkäufer, Automatisierungspfad oder Support-Konto diese Masse stillschweigend gegen die Öffentlichkeit wenden kann. Historische Vorfälle sind keine dauerhafte Schuld. Sie sind dauerhafte Beweise für Versagensmodi, gegen die konstruiert, geprüft, überwacht und erklärt werden muss.

Die vertretbarste Lesart der Aufzeichnung von 2011 ist weder Panik noch Verharmlosung. Comodo erkannte und widerrief die betrügerischen Zertifikate und erklärte, seine Root-Infrastruktur sei nicht kompromittiert worden. Mozilla und Microsoft mussten dennoch Schutz-Updates ausliefern. Der Angreifer zeigte, dass delegierte Ausstellung vom Browser vertraute Identitäten für große Domains schaffen kann. Das Ökosystem lernte, dass Widerruf, Root-Vertrauen und Wiederverkäufer-Kontrolle keine getrennten Themen waren. Sie waren eine einzige Verantwortungsoberfläche.

Deshalb gehört dieser Vorfall auch fünfzehn Jahre später noch in eine Serie über Risiko und Verantwortung. Das sichtbare Artefakt war ein Zertifikat. Der eigentliche Vermögenswert war das öffentliche Vertrauen, dass ein Browser eine Domain von einer anderen unterscheiden kann. Sobald dieses Vertrauen durch ein kompromittiertes delegiertes Konto entliehen werden kann, lautet die Frage nicht mehr, ob der Root-Schlüssel in einem HSM sicher war. Die Frage ist, ob alle, die praktische Kontrolle über delegiertes Vertrauen hatten, es mit der Disziplin nutzten, die globale Abhängigkeit erfordert.