Update 5 Das Hauptproblem (heh) beim CA-Modell besteht darin, dass in der Regel jede CA Zertifikate für jede Domain ausstellen kann, sodass Sie für das schwächste Glied anfällig sind. Ich bezweifle, dass die Liste überhaupt sehr lang ist, da viel auf dem Spiel steht und die Sicherheit schwierig ist. Ich empfehle Christopher Soghoians Beitrag zu diesem Thema, in dem die verschiedenen Ansätze erläutert werden, mit denen Regierungen auf der ganzen Welt Zugang zu privaten Benutzerdaten erhalten - sei es, indem sie dies direkt von Unternehmen verlangen, die Cloud-Dienste betreiben, über Abhören oder zunehmend jetzt über CA-Zwang oder Hacks: leichte Paranoia: Die Kräfte, die zum DigiNotar-Hack geführt haben.

Hier stelle ich einige Einzelheiten vor und beende mit Links zu möglichen Korrekturen.

Im Jahr 2009 hat Etisalat (60% im Besitz der Regierung der Vereinigten Arabischen Emirate) ein harmloses Aussehen eingeführt BlackBerry-Patch, der Spyware in RIM-Geräte eingefügt hat und die Überwachung von E-Mails ermöglicht, sodass er kaum als vertrauenswürdig angesehen werden kann. Es befindet sich jedoch in vielen vertrauenswürdigen CA-Listen: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Update 1 Siehe auch ein Beispiel für einen erfolgreichen Angriff eines Iraners namens ComodoHacker gegen Comodo: Rogue SSL Zertifikate ("case comodogate") - F-Secure Weblog. F-Secure stellt fest, dass Mozilla Zertifikate enthält, die von Zertifizierungsstellen in China, Israel, Bermuda, Südafrika, Estland, Rumänien, der Slowakei, Spanien, Norwegen, Kolumbien, Frankreich, Taiwan, Großbritannien, den Niederlanden, der Türkei, den USA, Hongkong und Japan ausgestellt wurden , Ungarn, Deutschland und der Schweiz.

Tunesien ist ein weiteres Land, das eine weithin vertrauenswürdige Zertifizierungsstelle unterhält, und es gibt auch eine gute Dokumentation der Maßnahmen seiner Regierung zur Verletzung der Privatsphäre: Die Insider-Geschichte darüber, wie Facebook auf tunesische Hacks reagiert hat - Alexis Madrigal - Technologie - Der Atlantik

Mozilla stellt eine weitere fragwürdige Vorgehensweise fest, auf die Sie achten sollten: Zertifizierungsstellen, mit denen ein RA-Partner Zertifikate direkt vom Stamm aus und nicht über einen Vermittler ausstellen kann: Ausgabe eines Comodo-Zertifikats - Follow-up im Mozilla Security Blog
Siehe auch weitere Einzelheiten, einschließlich Spekulationen über den Verantwortungsanspruch eines einzelnen iranischen Hackers. Webbrowser und Comodo legen einen erfolgreichen Angriff der Zertifizierungsstelle offen, möglicherweise aus dem Iran | Freiheit zu basteln

Update 3 : Ein weiterer erfolgreicher Angriff, der anscheinend auch von ComodoHacker durchgeführt wurde, war gegen die DigiNotar CA. Ihre Website wurde ab 2009 kompromittiert, aber dies wurde erst bemerkt, nachdem DigiNotar 2011 auch von Iranern verwendet wurde, um falsche Zertifikate für die Websites von Google, Yahoo! Mozilla, WordPress und The Tor Project zu signieren. DigiNotar gab über einen Monat lang kein Wissen über das Eindringen in seine Website bekannt. Weitere Informationen finden Sie unter DigiNotar Hack. Hervorgehoben werden die kritischen Fehler unseres SSL-Web-Sicherheitsmodells | Freiheit zu basteln.

