it-swarm-eu.dev

Wie machbar ist es, dass eine Zertifizierungsstelle gehackt wird? Welche standardmäßigen vertrauenswürdigen Stammzertifikate sollte ich entfernen?

Diese Frage wurde seit der Originalversion erheblich überarbeitet und geklärt.

Wie sehr sollte ich ihnen vertrauen, wenn wir uns jedes vertrauenswürdige Zertifikat in meinem vertrauenswürdigen Stammspeicher ansehen?

Welche Faktoren sollten berücksichtigt werden, wenn ich das Vertrauen jeder Stammzertifizierungsstelle hinsichtlich einer möglichen Entfernung aus meinem lokalen Geschäft bewerte?

Weitere Informationen:
Wenn eine Zertifizierungsstelle ein Zertifikat an eine nicht ordnungsgemäß validierte Partei ausstellt, werden alle Computer, die dieser Zertifizierungsstelle vertrauen, für MITM-Angriffe anfällig. Infolgedessen validieren alle Zertifizierungsstellen den Anforderer einer bestimmten SSL-Zertifikatanforderung streng, um die Integrität ihrer CS-Kette sicherzustellen.

Ein großer Teil dieses CA-Überprüfungsprozesses unterliegt jedoch menschlichen Eingriffen und bietet die Möglichkeit, ein Zertifikat an die falsche Partei auszustellen. Dies kann durch Fehler des CA-Betreibers, Forderungen der Regierung oder möglicherweise durch Zwang (Bestechung) eines CA-Betreibers geschehen.

Ich möchte mehr darüber erfahren, welche Standardzertifizierungsstellen mit größerer Wahrscheinlichkeit Zertifikate an die falsche Partei ausstellen. Ich beabsichtige, diese Informationen zu verwenden, um Benutzern zu empfehlen, diese Zertifizierungsstelle aus ihrem Trusted Cert Store zu entfernen

Beispiele:
Angenommen, die Regierung, die eine bestimmte Zertifizierungsstelle kontrolliert, möchte die Identität von Microsoft.com annehmen und fordert eine Ausnahme vom Überprüfungsprozess der Zertifizierungsstelle. Diese Regierung verlangt dann auch die Wahrung der Geheimhaltung dieser Ausnahme. Das generierte Schlüsselpaar würde dann bei einem MITM-Angriff verwendet.

Windows Azure-Standardvertrauensstellung

Windows Azure unterstützt 275 Zertifizierungsstellen, wie in dem folgenden Link gezeigt. Abhängig von der Verwendung der jeweiligen Zertifizierungsstelle können einige dieser Zertifizierungsstellen die Oberfläche eines bestimmten Angriffs vergrößern. Tatsächlich kann dies technisch erforderlich sein, damit einige Anwendungen ordnungsgemäß funktionieren.

Amazon Default Trust

(nicht verfügbar) Bitte geben Sie Links zu Amazon, Google und der Standard-CA-Liste von VMWare frei, wenn Sie auf diese stoßen.

Mozilla

Eine Liste aller Zertifikate und Prüfanweisungen ist verfügbar.

Apple iOS

Liste aller iPhone-Stammzertifikate , wie in dieser # WWDC2017 erwähnt. Video

84

Update 5 Das Hauptproblem (heh) mit dem CA-Modell besteht darin, dass in der Regel jede CA Zertifikate für jede Domain ausstellen kann, sodass Sie anfällig sind zum schwächsten Glied. 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 gebe ich einige Details an und ende mit Links zu möglichen Korrekturen.

Im Jahr 2009 hat Etisalat (60% im Besitz der Regierung der Vereinigten Arabischen Emirate) einen harmlos aussehenden BlackBerry-Patch herausgebracht, der Spyware in RIM-Geräte einfügt und die Überwachung von E-Mails ermöglicht, sodass diese kaum als vertrauenswürdig angesehen werden können. Aber es ist in vielen vertrauenswürdigen CA-Listen enthalten: 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, angeblich von einem Iraner 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 betreibt, 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 reagierte - 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 des 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 enthüllen einen erfolgreichen Angriff der Zertifizierungsstelle, möglicherweise aus dem Iran | Freiheit zum 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 worden war, um falsche Zertifikate für die Websites von Google, Yahoo! Mozilla, WordPress und Das Tor-Projekt. DigiNotar hat über einen Monat lang sein Wissen über das Eindringen in seine Website nicht preisgegeben. Weitere Informationen finden Sie unter DigiNotar-Hack hebt die kritischen Fehler unseres SSL-Web-Sicherheitsmodells hervor | 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 ausgeklügelte Angriffe bleiben.

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

