Zusammenfassung

  • Bestätigter öffentlicher Bericht:Comodos Vorfallbericht gab an, dass am 15. März 2011 ein Konto einer Registrierungsstelle kompromittiert und zur Ausstellung von neun betrügerischen Zertifikaten für sieben Domains verwendet wurde; es hieß auch, alle seien sofort nach Entdeckung widerrufen worden und die Überwachung des OCSP-Responder-Verkehrs habe keine Nutzungsversuche nach dem Widerruf festgestellt. (Comodo-Vorfallbericht)
  • Reaktion von Browsern und Plattformen:Mozilla, Microsoft und andere Browser- oder Plattformbetreiber behandelten das Ereignis als mehr als ein internes Problem des Herausgebers. Mozilla veröffentlichte ein Update der Zertifikatssperrliste, Microsoft veröffentlichte Security Advisory 2524375 und ein Update, das die neun Zertifikate in den Windows-Speicher für nicht vertrauenswürdige Zertifikate aufnahm, und Mozillas Follow-up beschrieb den Pfad der kompromittierten Registrierungsstelle. (Mozilla Advisory,Microsoft Advisory,Mozilla Follow-up)
  • Verantwortungsgrenze:Die öffentlichen Beweise stützen ein Versagen der delegierten Ausstellung, nicht eine öffentliche Feststellung, dass Comodos Root-Keys oder Hardware-Sicherheitsmodule kompromittiert wurden. Comodo sagte, seine CA-Infrastruktur und HSM-Keys seien nicht kompromittiert worden. Diese Unterscheidung schränkt die technische Behauptung ein, schränkt jedoch das Verantwortungsproblem nicht ein: Das delegierte Konto produzierte dennoch browser-vertrauenswürdige Zertifikate für hochwertige Domains.
  • Bewertung:Der Angreifer war für den Eindringling und den versuchten Missbrauch verantwortlich. Comodo kontrollierte das delegierte Ausstellungsmodell, die Reseller-Authentifizierung und die Maßnahmen nach dem Vorfall; Browser- und Betriebssystemanbieter kontrollierten das Notfall-Misstrauen; Root-Programme kontrollierten das fortlaufende Vertrauen; Dienste und Nutzer, die auf das Vertrauen angewiesen sind, trugen Konsequenzen, die sie nicht direkt beobachten konnten.

Eine Zertifizierungsstelle kann weit entfernt vom Root-Key versagen

Zertifizierungsstellen-Vorfälle werden oft als ein einziger filmreifer Kompromiss vorgestellt: Ein Angreifer stiehlt einen privaten Root-Key, fälscht das Web und das gesamte Vertrauenssystem brennt. Der Comodo-Vorfall war alltäglicher und lehrreicher. Comodo sagte, seine CA-Infrastruktur sei nicht kompromittiert worden und die Schlüssel in seinen Hardware-Sicherheitsmodulen seien nicht kompromittiert worden. Die betrügerischen Zertifikate wurden über ein Registrierungsstellen-Konto ausgestellt, eine delegierte Eingangstür zur Zertifikatsbestellplattform. (Comodo-Vorfallbericht)

Dieser Unterschied ist wichtig. Ein Root-Key-Kompromiss würde fragen, ob der grundlegende kryptografische Anker noch verwendbar war. Ein Kompromiss der delegierten Ausstellung stellt eine schwierigere operative Frage: Wie viel praktische CA-Macht wird in Partnerkonten, Reseller-Workflows, Validierungsmitarbeiter, automatisierte Systeme und Notfall-Widerrufskanäle gelegt? 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 dort, wo das öffentliche Internet lebt. Benutzer entscheiden nicht, welche Registrierungsstelle eine Zertifikatsanfrage validiert hat. Sie sehen ein Schlosssymbol, einen Domainnamen und die Akzeptanz der Kette durch den Browser. Browser-Anbieter und Root-Programme vertrauen nicht nur einem einzigen Unternehmenssitz; sie vertrauen dem operativen System, das den privaten Schlüssel umgibt.

Dieses System umfasst Validierungsverfahren, Kontosicherheit, Reseller-Überwachung, Prüfungsnachweise, Widerrufsdienstkapazität, Vorfallberichterstattung und die Bereitschaft, Vertrauen zu entziehen oder einzuschränken, wenn Fehler wiederholt auftreten.

Der Comodo-Fall ist daher ein nützlicher Rechenschaftsfall, weil die Anzahl der betrügerischen Zertifikate gering war. Neun Zertifikate reichen aus, um die Fehlerart zu zeigen, ohne die Lektion in Tausenden von Randfällen zu vergraben. Der Vorfall musste keine bekannte Massenabfangkampagne verursachen, um ein Governance-Problem aufzuzeigen. Er zeigte, dass ein delegiertes Konto den Browser-Root-Status einer Zertifizierungsstelle in Zertifikate für einige der sensibelsten Identitätsziele im Internet verwandeln konnte.