Ich würde vermuten, dass der Schwachstellenbereich verschiedener Zertifizierungsstellen sehr unterschiedlich ist, ebenso wie ihre Nützlichkeit. Daher würde ich vorschlagen, Ihre Strategie neu auszurichten. Wenn Sie es auf bestimmte Assets eingrenzen können, die Sie schützen möchten, löschen Sie einfach alle Zertifizierungsstellen mit Ausnahme der für die Verwendung dieser Assets erforderlichen. Andernfalls sollten Sie die Zertifizierungsstellen entfernen, die Ihrer Meinung nach am anfälligsten für diejenigen sind, die sich um Ihre Vermögenswerte kümmern oder die am wenigsten beliebt sind, nur um die Angriffsfläche zu verringern. Akzeptieren Sie jedoch die Tatsache, dass Sie selbst gegen die beliebtesten und vorsichtigsten Zertifizierungsstellen anfällig für ausgefeilte Angriffe bleiben.

Update 2 : Es gibt einen großartigen Beitrag zum Reparieren unserer gefährlichen Zertifizierungsstelleninfrastruktur at Freedom to Tinker: Aufbau einer besseren CA-Infrastruktur

Es geht um folgende Innovationen:

• ImperialViolet - DNSSEC und TLS

• Netzwerknotar - Perspektiven: Verbesserung der Hostauthentifizierung im SSH-Stil durch Netzwerkprüfung mit mehreren Pfaden

• Google Online-Sicherheitsblog: Verbesserung der Sicherheit von SSL-Zertifikaten

Update 4 Eine unserer IT-Abteilungen Sicherheitsblog-Posts im August 2011 behandeln auch den Fall der Umstellung auf DNSSEC: Ein risikobasierter Blick auf die Behebung des Problems der Zertifizierungsstelle «Stack Exchange-Sicherheitsblog

Update 6 Mehrere Zertifizierungsstellen wurden bei Verstößen gegen die Regeln erwischt. Dazu gehören die französische Cyberdefense-Agentur (ANSSI) und Trustwave, die jeweils mit dem Spoofing digitaler Zertifikate verbunden waren.

Update 7 Noch ein Satz von "falsch ausgestellten Zertifikaten" über den indischen Controller of Certifying Authorities (India CCA) im Jahr 2014: Google Online Security Blog: Aufrechterhaltung der Sicherheit digitaler Zertifikate

Siehe auch die Frage zu Zertifikatstransparenz Dies scheint ein hilfreicher Ansatz zu sein, um fehlerhafte Zertifikate und Richtlinienverletzungen früher zu erkennen.

Wie Matt Blaze einmal schrieb, schützen CAs Sie vor allen, denen sie kein Geld abnehmen wollen. Das sollte Ihnen etwas darüber sagen, wo die Anreize der Zertifizierungsstelle liegen und welche potenziellen Risiken in der Vereinbarung enthalten sind.

Ich befürchte, dass die kurze Antwort auf diese Frage lautet, dass es unmöglich ist zu wissen, soweit ich sehen kann. In den meisten gängigen Browsern ist eine große Anzahl von Standardzertifizierungsstellen installiert, und es ist schwierig zu beurteilen, wie wahrscheinlich es ist, dass sie "vertrauenswürdig" sind, wenn Zertifikate an staatliche oder andere Organisationen ausgegeben werden.

Wenn eine Zertifizierungsstelle bekannt wurde Da sie nicht vertrauenswürdig sind, werden sie wahrscheinlich aus den Standardinstallationslisten des Browsers entfernt (gemäß @xce unten ist Diginotar hier ein gutes Beispiel und auch Digicert).

Zusätzlich zu der Organisation, die freiwillig Zertifikate bereitstellt, besteht das Risiko, dass Sie können Zertifikate bereitstellen, ohne den Anforderer entsprechend zu überprüfen. Vor ein paar Jahren gab es bei Defcon mehrere Präsentationen zu diesem Thema, bei denen es darum ging, Zertifikate ohne Genehmigung zu erhalten.

