Warum sind alle CA-Stammzertifikate SHA-1-signiert (da SHA-1 veraltet ist)?

67

Ich verstehe, dass SSL-Zertifikate nicht mehr mit SHA-1 signiert werden können. Alle CA-Stammzertifikate sind jedoch (meistens) mit SHA-1 signiert. Bedeutet dies, dass derselbe Algorithmus, dem "Sie, Ihre Oma, SSL-Shop" nicht mehr vertraut, für das höchstgesicherte Zertifikat der Welt in Ordnung ist?

Vermisse ich etwas? (Schlüsselverwendung? Schlüsselgröße?)

ssl ssl-certificate certificate-authority

— 131
quelle

9

Es ist nicht wahr, dass "alle" CA-Stammzertifikate SHA1 sind.

— Greg Askew

5

Stammzertifikate sind wie Startannahmen in einer Weltanschauung. Es braucht Glauben, um ihnen zu vertrauen.

— Roy Tinker

@ RoyTinker außer cogito ergo sum (siehe radikale Zweifel, und es ist die Antwort: Kartesische Skepsis )?

— Nick T

1

Cross-Stack: security.stackexchange.com/questions/120301/... und superuser.com/questions/1122069/...

— dave_thompson_085

6

@ NickT: Gehen Sie auf Nummer sicher - cogito ergo cogito ;-)

— tonysdg

106

Die Signatur der Stammzertifizierungsstellenzertifikate spielt keine Rolle, da sie nicht überprüft werden müssen. Sie sind alle selbst signiert.

Wenn Sie einem Zertifikat der Stammzertifizierungsstelle vertrauen, müssen Sie dessen Signatur nicht überprüfen. Wenn Sie ihm nicht vertrauen, ist seine Unterschrift für Sie wertlos.

Bearbeiten: Es gibt einige sehr relevante Kommentare unten. Ich fühle mich nicht wohl, wenn ich sie kopiere oder umformuliere und ihnen anstelle ihrer Autoren Anerkennung ziehe. Aber ich begrüße es, wenn die Leute Erklärungen zu dieser Antwort hinzufügen.

— user2233709
quelle

3

Wirft die Frage auf, warum sie überhaupt unterschrieben sind

— Richard Tingle

42

Weil das System keine Zertifikate unterstützt, die nicht signiert sind.

— OrangeDog

Es scheint mir, dass das Problem mit einem knackbaren Stammzertifikat nicht "Sie wissen nicht, woher Sie das Stammzertifikat haben" ist, sondern "Sie wissen nicht, wer dieses Zertifikat noch geknackt und verwendet hat zu unterzeichnen, was sie wollen. " Und aus Ihrer Antwort geht hervor, dass die beiden Aspekte (Zertifikat und Zertifizierungssignatur) voneinander getrennt sind und dass das Zertifikat selbst angemessen sicher und unknackbar ist?

— Dewi Morgan

20

Ich würde sogar noch weiter gehen als "es gibt keine Notwendigkeit, sie zu überprüfen". Der Zweck der Signatur in einer Zertifikatskette besteht darin, dass eine höhere Behörde eine niedrigere Behörde zertifiziert. Für eine Stammzertifizierungsstelle gibt es per Definition keine höhere Berechtigung (was "Stamm" bedeutet), sodass es niemanden gibt, der möglicherweise das Zertifikat signieren könnte . Da, wie bereits erwähnt, Zertifikate signiert werden müssen, werden Stammzertifizierungsstellen mit einer "Dummy" -Signatur signiert. Der einfachste Weg, dies zu tun, ist das Selbstsignieren. Es muss also nicht nur nicht überprüft werden, die Idee, die Signatur einer Stammzertifizierungsstelle zu überprüfen, ist auch nicht sinnvoll.

— Jörg W Mittag

13

@DewiMorgan Ein Root-Zertifikat kann nicht mit einer Hash-Kollision "geknackt" werden, da der Client dem Zertifikat selbst vertraut und nicht seiner (Selbst-) Signatur. Sie müssten den privaten Schlüssel wiederherstellen, der einen Angriff auf RSA darstellt, nicht auf den Hash-Algorithmus.

— zwol

46

Am Ende des Tages ist ein Stammzertifikat selbst signiert. Es wird nie von einer anderen Entität außer von sich selbst signiert. Das Stammzertifikat erhält seine Vertrauenswürdigkeit durch Out-of-Band-Prozesse wie das Senden an eine Browserliste vertrauenswürdiger Herausgeber oder das Akzeptieren durch Microsoft zum Einfügen in die Standardliste vertrauenswürdiger Windows-Herausgeber.

Diese Zertifikate (und die Unternehmen, die sie selbst signiert haben) werden (angeblich, hoffentlich) auf andere Weise als nur durch ihre Signaturen gründlich überprüft.

— Mark Henderson
quelle

2

Ganz zu schweigen davon, dass zum Aktualisieren eines Stammzertifikats dieser Out-of-Band-Prozess erneut ausgeführt werden muss.

— Kaithar

4

+1 für die "angeblich, hoffentlich"