Die Namen selbst tragen das Problem. Ein Zertifikat für einen Login-Endpunkt ist kein dekoratives Artefakt. Es ist eine Berechtigung zur Präsentation einer kryptografischen Identität gegenüber Browsern. Wenn ein Angreifer ein solches Zertifikat mit Verkehrsumleitung, DNS-Manipulation, lokaler Netzwerkkontrolle, Routing-Interferenz, Malware oder staatlichem Netzwerkzugang kombinieren kann, hat der Benutzer möglicherweise keine normale Möglichkeit zu sehen, 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 oder Man-in-the-Middle-Angriffe gegen Browser-Benutzer durchzuführen. (Microsoft Advisory 2524375)

Der korrekte Befund ist begrenzt. Die öffentliche Aufzeichnung zeigt nicht, dass alle neun Zertifikate bei erfolgreichen groß angelegten Abfangaktionen verwendet wurden. Comodo sagte, nur eines sei live im Internet gesehen worden und die Überwachung des OCSP-Responder-Verkehrs habe keine Nutzungsversuche nach dem Widerruf festgestellt. Microsoft und Mozilla behandelten das Ereignis dennoch als dringend, weil 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 Massenausnutzung belegen.

Die öffentliche Chronologie ist ungewöhnlich konkret

Comodos Vorfallbericht gibt die erste harte Grundlage. Er besagt, dass am 15. März 2011 eine Registrierungsstelle einen Angriff erlitt, 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 sagte, alle Zertifikate seien sofort nach Entdeckung widerrufen worden. Derselbe Bericht listete die Domains und Seriennummern auf und trennte Zertifikate, die live gesehen wurden, von denen, die nicht live gesehen wurden. (Comodo-Vorfallbericht)

Mozillas Follow-up verband dieses Kontoversagen mit dem Browser-Vertrauen. Mozilla sagte, ein Comodo-RA-Partner habe einen internen Sicherheitsverstoß erlitten, und der Angreifer habe das RA-Konto bei Comodo verwendet, um neun betrügerische Zertifikate ausstellen zu lassen. Mozilla stellte auch fest, dass die Zertifikate widerrufen wurden, dass Firefox Updates ausgeliefert hatte, um sie auf die Sperrliste zu setzen, und dass Mozilla weitere Maßnahmen mit Comodo und anderen CAs besprach. (Mozilla Follow-up)

Mozilla Foundation Security Advisory 2011-11 ist knapp, aber wichtig. Es kündigte ein Update der HTTPS-Zertifikatssperrliste am 22. März 2011 mit hoher Auswirkung 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 für die browserseitige Reaktion. (MFSA 2011-11, Mozilla Bugzilla 642395)

Microsofts Security Advisory 2524375 fügte eine Plattformebene hinzu. Microsoft sagte, Comodo habe es am 16. März 2011 informiert, dass neun Zertifikate im Namen eines Dritten ohne ausreichende Identitätsüberprüfung signiert worden seien. Microsoft listete die betroffenen Eigenschaften auf, beschrieb das Risiko von Spoofing, Phishing und Man-in-the-Middle-Angriffen und sagte, Comodo habe die Zertifikate widerrufen und in seine Zertifikatssperrliste aufgenommen.

Microsoft veröffentlichte dennoch Updates, um die neun Zertifikate in den lokalen Speicher für nicht vertrauenswürdige Zertifikate aufzunehmen, weil Widerrufsprüfungen nicht robust genug waren, um Schutz unter allen Netzwerkbedingungen zu gewährleisten. (Microsoft Advisory 2524375)

Dieser letzte Punkt ist das Scharnier. Wenn der Widerruf allein zuverlässig genug wäre, wäre ein Betriebssystem-Update weniger dringend. Microsofts Advisory erklärte das Problem klar: Wenn CRL- oder OCSP-Endpunkte nicht erreicht werden können, können Browser und Anwendungen auf eine Weise fortfahren, die Benutzer gefährdet. Die Zertifikate waren vom Herausgeber widerrufen worden, aber die Software der vertrauenden Partei benötigte dennoch lokale Misstrauenslogik, um Unsicherheit zu beseitigen. Das ist der Moment, in dem ein CA-Vorfall zu einem Browser-, Betriebssystem- und Ökosystem-Vorfall wird.