Wenn dies ein wichtiges Anliegen ist, kann ich mir nur vorstellen, dies zu tun Eine weiße Liste von Zertifizierungsstellen, die Sie überprüft haben und mit der bereitgestellten Sicherheit vertraut sind. Dies würde natürlich nicht für den Zugriff auf das allgemeine Internet funktionieren, da Sie wahrscheinlich Zertifizierungsstellen entfernen würden, bei denen Probleme mit Zertifikaten für Websites auftreten, die Sie verwenden möchten.

2 Beispiele, die auf das eingehen, was Sie wissen müssen, aber nicht das, was Sie explizit fragen:

Dann gibt es natürlich die Software-Szenarien, in denen die Zertifizierungsstelle nicht einmal zum Einsatz kommt - z. Bei Thick-Clients, die Web Services aufrufen und sich nicht die Mühe machen, das Zertifikat des Servers zu überprüfen.

Mein Punkt ist, dass wenn Sie sich über MITM über SSL Sorgen machen, dies meistens nicht der Fall ist Regierungszwang, der Sie beunruhigen sollte. Es gibt normalerweise einfachere und zugänglichere Wege.
Ich lehne es sogar ab, dass "Vertrauenswürdige Zertifikate" als "Vertrauenswürdig" bezeichnet werden ... Nur weil ich weiß, wer Sie sind, heißt das nicht, dass ich Ihnen vertrauen sollte ... und es bedeutet nicht, dass ich sollte darauf vertrauen, dass Sie wissen, wer jemand anderes ist.

Ganz zu schweigen davon, dass viele Websites im Internet nicht wie erwartet funktionieren, wenn Sie Standard-Stammzertifikate aus dem vertrauenswürdigen Speicher entfernen.

Wenn Sie dagegen mit einem Server / einer Appliance arbeiten, der keine allgemeinen Browsing-Funktionen benötigt, aber mit einem bestimmten Server (oder einer Reihe von Servern) kommuniziert Entfernen Sie auf jeden Fall ALLE Stammzertifikate, mit Ausnahme einer Whitelist der von Ihnen benötigten.
Und wenn Sie mit Ihrer eigenen internen Zertifizierungsstelle arbeiten, ist dies sogar noch besser ...

Jede Zertifizierungsstelle veröffentlicht eine Erklärung zur Zertifikatspraxis, in der beschrieben wird, wie sie ihre eigenen Schlüssel schützt und Anforderungen für Zertifikate validiert, bevor sie ausgestellt werden. Eine URL zum Speicherort für dieses Dokument ist normalerweise in jedes von der Zertifizierungsstelle ausgestellte Zertifikat eingebettet. Unter der Annahme, dass die betreffende Zertifizierungsstelle tatsächlich diesem Richtliniendokument folgt, sollte sie Ihnen einen Hinweis auf die Länge geben, die sie benötigen, um die Gültigkeit der Entität zu überprüfen, die Zertifikate anfordert. Suchen Sie nach Aussagen, die besagen, dass sie ihre CA-Signaturschlüssel mithilfe von Hardware-Sicherheitsmodulen oder kryptografischen Modulen schützen, um die Signaturschlüssel, die Multi-Faktor-Authentifizierung und die quorumbasierte Autorisierung zum Signieren von Zertifikaten usw. zu schützen. Diese Schutzmethoden machen es viel schwieriger und teurer für einen betrügerischen Dritten, um die Signaturschlüssel zu stehlen.

Die riesige Liste vertrauenswürdiger Zertifizierungsstellen (mein Mac System Roots Keychain hat 175) dient Ihrer Bequemlichkeit, um das HTTPS-System für Sie und alle auf dem Planeten, die diese Fragen nicht stellen, nutzbar zu machen. Sie können natürlich jede Zertifizierungsstelle aus dieser Liste streichen, es sei denn, Sie haben ihre Praktiken persönlich geprüft. Bei einem geschlossenen System, bei dem Sie alle Endpunkte steuern und eine begrenzte Anzahl vertrauenswürdiger Parteien haben, ist dies möglich. Das Versionskontrollsystem von Subversion enthält keine vertrauenswürdigen Stammzertifikate. Sie können jedoch jedem Client eigene Zertifikate hinzufügen. Für das gesamte Web besteht die einzige Möglichkeit, es nutzbar zu machen, darin, dass eine vertrauenswürdige Out-of-Band-Partei (das Unternehmen, das Ihr Betriebssystem oder Ihren Browser bereitstellt, was auch immer Sie davon halten) eine Liste vertrauenswürdiger Unternehmen bereitstellt Zertifikate, mit denen Sie eine Verbindung zu nahezu jedem SSL-fähigen Server der Welt herstellen können.

