Frage:
Wie machbar ist es, dass eine Zertifizierungsstelle gehackt wird? Welche standardmäßigen vertrauenswürdigen Stammzertifikate sollte ich entfernen?
goodguys_activate
2011-02-24 01:54:23 UTC
view on stackexchange narkive permalink

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

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

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, sind 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 Möglichkeiten dazu ein Zertifikat an die falsche Partei ausstellen. Dies kann durch CA-Betreiberfehler, behördliche Anforderungen oder möglicherweise durch Zwang (Bestechung) eines CA-Betreibers geschehen.

Ich möchte mehr darüber erfahren, welche Standard-CAs mit größerer Wahrscheinlichkeit Zertifikate an die CA ausstellen falsche Partei. 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 annehmen Microsoft.com und fordert eine Ausnahme vom Überprüfungsprozess der Zertifizierungsstelle. Diese Regierung verlangt dann auch die Wahrung der Geheimhaltung dieser Ausnahme. Das generierte Schlüsselpaar wird dann bei einem MITM-Angriff verwendet.

Windows Azure-Standardvertrauensstellung

Windows Azure unterstützt 275 Zertifizierungsstellen, wie in the gezeigt folgenden Link. 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 teilen Sie Links zu Amazon, Google, und die Standard-CA-Liste von VMWare, wenn Sie auf sie 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