Das spätere Detail vom 26. März in Comodos Bericht ist ebenfalls aufschlussreich. Comodo sagte, es habe am 26. März einen Eindringling in ein Reseller-Benutzerkonto erkannt und vereitelt, und dass neue Kontrollen, die nach dem Vorfall vom 15. März implementiert wurden, jedes Risiko einer betrügerischen Zertifikatsausstellung beseitigt hätten. Es sagte auch, es glaube, dass der Angriff vom selben Täter stammte. Dieses Update ist nicht nur eine Randnotiz. Es deutet auf einen Wiederholungsversuch gegen die delegierte Ausstellung nach dem ersten Kompromiss hin und stellt die Kontrollen nach dem Vorfall unter die Lupe. (Comodo-Vorfallbericht)

Für eine öffentliche Rechenschaftsaufzeichnung ist die Chronologie stark, aber unvollständig. Sie teilt der Öffentlichkeit das Datum, den Pfad des delegierten Kontos, die Anzahl der Zertifikate, die Domains, die Widerrufsbehauptung, die Reaktion von Browser und Betriebssystem und die Existenz eines später blockierten Versuchs mit. Sie veröffentlicht keinen vollständigen unabhängigen forensischen Bericht, die genaue anfängliche Zugriffsmethode, die vollständige Kontrollumgebung des Resellers, die Prüfungskonsequenzen, die private Kommunikation mit Root-Programmen oder die genauen Entscheidungsschwellen der Browser-Anbieter.

Delegierung ist keine Hintertür in der Verantwortung

Die verführerischste Verteidigung bei delegierter Ausstellung ist auch die schwächste Rechenschaftsverteidigung: Die Root-CA wurde nicht kompromittiert, also lag das Versagen woanders. Technisch gesehen mag das stimmen. Governance-technisch reicht es 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-vertrauenswürdigen Ausstellung erhalten.

Das bedeutet nicht, dass jedes delegierte Modell rücksichtslos ist. Die groß angelegte Zertifikatsausstellung war schon immer auf Verteilung angewiesen. Unternehmen, Hosting-Anbieter, Reseller und Managed-Service-Kanäle können Organisationen helfen, Zertifikate schnell zu erhalten. Automatisierung und Delegierung können Kosten senken und die Akzeptanz verbessern. Die Rechenschaftsfrage ist, ob das Delegierungsmodell Kontrollen trägt, die dem angemessen sind, was das delegierte Konto tun kann.

Die Comodo-Zertifikate waren nicht für obskure Domains mit geringem Missbrauchswert. Sie waren für 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 eine kleine Unternehmensdomain.

Diese Erkenntnis kann als stärkere Domain-Validierung, Out-of-Band-Genehmigung, Überwachung von Hochrisiko-Namen, Anomalieerkennung, Ratenbegrenzungen, Partnerkontobeschränkungen, Kundenpreautorisierung oder sofortige Eskalation auftreten, wenn ein Reseller-Konto eine Ausstellung für global sensible Namen versucht.

Moderne Baseline-Regeln und Root-Store-Richtlinien sprechen diese Themen expliziter an als das Ökosystem von 2011. Die CA/Browser Forum Baseline Requirements enthalten heute öffentliche Anforderungen für die Ausstellung von Serverzertifikaten, Validierung, Widerruf und CA-Betrieb. Mozillas Root-Store-Richtlinie und Durchsetzungsmaterial definieren Bedingungen für die Aufnahme und Disziplinierung von Zertifizierungsstellen, die von Mozilla-Produkten vertrauenswürdig sind. (CA/Browser Forum Baseline Requirements, Mozilla Root Store Policy, Mozilla CA Enforcement Policy)

Diese aktuellen Dokumente sollten nicht rückwärts gelesen werden, um zu beweisen, dass eine bestimmte Kontrolle von 2011 eine heutige Regel verletzt hat. Sie sind relevant, weil sie zeigen, wie das Ökosystem gelernt hat, Vertrauen in veröffentlichte Betriebsanforderungen zu übersetzen. Delegierung ist nur erlaubt, wenn die CA für das Ergebnis rechenschaftspflichtig bleibt. Eine CA kann die soziale Bedeutung eines browser-vertrauenswürdigen 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 kommt die Missbrauchskontakt-Ökonomie ins Spiel. Die betrügerische Zertifikatsausstellung verursacht Kosten bei Parteien, die nicht an der Delegierungsentscheidung beteiligt waren: Browser-Anbieter müssen Notfall-Updates ausliefern; Betriebssystemanbieter müssen Misstrauensspeicher unterhalten; Seitenbetreiber müssen auf Identitätsdiebstahl achten; Sicherheitsteams müssen untersuchen, ob Benutzer abgefangen wurden; Endbenutzer müssen auf unsichtbare Behebung vertrauen. Der Herausgeber und sein delegierter Partner mögen Untersuchungs- und Reputationskosten tragen, aber die Notfallarbeit ist über das Ökosystem verteilt.