Benötigen Sie wirklich alle diese Zertifikate in Ihrer vertrauenswürdigen Liste? Wahrscheinlich nicht. Ihr Betriebssystem- / Browser-Anbieter kann jedoch nicht vorhersehen (und sollte auch nicht kontrollieren), mit wem Sie Geschäfte tätigen möchten, sodass alle enthalten sind. Das Problem mit der großen Liste ist, dass Sie CAs aller Gefieder mit allen Arten von Überprüfungsmethoden aus allen Gerichtsbarkeiten haben, die genau gleich behandelt werden. Nicht jede Zertifizierungsstelle verhält sich gleich: Wir haben Fälle von gefährdeten Anmeldeinformationen für Wiederverkäufer und sogar gefährdete Zertifizierungsstellenschlüssel gesehen. Einige Zertifizierungsstellen erfordern eine Gründungsurkunde und das Versprechen Ihres Erstgeborenen, andere überprüfen lediglich, ob Sie E-Mails in der Domain erhalten können, für die Sie ein Zertifikat anfordern. Und dennoch wird jede Zertifizierungsstelle von Ihrem Browser genau gleich behandelt.

Eine Verteidigungslinie gegen unerwünschte Zertifikate für denselben allgemeinen Namen besteht darin, das Originalzertifikat auf dem Client zwischenzuspeichern: Wenn plötzlich ein anderes Zertifikat von einer anderen Zertifizierungsstelle angezeigt wird, sollte dies Anlass zur Sorge geben. Ich weiß nicht, wie die heutigen Browser diesen Fall behandeln, und ich bin zu faul, um es herauszufinden.

Diese Art der Diskussion erinnert mich immer an diesen Mozilla-Fehler, bei dem die Aufnahme einer neuen Zertifizierungsstelle angefordert wurde. Ziemlich witzig, aber ziemlich aufschlussreich.

Ich glaube, die US-Regierung hat vor einigen Jahren versucht, Gesetze zu verabschieden, die ihnen das Recht einräumen, eine Zertifizierungsstelle zu zwingen, ein gültiges Zertifikat eines Dritten für das Abhören und was nicht. Ich konnte keine Beweise dafür finden, daher erinnere ich mich möglicherweise an etwas in Anlehnung an die von Rory erwähnten DefCon-Gespräche.

Angenommen, eine schlechte Regierung wollte den SSL-Verkehr von Maschinen sehen. Wie machbar ist es, dass die Standardzertifizierungsstellen zur Ausstellung eines neuen Zertifikats gezwungen werden?

Das Prädikat und die Frage stehen in keinem Zusammenhang. Es spielt keine Rolle, wie einfach oder oft eine Zertifizierungsstelle zur Ausstellung eines neuen Zertifikats gezwungen werden könnte - der potenzielle Lauscher konnte Ihre Daten nur sehen, wenn er über den privaten Schlüssel des bereits installierten Zertifikats verfügt. IIRC (aber ich würde empfehlen, dies zu überprüfen) Der CSR enthält den privaten Schlüssel nicht - daher kann die Zertifizierungsstelle ihn nicht so erhalten. Sie können nicht ändern, welche Schlüssel Ihre Computer verwenden.

Es ist jedoch möglich, dass eine nicht autorisierte Zertifizierungsstelle ein gefälschtes Zertifikat ausstellt - und dann besteht das Potenzial für einen MITM-Angriff auf Ihre Site. Jüngste Probleme mit dem MD5-Format und Etisalat legen nahe, dass dies nicht unmöglich ist.