Es spricht über diese Innovationen:

Update 4 Einer unserer IT-Sicherheits-Blogbeiträge im August 2011 behandelt auch den Fall der Umstellung auf DNSSEC: Ein risikobasierter Blick auf die Fehlerbehebung das Problem der Zertifizierungsstelle "Stack Exchange Security Blog

Update 6 Mehrere Zertifizierungsstellen wurden bei Verstößen gegen die Regeln erwischt. Dazu gehören die französische Cyberdefense-Agentur (ANSSI) und Trustwave, von denen jede im Zusammenhang mit dem Spoofing digitaler Zertifikate war.

Update 7 Noch ein Satz "falsch ausgestellter Zertifikate" ü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 , die hilfreich erscheint, um fehlerhafte Zertifikate und Richtlinienverstöße früher zu erkennen.

64
nealmcb

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 CA liegen und welche potenziellen Risiken in der Vereinbarung bestehen.

38
D.W.

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 als nicht vertrauenswürdig bekannt wird, 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 Zertifikate bereitstellt, ohne den Anforderer entsprechend zu überprüfen. Vor einigen 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, eine weiße Liste von Zertifizierungsstellen zu erstellen, die Sie überprüft haben und mit der bereitgestellten Sicherheit zufrieden 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.

18
Rory McCune

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

  • Vor einigen Jahren (2006 oder vielleicht Ende 2005) gab es einen ziemlich gut bekannt gewordenen Vorfall von SSL-Phishing - eine gefälschte Bank-Website erhielt ein legitimes SSL-Zertifikat (von GeoTrust, glaube ich), weil die Website einer regionalen Bank falsch geschrieben wurde. (Update: gefunden dieser historische Link - Die Adresse war für den vollständigen Namen der Bank anstelle des verkürzten Akronyms). Seitdem gab es andere Fälle von SSL-Phishing .... Punkt ist, dass es möglich ist, ein Zertifikat zu erhalten, ohne auf "Zwang" zurückzugreifen.
  • Die jüngste Novelle Stuxnet stützte sich unter anderem auf gestohlene Zertifikate. Diese wurden von Treiberherstellern von Drittanbietern "ausgeliehen" und konnten, da sie "vertrauenswürdig" waren, missbraucht werden, um die Malware zu installieren.

Dann gibt es natürlich die Softwareszenarien, in denen die Zertifizierungsstelle nicht einmal zum Einsatz kommt - z. mit Thick-Clients, die Web Services aufrufen und sich nicht die Mühe machen, das Serverzertifikat zu überprüfen ....

Mein Punkt ist, dass, wenn Sie sich über MITM über SSL Sorgen machen, es meistens nicht der staatliche Zwang ist, der Sie beunruhigen sollte. Es gibt normalerweise einfachere und zugänglichere Wege.
Ich lehne es sogar ab, "Trusted Certs" als "Trusted" zu bezeichnen ... Nur weil ich weiß, wer Sie sind, heißt das nicht, dass ich Ihnen vertrauen sollte ... und es bedeutet nicht, dass ich darauf vertrauen sollte, dass Sie jemanden kennen else is.

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