Der Vorfall fragt daher, wer für die Geschwindigkeit bezahlt. Schnelle, reibungslose Ausstellung nützt Zertifikatsverkäufern und Kunden, wenn alles funktioniert. Wenn ein delegiertes Konto versagt, wird dieselbe Geschwindigkeit zu einem Angreifer-Asset, und andere Parteien bezahlen, um das Ergebnis zu verlangsamen oder rückgängig zu machen. Ein ausgereiftes Rechenschaftsmodell erfordert, dass die CA mehr dieses Risikos internalisiert durch stärkere Partnerkontrollen, Tore für risikoreiche Ausstellung, obligatorische Berichterstattung und Beweise, die Root-Programmen zur Verfügung stehen.

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

Comodo sagte, alle neun Zertifikate seien sofort nach Entdeckung widerrufen worden. Das ist eine bedeutende Tatsache. Widerruf ist die erste Notbremse, wenn ein Zertifikat fehlausgestellt wurde. Aber der Vorfall zeigte, dass Widerruf nicht gleichbedeutend mit zuverlässigem Benutzerschutz ist. Ein Zertifikat kann bei der CA widerrufen, in eine CRL aufgenommen und von OCSP als schlecht markiert werden, während dennoch clientseitige Updates erforderlich sind, weil die Widerrufsprüfung in der realen Welt uneinheitlich ist.

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

Die zugrundeliegenden Standards helfen, die Struktur zu erklären. RFC 5280 definiert das Internet-X.509-PKI-Zertifikats- 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 Fehlverhalten 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 Werkzeug, aber sie ist entscheidend. Sie macht die Abhängigkeit von einem Netzwerkaufruf überflüssig, den ein Angreifer blockieren, abfangen oder zum Scheitern bringen könnte. Der Preis ist, dass Anbieter Updates ausliefern und Benutzer sie schnell genug erhalten müssen, um etwas zu bewirken. (MFSA 2011-11)

Der Comodo-Vorfall demonstrierte daher ein mehrschichtiges Notfallmodell. Die CA widerruft. Browser-Anbieter misstrauen lokal. Betriebssystemanbieter misstrauen lokal. Seitenbetreiber überwachen. Root-Programme hinterfragen die Kontrollen der CA. Benutzer warten auf unsichtbare Maschinerie. Die Existenz mehrerer Schichten ist eine Stärke, aber auch ein Beweis dafür, dass keine einzelne Schicht ausreichte.

Dieser Punkt sollte Lob und Kritik mildern. Es ist fair, Comodo zu loben, dass es die Zertifikate schnell genug erkannt, offengelegt und widerrufen hat, so dass die öffentliche Aufzeichnung keine breite Nutzung nach dem Widerruf zeigte. Es ist auch fair zu sagen, dass der sofortige Widerruf nicht ausreichte. Der Vorfall erforderte, dass Mozilla und Microsoft Produkte aktualisierten, weil der Schutz der vertrauenden Partei nicht vollständig dem Live-Widerruf überlassen werden konnte. Das ist kein Widerspruch. Es ist die normale Form der Reaktion auf Zertifikatsvorfälle, wenn das falsche Zertifikat bereits entkommen ist.

Die spätere Entwicklung der Zertifikatstransparenz gibt der Lektion einen weiteren Rahmen. RFC 6962 beschrieb ein experimentelles öffentliches Protokollierungsdesign 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 einfacher zu erkennen und zu prüfen sind. (RFC 6962, RFC 9162, Chrome Certificate Transparency Policy)

Certificate Transparency machte den Comodo-Vorfall von 2011 nicht rückwirkend unmöglich. Es veränderte die Rechenschaftsumgebung für spätere Vorfälle, indem es versteckte Ausstellung schwieriger zu verbergen und für Domaininhaber, Überwacher und Browser einfacher 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 Domaininhaber und das Browser-Ökosystem nicht auf private Entdeckung allein 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 vertrauenswürdige Intermediate, die mit Roots verbunden sind, in Software aufnehmen, 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 legen öffentliche Erwartungen an CAs fest, die Vertrauen in Mozilla-Produkten suchen. Chromium und Apple veröffentlichen eigene Root-Programm-Anforderungen und -Richtlinien. Microsoft unterhält ebenfalls ein vertrauenswürdiges Root-Programm. Diese Programme sind nicht identisch, aber sie teilen die zentrale Prämisse, dass Browser- und Plattformvertrauen konditional ist. (Mozilla Root Store Policy, Chromium Root Program Policy, Apple Root Certificate Program, Microsoft Trusted Root Program)