Wenn Sie untersuchen, welches Zertifikat auf einem Windows-PC entfernt werden soll, sollten Sie zunächst sicherstellen, dass Sie keine vom System erforderlichen Zertifikate entfernen. Wenn Sie dies versuchen, wird die folgende Fehlermeldung angezeigt:

Dies ist die URL mit einer Liste von Zertifikaten, die niemals aus einem Windows-System gelöscht werden dürfen http://support.microsoft.com/?id=293781

Als Nächstes sollten Sie das Entfernen (Testen des Entfernens von) Zwischenzertifikaten in Betracht ziehen, da diese nur " rein für" existieren Legacy-Gründe ".

Berücksichtigen Sie bei der Bewertung des Entfernens aller verbleibenden Zertifikate, dass die Zertifizierungsstelle für das Microsoft Root-Zertifikatsprogramm einen dieser Prüfstandards erfüllen muss:

Wenn Sie Zertifikate aus einem Nicht-MSFT-Browser (IE) entfernen, sollten Sie diese CA-Qualitätsrichtlinien überprüfen.

Einschränkungen

Das Programm verfügt außerdem über zusätzliche Audits, die sich auf die Schlüsselverwendung beziehen. Die Schlüsselverwendung ist auf Folgendes beschränkt:

• Serverauthentifizierung (SSL) = 1.3.6.1.5.5.7.3.1

• Clientauthentifizierung (SSL) = 1.3.6.1.5.5.7.3.2

• Sichere E-Mail (SMIME) EKU = 1.3.6.1.5.5.7.3.4

• Codesignatur EKU = 1.3.6.1.5.5.7.3.3

• Zeitstempel EKU = 1.3.6.1.5.5.7.3. 8

• OCSP EKU = 1.3.6.1.5.5.7.3.9

• Dateisystem verschlüsseln EKU = 1.3.6.1. 4.1.311.10.3.4

• IPSec (Tunnel, Benutzer) EKU = 1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

Die folgenden Schlüsselverwendungen werden vom Programm gesperrt:

• Smartcard-Anmeldung Dies ist ein Szenario nur für Unternehmen, da eine Active Directory-Bereitstellung erforderlich ist und das Stammverzeichnis dem NTAuth-Speicher in Active Directory hinzugefügt werden muss. Weitere Informationen finden Sie im folgenden KB-Artikel. http://support.microsoft.com/default.aspx?scid=kb;en-us;Q281245

• Digitale Rechte Diese EKU ist veraltet . Windows Media DRM verwendet ein eigenes XML-Format für Lizenzen und kein X.509.

• Qualifizierte Unterordnung Diese EKU ist veraltet und wird von Windows ignoriert.

• Schlüsselwiederherstellung Enterprise CA-Szenario.

• Dateiwiederherstellung Diese EKU ist veraltet und wird vom Windows Encrypting File System (EFS) ignoriert.

• Alle Anwendungsrichtlinien Wir können nicht "alle Verwendungen" gewähren, da dies notwendigerweise nur für Unternehmen und andere nicht akzeptable EKUs zulässt.

• Verzeichnisdienst-E-Mail Replikation Enterprise-Szenario

• Zertifikatanforderungsagent

• Enterprise-CA-Szenario

• Enterprise CA-Szenario des Key Recovery Agent

• CA-Verschlüsselungszertifikat

• Enterprise CA-Szenario

Akzeptanzkriterien

Außerdem müssen die folgenden Kriterien erfüllt sein, bevor der Stammverzeichnis eine allgemeine Zweck- oder Regierungszertifizierungsstelle hinzugefügt wird:

1. Die Zertifizierungsstelle muss die unten angeforderten Informationen bereitstellen (siehe St. ep 1. Wenden Sie sich an Microsoft) und erhalten Sie eine vorläufige Genehmigung für die Mitgliedschaft im Programm.