Auf der anderen Seite, wenn Sie mit einem Server/einer Appliance zu tun haben, der nicht allgemeine Browsing-Funktionen benötigt, sondern mit einem bestimmten Server kommuniziert (oder Server), entfernen Sie auf jeden Fall [~ # ~] alle [~ # ~] Root-Zertifikate, mit Ausnahme einer Whitelist der von Ihnen benötigten.
Und wenn Sie mit Ihrer eigenen internen Zertifizierungsstelle arbeiten, noch besser ...

11
AviD

Jede Zertifizierungsstelle veröffentlicht eine Certificate Practice Statement, in der beschrieben wird, wie sie ihre eigenen Schlüssel schützen und Anforderungen für Zertifikate validieren, 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 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.

9
Sander Temme

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

4
Steve Dispensa

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

error- you're deleting a system cert!!

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 " nur aus älteren Gründen " existieren.

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

  • ETSI 102 042
  • ETSI 101 456
  • WebTrust für Zertifizierungsstellen
  • WebTrust EV-Bereitschaftsprüfungen
  • ISO 21188 (Beachten Sie, dass sie ISO 27001 nicht akzeptieren)

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

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

Verbotene Schlüsselverwendungen

Die folgenden Schlüsselverwendungen sind vom Programm verboten:

  • Smartcard-Anmeldung Dies ist ein Szenario nur für Unternehmen, da eine Active Directory-Bereitstellung erforderlich ist und der Stamm 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 Unternehmen und andere inakzeptable EKUs zulässt.

  • Verzeichnisdienst-E-Mail-Replikation Unternehmensszenario

  • Agent für Zertifikatsanfragen

  • Enterprise CA-Szenario

  • Enterprise CA-Szenario für Key Recovery Agent

  • CA-Verschlüsselungszertifikat

  • Enterprise CA-Szenario

Akzeptanzkriterien

Darüber hinaus müssen folgende 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 Schritt 1. Microsoft kontaktieren ) und eine vorläufige Genehmigung für die Mitgliedschaft im Programm erhalten.

  2. Die Zertifizierungsstelle muss zu Testzwecken ein Testzertifikat bereitstellen, das vom Stammzertifikat der Zertifizierungsstelle ausgestellt wurde. 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. (Siehe FAQ für Details)

  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. Root-Zertifikate 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. Von einem Stammzertifikat ausgestellte Zertifikate müssen die CRL-Verteilungspunkterweiterung unterstützen. Der CRL-Verteilungspunkt sollte auf einen öffentlich zugänglichen Ort 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 ein Audit durchführen und die Auditergebnisse 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. Geeignete Audits umfassen:

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-Zertifikate sein.

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

  • Grundlegende Constraints-Erweiterung: cA = true

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

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

         RSA greater or equal to 2048-bit modulus
    
         ECC greater or equal to P256 modulus
    
  • Der Hash-Algorithmus muss mindestens SHA1 sein. Es werden keine MD2-, MD4- oder MD5-Hashes akzeptiert.

  • Bei einer Root-Schlüsselgröße, die größer oder gleich einem RSA 2048-Bit-Modul ist, darf das Root-Zertifikat erst mindestens 8 Jahre nach der Übermittlung und spätestens 2030 ablaufen. Bei größeren Root-Schlüsselgrößen kann ein längerer Ablauf gewährt werden.

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

  • Die Zertifizierungsstelle stellt mit Wirkung zum 15. Januar 2009 keine untergeordneten oder End-MD2-, MD4- oder MD5-Zertifikate von einem vom Programm verteilten 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.

3

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 zu erstellen. Ich konnte keine Beweise dafür finden, daher erinnere ich mich vielleicht an etwas in Anlehnung an die von Rory erwähnten DefCon-Gespräche.

3
Steve

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 haben nichts miteinander zu tun. 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 Maschinen 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. Aktuelle Probleme mit dem MD5-Format und Etisalat legen nahe, dass dies nicht unmöglich ist.

3
symcbean

Ich versuche mich auf die zweite Frage zu konzentrieren.

Das Problem "Welche standardmäßigen vertrauenswürdigen Stammzertifikate 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, zu denen Sie eine Verbindung herstellen.

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

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

Das Tool SSLCop from 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, die zufällig der Hauptbenutzer dieser Zertifizierungsstelle): http://www.security-projects.com/?SSLCop

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

1
Ángel

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

1
Bradley Kreider

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 mir nicht sicher, ob dieses Update bereits über Windows-Updates verbreitet wurde oder ob es sich um ein Out-of-Band-Update handelt.

http://support.Microsoft.com/kb/267707

0