Konditionales Vertrauen ist einfacher zu beschreiben als durchzusetzen. Das Entfernen oder Einschränken einer großen CA kann Websites, Unternehmen, Regierungsdienste, lokale Portale, eingebettete Systeme und alte Geräte lahmlegen. Das Belassen einer schlecht kontrollierten CA in Vertrauensspeichern kann Benutzer Abhörangriffen aussetzen. Root-Programme tragen daher eine schwierige Rechenschaftslast: Sie müssen CAs stark genug disziplinieren, um Benutzer zu schützen, aber vorhersagbar genug, dass das Web nicht unter unnötigen Verfügbarkeitsausfällen leidet.

Im Jahr 2011 zeigte Mozillas öffentliche Schreibe die Spannung. Die sofortige Arbeit war, die schlechten Zertifikate auf die Sperrliste zu setzen. Die breitere Arbeit war, zu besprechen, was passiert war, zu fragen, ob zusätzliche Maßnahmen erforderlich waren, und zu entscheiden, ob die Kontrollen und die Reaktion der CA fortlaufendes Vertrauen rechtfertigten. Das ist kein einzeiliges Urteil. Es erfordert Beweise über den kompromittierten Pfad, Eindämmung, Partnerkontrolle, Überwachung, Prüfung und die Wahrscheinlichkeit eines Wiederauftretens.

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 effektiv reagiert, den Fehler eingedämmt, Kontrollen verbessert und genügend Beweise geliefert hat. Aber Toleranz sollte nicht mit Absolution verwechselt werden. Fortlaufendes Vertrauen ist eine zukunftsorientierte Risikoentscheidung, keine Erklärung, dass der Vorfall harmlos war.

Die Öffentlichkeit lernte auch, dass Root-Store-Programme Teil der Reaktionskette waren, nicht passive Konsumenten von CA-Berichten. Mozilla veröffentlichte ein Security Advisory. Microsoft veröffentlichte ein Security Advisory 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-Reseller hatten. Das öffentliche Gesicht des Vertrauenssystems war der Browser und das Betriebssystem, nicht der Zertifikatsanbieter.

Das schafft eine nützliche Rechenschaftsspaltung. Comodo kontrollierte Ausstellung und Widerruf. Browser- und Plattformanbieter kontrollierten das Notfall-Misstrauen und den Benutzerschutz. Root-Programme kontrollierten das zukünftige Vertrauen. Seitenbetreiber 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

Das Thema des Artikels ist Sectigo, weil das gegenwärtige Unternehmen der Nachfolgemarke für Comodos Zertifizierungsstellengeschäft ist. Sectigos öffentliches Material beschreibt das Comodo-CA-Rebranding und sein Zertifikatslebenszyklus- und digitales Vertrauensgeschäft. (Comodo CA ist jetzt Sectigo, Sectigo Über uns)

Das bedeutet nicht, dass das heutige Sectigo für jedes operative Detail von 2011 in gleicher Weise verantwortlich ist wie das Comodo-Management von 2011. Unternehmensgeschichte braucht Präzision. Der Vorfall von 2011 gehört zur Comodo-Zertifizierungsstellenaufzeichnung. Sectigos Rechenschaftspflicht ist das Erbe von Vertrauen, Marktposition, Prüfungserwartungen, Root-Programm-Beziehungen und der Pflicht zu zeigen, dass Lehren aus früheren CA-Vorfällen in die gegenwärtigen Kontrollen eingeflossen sind.

Vertrauensgeschichten sind auf Zertifikatsmärkten wichtig, weil Zertifikate keine gewöhnlichen Produkte sind. Eine CA verkauft eine Behauptung, dass Browser und vertrauende Parteien sie akzeptieren werden. Der Wert dieser Behauptung kommt von angesammeltem Vertrauen: Prüfungen, Root-Aufnahme, Compliance, Betriebszeit, Widerrufsdienste, Markenbekanntheit und wiederholte Beweise, dass Fehlausstellungen ernst genommen werden. Ein Rebranding kann Eigentum und Strategie klären, aber es kann die öffentliche Vorfallsgeschichte des Vertrauensankers nicht auslöschen.

Für Kunden ist die praktische Frage nicht, ob ein RA-Konto von 2011 als direktes technisches Risiko im Jahr 2026 relevant ist. Wahrscheinlich ist es das nicht, im wörtlichen Sinne. Die praktische Frage ist, ob eine moderne CA starke Kontrollen über delegierte Ausstellung, Kontosicherheit, risikoreiche Domains, Vorfalloffenlegung, Zertifikatstransparenzprotokollierung, Widerrufsdienstqualität und Root-Programm-Kommunikation nachweisen kann. Ein historischer Fehler 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 Ausstellungsfußabdruck und vielen delegierten oder automatisierten Kanälen muss nachweisen, dass sie Anomalien schnell erkennen und öffentliche Vorfallberichte liefern kann, wenn etwas schief geht. Die Common CA Database existiert teilweise, um öffentliche Informationen über CAs und Root-Programm-Compliance zu koordinieren. (CCADB) Die öffentliche Rechenschaftspflicht verbessert sich, wenn Vorfallberichte und Sanierungsnachweise sichtbar genug sind, damit Forscher, Kunden und vertrauende Parteien Muster bewerten können und nicht nur isolierte Aussagen.