2. Die Zertifizierungsstelle muss zum Testen ein Testzertifikat bereitstellen, das vom Stammzertifikat der Zertifizierungsstelle ausgestellt wurde Zwecke. Optional kann eine Zertifizierungsstelle Microsoft eine URL eines öffentlich zugänglichen Servers bereitstellen, auf dem von ihrem Stammzertifikat ausgestellte Zertifikate überprüft werden können. (Einzelheiten finden Sie in den häufig gestellten Fragen.)

3. Die Zertifizierungsstelle muss eine Microsoft-Zertifizierungsstellenvereinbarung abschließen. Die Vereinbarung wird erst bereitgestellt, nachdem Sie Schritt 1 des Antragsverfahrens abgeschlossen und die vorläufige Genehmigung Ihres Antrags erhalten haben.

4. Stammzertifikate müssen den folgenden technischen Anforderungen entsprechen. Insbesondere benötigen wir eine Mindestgröße des Kryptoschlüssels mit einem RSA 2048-Bit-Modul für jeden Root und alle ausstellenden Zertifizierungsstellen. Microsoft akzeptiert keine Stammzertifikate mit RSA 1024-Bit-Modul mehr mit Ablauf. Wir bevorzugen, dass neue Roots ab dem Datum der Einreichung mindestens 8 Jahre gültig sind, jedoch vor dem Jahr 2030 ablaufen, insbesondere wenn sie einen 2048-Bit-RSA-Modul haben.

5. Ausgestellte Zertifikate von einem Stammzertifikat muss die CRL-Verteilungspunkterweiterung unterstützen. Der CRL-Verteilungspunkt sollte auf einen öffentlich zugänglichen Speicherort verweisen.

6. Die Zertifizierungsstelle muss über eine dokumentierte Sperrrichtlinie verfügen, und die Zertifizierungsstelle sollte in der Lage sein, jedes von ihnen ausgestellte Zertifikat zu widerrufen.

7. Die Zertifizierungsstelle muss alle zwölf (12) Monate eine Prüfung durchführen und die Prüfergebnisse an Microsoft übermitteln. Das Audit muss die vollständige PKI-Hierarchie abdecken, die von Microsoft durch die Zuweisung von EKUs (Extended Key Usages) aktiviert wird. Alle von uns aktivierten Zertifikatsverwendungen müssen regelmäßig überprüft werden. Der Prüfbericht muss den gesamten Umfang der PKI-Hierarchie dokumentieren, einschließlich aller Unterzertifizierungsstellen, die einen bestimmten Zertifikatstyp ausstellen, der von einer Prüfung abgedeckt wird. Zu den zulässigen Prüfungen gehören:

   • WebTrust für Zertifizierungsstellen v1.0 oder höher, die von einem lizenzierten Prüfer für WebTrust für Zertifizierungsstellen durchgeführt werden,

   • ETSI TS 101 456 v1.2.1 oder höher,

   • ETSI TS 102 042 V1.1.1 oder höher oder

   • ISO 21188: 2006, „Public-Key-Infrastruktur für Finanzdienstleistungen - Praktiken und politische Rahmenbedingungen“, ergänzt durch beide ein lizenzierter Prüfer von WebTrust for CAs oder eine Prüfbehörde, die gemäß den Gesetzen und Richtlinien für Prüfer in derselben Gerichtsbarkeit wie die Zertifizierungsstelle arbeitet.

Dies sind die derzeit akzeptierten Audits für nichtstaatliche Zertifizierungsstellen. Wir behalten uns das Recht vor, die oben aufgeführten Audits zu ändern und / oder andere vergleichbare Audits in Zukunft zu akzeptieren.

Technische Anforderungen

Neue Stammzertifikate müssen die folgenden technischen Anforderungen erfüllen:

• Stammzertifikate müssen x.509 v3 sein Zertifikate.

• Der Antragstellername muss einen aussagekräftigen Namen der Zertifizierungsstelle enthalten (z. B. kann nicht "Root" oder "CA1" sein).