Ich denke, Sie müssen Ihre Terminologie bereinigen. "Zertifikate" sind öffentlich zugängliche Informationen. Ich denke, Sie meinen "Schlüsselpaar" und Sie gehen hier viel davon aus, dass alle SSL-Schlüsselpaare auf dieselbe Weise generiert werden und dass jede einzelne Zertifizierungsstelle nur einen Weg zur Ausstellung von Schlüsseln und Zertifikaten verwendet. Ich denke auch, dass Sie wahrscheinlich "Trusted Cert Store" und nicht "Trusted Root Store" meinen, weil Sie möglicherweise von einer schwachen Zwischenzertifizierungsstelle sprechen, die von einem anständigen vertrauenswürdigen Stamm signiert wurde ...
@bethlakshmi - Ich hatte den Eindruck, dass der private Schlüssel nie an die vorgelagerte Zertifizierungsstelle gesendet wurde, und sagte aus diesem Grund kein Schlüsselpaar. Ist das falsch
Nein, ist es nicht ... aber Zertifizierungsstellen stellen Zertifikate aus, also versuche ich zu verstehen, was Sie unter "erzwungen" verstehen. Viele Zertifizierungsstellen können dazu gebracht werden, ein Zertifikat auszustellen, indem sie eine Pauschalgebühr erhalten ... das ist kaum "Zwang". Ich nahm an, Sie meinten, Sie wollten, dass die Zertifizierungsstelle ihren privaten Schlüssel aufgibt? Wenn Sie meinen, "gezwungen zu sein, ein Zertifikat auszustellen *, ohne die entsprechende Authentifizierung durchzuführen, die für die Sicherheitsrichtlinie erforderlich ist *", wäre dies auch eine hilfreiche Klarstellung.
@bethlakshmi - Ich habe mehrere Klarstellungen vorgenommen. Würde mich über Ihre Bewertung freuen ...
Die Klärung Ihres Bedrohungsmodells würde viel helfen, wie in der FAQ erläutert. Ich gehe davon aus, dass viele Zertifizierungsstellen für einen umfassenden Angriff einer versierten großen Regierung anfällig sind, sei es durch Zwang oder Social Engineering oder durch Ausnutzung von Sicherheitslücken. All dies wurde bereits in freier Wildbahn demonstriert. Wenn Sie nur ein kleiner Fisch sind, müssen Sie sich wahrscheinlich noch um ein paar Zertifizierungsstellen sorgen, die eng mit Regierungen verbunden zu sein scheinen, die gerne schnüffeln. 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.
Verwandte: DigiNotars CA wurde gehackt [erlaubt MITM-Angriffe] (http://slashdot.org/story/11/08/30/1431211/Diginotar-Responds-To-Rogue-Certificate-Problem)
Ein unabhängiger Bericht von Fox-IT über den DigiNotar-Hack wurde veröffentlicht, siehe http://www.scribd.com/doc/64011372/Operation-Black-Tulip-v1-0
auch http://features.techworld.com/security/3408741/year-after-diginotar-security-breach-fox-it-details-extent-of-compromise/
Meine Politik: Entfernen Sie alle Zertifikate, die von Ländern mit unterdrückenden Regierungen gehostet werden.
Zwölf antworten:
#1
+66
nealmcb
2011-02-24 08:32:33 UTC
view on stackexchange narkive permalink

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:

Tolle Links; Ich werde dies sicher +1 verwenden
DNSSEC ist kein Allheilmittel
@nealmcb: Der Artikel besagt, dass die iranische Regierung das Zertifikat einer CA gestohlen hat. Damit bedeutet es, dass die Regierung. hat den privaten Schlüssel der CA gestohlen, oder? Ich verstehe nicht, wie Sie den privaten Schlüssel stehlen können
@Ashwin Auf welchen Artikel beziehen Sie sich? Beachten Sie auch, dass einige private Schlüssel zwar durch ausgefallene Hardware gut geschützt sind, andere jedoch nur Teile eines Allzweckcomputers sind und leichter gestohlen werden können. Es ist auch oft möglich, neue Zertifikate zu erstellen, ohne den privaten Hauptschlüssel zu haben, z. indem Sie einen Registrar unterwandern oder die Kontrolle über ein delegiertes CA-Zertifikat erlangen, wie in anderen Artikeln erläutert, auf die hier verwiesen wird.
Ein weiterer Missbrauch ereignete sich Anfang dieses Monats, in diesem Fall vom National Informatics Center (NIC) in Indien: http://googleonlinesecurity.blogspot.com.es/2014/07/maintaining-digital-certificate-security.html
Und dann gibt es die Root-Zertifikate, die von Herstellern wie Lenovo eingefügt wurden, wie das [verrückte von Superfish] (http://security.stackexchange.com/a/82040/453), das mit einer eigenen unsicheren Zertifizierungsstelle geliefert wird, einschließlich des privaten Schlüssels . Werde diesen auch los!
#2
+41
D.W.
2011-03-18 21:42:01 UTC
view on stackexchange narkive permalink

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.

Dies ist so prägnant und eloquent formuliert, dass ich diese Antwort akzeptieren musste. Ich wäre immer noch daran interessiert, das Risiko innerhalb jeder vertrauenswürdigen Wurzel zu bewerten.
@makerofthings Aber denken Sie daran - Sie sind der Ort, an dem Vertrauen beginnt - der Weg ist letztendlich kreisförmig. Nur Sie können anhand Ihrer Vermögenswerte und Bedrohungen beurteilen, ob Sie sich Sorgen machen, basierend auf dem, was Sie über die einzelnen Zertifizierungsstellen wissen, und ob sie Sie wahrscheinlich den Fluss hinunter verkaufen werden.
#3
+18
Rory McCune
2011-02-24 03:32:14 UTC
view on stackexchange narkive permalink

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.

Kennen Sie eine Methode zur Überprüfung einer Zertifizierungsstelle?
Eine grundlegende Vertrauenswürdigkeit könnte durch ein Standard-Audit im Stil der Informationssicherheit festgestellt werden (mit den üblichen Einschränkungen hinsichtlich der Wirksamkeit von ISO27XXX usw.). Die Wahrscheinlichkeit, Daten an Regierungsorganisationen weiterzugeben, wäre schwierig. Ich denke, Sie müssten in einem bestimmten Land gesetzliche und rechtliche Schutzbestimmungen für die Privatsphäre festlegen und diese dann gegen wahrscheinliche Anreize für eine Regierungsorganisation abwägen, Zugang zu den Informationen zu erhalten. Wenn Sie sich Sorgen über die Interferenz auf Regierungsebene machen, würde ich letztendlich dazu neigen, Ihre CA einzurichten und keiner öffentlichen zu vertrauen :)
DigiNotar is one example.
#4
+11
AviD
2011-02-28 01:26:20 UTC
view on stackexchange narkive permalink

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 Ziemlich gut bekannt gewordener Vorfall von SSL-Phishing - eine gefälschte Bank-Website erhielt ein legitimes SSL-Zertifikat (von GeoTrust, glaube ich) für einen Rechtschreibfehler auf der Website einer Regionalbank. (Update: diesen historischen Link gefunden - 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 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 ...

    Schöne Antwort, aber vielleicht auf eine andere Frage. Natürlich ist es immer verlockend, sich zu fragen, ob es nicht gestellte Fragen gab ... Vielleicht sollten wir ein Wiki für das SSL-Tag mit den verschiedenen Fragen versehen, von denen wir immer denken, dass die Leute sie stellen sollten ...
    @nealmcb, Ich stimme zu - aber wie Sie gerne sagen: "Was ist Ihr Bedrohungsmodell?" Ich wollte darauf hinweisen, dass er die falsche Frage stellte, um sein angegebenes "Problem" zu lösen.
    Ja - ich würde auch gerne mehr Hintergrundinformationen in der Frage sehen, um herauszufinden, welches Problem dazu geführt hat. Aber es ist eine saubere Frage mit sauberen Antworten. Es verdient nur, in einem Netz von anderen nützlicheren Fragen zu anderen Aspekten von ssl zu sein, die wir auf dieser Seite langsam weben :)
    #5
    +9
    Sander Temme
    2011-08-31 11:30:09 UTC
    view on stackexchange narkive permalink

    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.

    #6
    +4
    Steve Dispensa
    2011-09-04 21:56:07 UTC
    view on stackexchange narkive permalink

    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.

    #7
    +3
    Steve
    2011-02-24 04:45:33 UTC
    view on stackexchange narkive permalink

    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.

    #8
    +3
    symcbean
    2011-02-24 19:57:12 UTC
    view on stackexchange narkive permalink

    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.

    Sie benötigen kein gefälschtes Zertifikat, sondern nur ein vertrauenswürdiges Zertifikat, das von der erzwungenen Zertifizierungsstelle signiert wurde, um einen MITM-Angriff auszuführen. Fortinet-Firewalls machen dies einfach, da sie für MITM-Angriffe konfiguriert werden können. Der einzige Grund, warum MITM bei der Arbeit fehlgeschlagen ist, war, dass auf meinem Computer das Fortinet-Zertifikat nicht installiert und vertrauenswürdig war. Daher wurde beim Starten von Mac Mail eine Warnung angezeigt (Google Mail hatte ein ungültiges Zertifikat).
    #9
    +3
    goodguys_activate
    2012-06-02 18:21:31 UTC
    view on stackexchange narkive permalink

    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 " 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:

  • ETSI 102 042
  • ETSI 101 456
  • WebTrust für Zertifizierungsstellen
  • WebTrust EV-Bereitschaftsprüfungen
  • ISO 21188 (Beachten Sie, dass ISO 27001 nicht akzeptiert wird)
  • 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

    p> Verbotene Schlüsselverwendungen

    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:

    8. 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.

    #10
    +1
    Bradley Kreider
    2011-02-24 21:04:50 UTC
    view on stackexchange narkive permalink

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

    Bitte geben Sie einige aktuelle, relevante Inhalte in die Antworten ein - nicht nur Links.
    Punkt genommen, aber es beantwortet die erste Frage: Wie machbar ist es: sehr.
    #11
    +1
    Ángel
    2014-07-18 04:07:23 UTC
    view on stackexchange narkive permalink

    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.

    #12
      0
    goodguys_activate
    2012-08-09 16:36:17 UTC
    view on stackexchange narkive permalink

    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



    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
    Loading...