Die Erbschaftsfrage ist nicht einzigartig für Sectigo. Das CA-Ökosystem hatte mehrere Vorfälle mit Fehlausstellungen, schwacher Validierung, kompromittierten Intermediates, 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 gibt CAs wirtschaftlichen Wert, aber sie erhöht auch den Standard für Beweise, wenn Vertrauen beschädigt wird.

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 Namen "Global Trustee". Diese Ziele sind bedeutsam, weil sie Orte sind, an denen ein Benutzer sich authentifizieren, vertrauenswürdigen Code herunterladen oder sensible Kommunikation empfangen könnte.

Das technische Risiko ist Man-in-the-Middle-Abfangen. Das wirtschaftliche und politische Risiko ist, dass jemand anderes das CA-System ausnutzen kann, um sich Legitimität vom Opferdienst zu leihen. Der Domaininhaber des Opfers mag seine eigenen Server gesichert, HTTPS durchgesetzt, private Schlüssel sorgfältig verwaltet und Benutzer geschult haben, dem Schlosssymbol zu vertrauen. Ein betrügerisches Zertifikat, das von einer vertrauenswürdigen CA ausgestellt wurde, kann einen Großteil dieser Arbeit umgehen, wenn der Verkehr auf der Netzwerkebene umgeleitet oder abgefangen wird.

Deshalb erscheint die DNS-Delegierungsmacht im Manifest. DNS und Zertifikate sind getrennte Systeme, aber sie konvergieren im Gefühl des Benutzers "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 dieser Systeme untergraben wird, ist der Benutzer gefährdet. Wenn beide von einem Angreifer oder einer koerziven Netzwerkumgebung beeinflusst werden können, wird das Risiko viel schlimmer.

Die Missbrauchskontakt-Ökonomie ist hässlich. Ein Domaininhaber mag nichts von der kompromittierten CA oder dem Reseller gekauft haben. Er muss dennoch auf ein betrügerisches Zertifikat für seinen Namen reagieren. Browser-Anbieter mögen die Ausstellung nicht verursacht haben. Sie müssen dennoch Updates ausliefern. Benutzer mögen alles richtig gemacht haben. Sie sind dennoch auf Widerruf, Sperrlisten und Plattform-Updates angewiesen. Die Partei, die von einem Markt mit geringer Reibung profitiert, ist nicht immer die Partei, die die Notfallkosten trägt, wenn die Ausstellung fehlschlägt.

Moderne CT-Überwachung hilft Domaininhabern, unbefugte Zertifikate schneller zu sehen, aber Sichtbarkeit ist nur ein Teil der Ökonomie. Jemand muss immer noch Protokolle überwachen, Warnungen priorisieren, die CA kontaktieren, Widerruf beantragen, Kunden benachrichtigen, falls nötig, und bewerten, ob 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 existentiell sein, wie ein Vorfall mit einer großen Domain für das Ökosystem peinlich ist.

Der Comodo-Fall dreht sich daher nicht nur um bekannte Internet-Marken. Bekannte Marken machten das Ereignis sichtbar. Dasselbe delegierte Ausstellungsmodell hätte eine Dissidenten-Nachrichtenseite, eine kleine Bank, einen lokalen Regierungsdienst, ein Gesundheitsportal oder eine Anbieterseite mit weit weniger öffentlicher Aufmerksamkeit schädigen können. Vertrauenssysteme müssen danach beurteilt werden, wie sie die am wenigsten sichtbaren vertrauenden Parteien schützen, nicht nur, wie schnell sie koordinieren, wenn das Ziel weltweit bekannt ist.

Gute Vorfallreaktion ließ dennoch unbeantwortete Fragen

Comodos öffentliche Reaktion enthielt nützliche Fakten: das Datum, den RA-Konto-Verstoß, die neun Zertifikate, Domainnamen und Seriennummern, sofortigen Widerruf, OCSP-Überwachungssprache, Verneinung von CA-Infrastruktur- und HSM-Kompromiss und den später blockierten Versuch. Browser- und Plattformanbieter fügten öffentliche Beratungen hinzu. Für 2011 ist das eine bessere Aufzeichnung als viele Vorfälle.