• Erweiterung für grundlegende Einschränkungen: cA = true

• Schlüsselverwendung (falls vorhanden): nur keyCertSign und cRLSign

• Root Die Anforderungen an Schlüsselgrößen basieren auf NIST SP 800-57:

    RSA größer oder gleich 2048-Bit-Modul ECC größer oder gleich P256-Modul  

• Der Hash-Algorithmus muss mindestens SHA1 sein. Es werden keine MD2-, MD4- oder MD5-Hashes akzeptiert.

• Bei einer Root-Schlüsselgröße von mindestens einem RSA 2048-Bit-Modul darf das Root-Zertifikat erst nach mindestens 8 Jahren ablaufen Nach der Einreichung und spätestens 2030. Größere Stammschlüsselgrößen können länger gültig sein.

• Zwischenzertifizierungsstellenzertifikate sind vom Stammzertifizierungsstellenprogramm ausgeschlossen (weitere Informationen finden Sie unter Häufig gestellte Fragen) Informationen)

• Die Zertifizierungsstelle stellt mit Wirkung zum 15. Januar 2009 keine untergeordneten oder Endentitätszertifikate für MD2, MD4 oder MD5 von einem vom Programm vertriebenen Stammzertifikat aus.

• Bestehende ("Legacy") 1024-Bit-RSA-Stammzertifikate können vom Programm bis zum NIST-Termin am 31. Dezember 2010 verteilt werden, sofern dies nicht von Microsoft bereitgestellt wird.

Die Zertifizierungsstelle kann bis zum NIST-Termin am 31. Dezember 2010 1024-Bit-RSA-Zertifikate aus vom Programm verteilten Stammzertifikaten ausstellen.

Demonstration der Erstellung einer nicht autorisierten Zertifizierungsstelle unter Verwendung von MD5-Schwachstellen:

• Originalrecherche
• Berichterstattung in der Presse

Ich versuche, mich auf die zweite Frage zu konzentrieren.

Das Problem "Welche vertrauenswürdigen Standardstammzertifikate soll ich entfernen?" hängt im Wesentlichen davon ab, mit wem Sie es zu tun haben.

Sie müssen "nur" allen Zertifizierungsstellen vertrauen, die eine der Websites signieren, mit denen Sie eine Verbindung herstellen.

Für einen Benutzer vom Typ Oma besucht immer die gleichen wenigen Websites, wahrscheinlich reichen eine Handvoll Zertifizierungsstellen aus, während die Liste für einen starken Internetnutzer nicht so schnell wächst.

Warum nicht so schnell ? Gegenintuitiv werden einige Zertifizierungsstellen häufig verwendet (einschließlich zu großer, um zu versagen), während andere im Internet nur selten verwendet werden, wie einige fast geografische.

Das Tool SSLCop von securitybydefault kann dazu beitragen, Länder zu blockieren, denen Sie misstrauen / die Sie wahrscheinlich nicht benötigen (z. B. erwarten Sie keinen Zugriff auf eine Website der Brobdingnag-Regierung, deren Hauptnutzer zufällig ist diese Zertifizierungsstelle): http://www.security-projects.com/?SSLCop

Wenn Sie jedoch zu vielen Zertifizierungsstellen nicht vertrauen, können Sie diese nicht erhalten Ein Vertrauensanker für Websites, die Ihre Benutzer benötigen (und sie werden trotz der Sicherheitswarnung trotzdem auf sie zugreifen), was ebenso schlecht ist.

Ab dem 12. Juni 2012 hat Microsoft einen neuen Updater veröffentlicht, der nicht vertrauenswürdige Stammzertifikate und alle anderen Zertifikate deaktiviert, die Microsoft als nicht vertrauenswürdig gemeldet werden.

Das Update ist hier verfügbar, und ich bin unklar Wenn dieses Update bereits über Windows-Updates verteilt wurde oder wenn es sich um ein Out-of-Band-Update handelt.

http://support.microsoft.com/kb/2677070