— Nathan Osman

6

Der einzige Fall, in dem dies von Bedeutung ist, ist, wenn die Wurzel von SHA-1 signiert ist, kann sie von SHA-1 widerrufen werden. Das heißt, jemand, der SHA-1 angreifen kann, kann einen Widerruf für die Wurzel konstruieren. Und ich bin mir absolut sicher, dass der Browser nicht weiß, wie er das durchhalten soll. Der Vandal hat also nur das Löschen von SSL-Verbindungen erreicht. Wie Lahm.

— Joshudson
quelle

1

Dies ist ein interessanter Gedanke, aber ich bezweifle, dass dies genau so funktionieren würde. Ich vermute, dass jeder Agent sein eigenes Verhalten hat, aber ich bezweifle, dass Entwickler auf die Idee gekommen sind, die Sperrliste zum Verwalten des Widerrufs von Stammzertifikaten zu verwenden. Zumindest, wenn dies in einigen Fällen funktioniert, liegt dies an der Abstraktion des Software-Widerrufs und nicht absichtlich durch Entwickler.

— Peter Oehlert

1

In diesem Fall haben einige Zertifizierungsstellen ihre Stamm- und Zwischenzertifikate ohnehin bereits auf SHA256 aktualisiert.

Ich weiß, dass GlobalSign im letzten Jahr die Zertifikate aktualisiert hat, als wir die Codesignaturzertifikate aktualisiert haben. Deshalb musste ich auch deren neue Kette hinzufügen.

Sie können hier überprüfen, welche spezifischen Zertifikate aktualisiert wurden und welche, aber auch ein älteres SHA1-Zertifikat hinterlassen haben => 1

Ich hoffe, das hilft.

— B.Kaatz
quelle

0

Für die Stammzertifizierungsstelle vertrauen Sie dem öffentlichen Schlüssel der im CRT enthaltenen Zertifizierungsstelle - unabhängig von ihrer Selbstsignatur.

Durch die Beschreibung der Zertifizierungsstelle mithilfe des CRT-Dateiformats anstelle eines unformatierten öffentlichen Schlüssels können weitere Details darin gebündelt werden, z. B. der Name der Zertifizierungsstelle. (Auch hier ist die Signatur wertlos.)

— 131
quelle

-1

Es gibt sehr alte, meistens bereits vertrauenswürdige SHA1-Stammzertifikate aus dem Jahr 2006 oder früher , die von Browsern akzeptiert werden, jedoch keine neueren Zertifikate. Erinnern Sie sich, als Firefox und Chrome mit einstelligen Zahlen versioniert wurden?

Zertifikate schlagen fehl, wenn die Stammzertifizierungsstelle SHA1-Zertifikate verwendet, bei denen Not Before auf einen Wert nach 2014 festgelegt ist. Die tatsächlichen Datumsbeschränkungen hängen vom Browser oder einer anderen Anwendung ab. Das WebCA cabforum hat dies vor einigen Jahren deutlich gemacht. Testen Sie dies selbst durch:

Erstellen Sie eine private Stammzertifizierungsstelleninfrastruktur, die mit einem SHA1 signiert ist, und nennen Sie sie rootSHA1
Lassen Sie rootSHA1 eine "ausstellende" Zertifizierungsstelle oder eine "zwischengeschaltete" Zertifizierungsstelle erstellen, die Zertifikate mit einem an root geketteten Zertifikat ausstellt. Nennen Sie es intermediateSHA256.
Lassen Sie die ausstellende Zertifizierungsstelle von intermediateSHA256 Zertifikate generieren, die mit einem Hash von sha256 oder höher signiert sind. Nennen Sie es webServerSHA256.
Installieren Sie webServerSHA256 in webServerSHA56.mydomain.com.
Installieren Sie das rootSHA1-, das intermediateSHA256- und das webServerSHA256-Zertifikat an den entsprechenden Speicherorten in Google Chrome. Installieren Sie das Stammverzeichnis bei vertrauenswürdigen Stammzertifizierungsstellen und den anderen mit einer Zertifikatkette.
Navigieren Sie in Google Chrome zu https://webServerSHA256.mydomain.com/ und vergewissern Sie sich, dass für webServerSHA256 kein grünes Vorhängeschloss vorhanden ist. Test schlägt fehl.

— rjt
quelle

Das ist ganz falsch. Zwischenzertifikate (und EE./Blattzertifikate) erfordern SHA2, Roots jedoch nicht. Googles eigene Zertifikate werden über ihre private Zertifizierungsstelle (Google Internet Authority G3) mit der GlobalSign Root-Zertifizierungsstelle R2 (SHA1) verknüpft und von Chrome (nicht überraschend) akzeptiert.

— Dave_thompson_085

Ja, diese angehefteten SHA1-Zertifikate werden akzeptiert, aber keine neuen SHA1-Stammzertifikate, selbst wenn Sie sie Ihrem eigenen Speicher für vertrauenswürdige Stammzertifikate hinzufügen. Meiner Antwort wurde ein Testfall hinzugefügt.

— 11.