Dennoch hinterlässt die öffentliche Aufzeichnung unbeantwortete Fragen, die für die Rechenschaftspflicht 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 Prüfungen für risikoreiche Domains, 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 Beziehung zum delegierten Partner?

Einige dieser Antworten mögen privat mit Browser-Root-Programmen oder Prüfern geteilt worden sein. Private Beweise 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 bewerten, wenn jedes bedeutende Sanierungsdetail vertraulich ist. Die Kunst ist, genügend Beweise zu veröffentlichen, um Kontrollverbesserung zu zeigen, ohne Angreifern ein Betriebshandbuch zu geben.

Der blockierte Versuch vom 26. März macht dies besonders wichtig. Comodo sagte, neue Kontrollen hätten eine betrügerische Ausstellung beim späteren Versuch verhindert. Das ist eine starke und nützliche Behauptung. Die Öffentlichkeit erhielt jedoch nur eine kompakte Beschreibung dieser Kontrollen. Ein robusterer öffentlicher Vorfallsbericht hätte die Kategorien der Kontrollen ohne sensible Details erklärt: stärkere Reseller-Authentifizierung, Ausstellungsanomalieerkennung, Genehmigung für risikoreiche Domains, Partnernachweisdrehung, Prüfungsüberprüfung, zusätzliche Überwachung und Root-Programm-Berichterstattung.

Die Lektion ist nicht, dass Comodos öffentliche Reaktion einzigartig mangelhaft war. Es ist, dass CA-Vorfälle einen Post-Mortem-Stil erfordern, der sich von gewöhnlichen Softwareschwachstellen unterscheidet. Eine browser-vertrauenswürdige CA ist Teil einer gemeinsamen Identitätsinfrastruktur. Wenn sie fehlausstellt, muss ihr Sanierungsnachweis nicht nur ihre eigenen Kunden zufriedenstellen, sondern auch Domaininhaber, die nie mit ihr kontrahiert haben, Browser-Nutzer, die nie von ihr gehört haben, und Root-Programme, die nachgelagerte Vertrauenskonsequenzen tragen.

Was der Vorfall im Vertrauensgespräch veränderte

Das Comodo-Ereignis liegt in einer breiteren Periode, in der die Web-PKI weniger bereit wurde, CA-Vertrauen als unsichtbare Hintergrundinstallation zu behandeln. 2011 brachte auch den DigiNotar-Kompromiss, einen viel schwerwiegenderen CA-Vorfall, der zu weit verbreitetem Misstrauen führte. Zusammen trieben solche Ereignisse das Ökosystem zu stärkerer öffentlicher Vorfallbehandlung, CT, besserer Root-Programm-Durchsetzung und detaillierteren Baseline-Anforderungen.

Es wäre zu einfach zu sagen, Comodo allein habe diese Reformen verursacht. Es wäre auch zu einfach, Comodo wegzulassen. Das Ereignis bot ein klares Beispiel für betrügerische Ausstellung durch delegierte Autorität, gezielt auf hochwertige Domains, die Notfallmaßnahmen von Browsern und Betriebssystemen erforderte. Das ist genau die Art von Vorfall, die versteckte Vertrauensbeziehungen sichtbar macht.

Die heutige Standards- und Politiklandschaft spiegelt diesen Wandel wider. Die CA/Browser Forum Baseline Requirements geben Domain-Validierung und Widerruf eine formalere öffentliche Baseline. Mozilla, Chromium, Apple und Microsoft veröffentlichen Root-Programm-Erwartungen. CT-Protokollierung gibt Domaininhabern 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 Policy)

Die verbleibende Schwäche ist Rechenschaftspflicht durch Erschöpfung. Das Ökosystem kann eine Flut von Richtlinien, Prüfungen, Bug-Threads, Mailinglisten-Beiträgen, Vorfallberichten und Root-Programm-Problemen produzieren. Nur eine kleine Gemeinschaft liest sie genau. Das schafft ein Transparenzparadox: Informationen mögen öffentlich sein, aber praktische Rechenschaftspflicht hängt dennoch von Experten ab, die Zeit haben, sie zu überwachen. Eine CA kann Offenlegungsformulare einhalten, während die breite Öffentlichkeit unfähig bleibt zu verstehen, was schief gelaufen ist.

Daniel Kades Risikorahmen schneidet durch dieses Papierkram, indem er fragt, wer die Konsequenzvariablen kontrollierte. Im Comodo-Fall ist die Antwort nicht mystisch. Comodo kontrollierte delegierte Ausstellung, Reseller-Authentifizierung, Widerruf und öffentliche Reaktion. Browser- und Plattformanbieter kontrollierten lokales Misstrauen und Updates. Root-Programme kontrollierten fortlaufende Aufnahme. Domaininhaber kontrollierten Überwachung und Kundenkommunikation. Angreifer kontrollierten die böswillige Handlung. Benutzer kontrollierten fast nichts.

Diese letzte Tatsache ist der Grund, warum CA-Rechenschaftspflicht streng sein muss. Benutzern wird gesagt, sie sollen auf HTTPS achten, Warnungen vermeiden und ihrem Browser vertrauen. Wenn das CA-System vorgelagert versagt, können Benutzer das Reseller-Konto, den RA-Verstoß, 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 Rechenschaftspflicht.

Ein besserer Rechenschaftstest für delegierte Ausstellung

Ein ernsthafter Rechenschaftstest für den nächsten Vorfall delegierter Ausstellung sollte vor der Zertifikatsanzahl beginnen. Erstens sollte die CA zeigen können, welche delegierten Konten welche Zertifikate anfordern können, unter welcher Authentifizierung, mit welchen Einschränkungen für risikoreiche Namen und mit welcher unabhängigen Genehmigung. Zweitens sollte die CA Anomalieerkennung für Anfragen zeigen können, die große Plattformen, sensible Login-Namen, öffentliche Domains, Finanzdienstleistungen, Softwareverteilung, Gesundheitssysteme und andere hochwertige Ziele betreffen.

Drittens sollte die CA 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 Plattformanbieter benötigen möglicherweise dennoch lokale Misstrauensupdates, aber die CA sollte einen Notfallkontaktpfad und ein Beweispaket für diese Anbieter bereithalten.

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

Fünftens sollten Root-Programme erklären können, warum fortlaufendes Vertrauen nach einem Vorfall angemessen ist. Diese Erklärung muss keine privaten Prüfungsaufzeichnungen offenlegen, aber sie sollte die Kategorien der überprüften Beweise angeben: Eindämmung, Partnerkontrolle, Validierungsänderungen, Prüfungsnachverfolgung, Überwachung, Widerrufsdienstleistung und Vorfalltransparenz. Sechstens sollten Domaininhaber praktische Möglichkeiten haben, unbefugte Ausstellung zu überwachen und CAs schnell zu erreichen, wenn Warnungen auftauchen.

Der Comodo-Vorfall zeigt, warum jedes Stück wichtig ist. Der Angreifer brauchte keinen Comodo-Root-Key. Ein delegiertes Konto war genug. Widerruf beseitigte nicht die Notwendigkeit von Browser- und Betriebssystemmaßnahmen. Öffentliche Beratungen beseitigten nicht jede Frage zu Partnerkontrollen. Die geringe Anzahl von Zertifikaten machte den Vorfall nicht gering, weil die Ziele identitätskritische Domains waren und das betroffene Vertrauen global war.

Für Sectigo ist die geerbte Lektion einfach. Eine moderne Zertifizierungsstelle verdient Vertrauen nicht nur durch die Ausstellung von Zertifikaten in großem Maßstab, sondern indem sie beweist, dass kein Partner, Reseller, Automatisierungspfad oder Support-Konto diesen Maßstab leise gegen die Öffentlichkeit wenden kann. Historische Vorfälle sind keine dauerhafte Schuld. Sie sind permanente Beweise für Fehlermodi, gegen die konstruiert, geprüft, überwacht und erklärt werden muss.

Die am besten verteidigbare Lesart der Aufzeichnung von 2011 ist weder Panik noch Verharmlosung. Comodo erkannte und widerrief die betrügerischen Zertifikate und sagte, seine Root-Infrastruktur sei nicht kompromittiert worden. Mozilla und Microsoft mussten dennoch Schutzupdates ausliefern. Der Angreifer zeigte, dass delegierte Ausstellung browser-vertrauenswürdige Identitäten für große Domains schaffen konnte. Das Ökosystem lernte, dass Widerruf, Root-Vertrauen und Reseller-Kontrolle keine getrennten Themen waren. Sie waren eine Rechenschaftsoberfläche.

Deshalb gehört dieser Vorfall fünfzehn Jahre später noch in eine Risiko- und Rechenschaftsserie. Das sichtbare Artefakt war ein Zertifikat. Der wirkliche Vermögenswert war das Vertrauen der Öffentlichkeit, dass ein Browser eine Domain von einer anderen unterscheiden kann. Sobald dieses Vertrauen durch ein kompromittiertes delegiertes Konto geliehen werden kann, ist die Frage nicht mehr, ob der Root-Key sicher in einem HSM geblieben ist. Die Frage ist, ob jeder, der praktische Kontrolle über delegiertes Vertrauen hatte, es mit der Disziplin eingesetzt hat, die globale Abhängigkeit erfordert.