Gibt es ein Konzept, einem SSL / TLS-Zertifikat zu vertrauen, um eine einzelne Website zu identifizieren, aber nicht als Zertifizierungsstelle für andere Zertifikate fungieren soll?

395
Ethan T

Ich habe regelmäßig mit schlechten Zertifikaten in meinem Intranet zu tun (oder auf temporären Servern ohne ordnungsgemäß signiertes Zertifikat). Ich bin keinem Ansatz begegnet, bei dem ich das Zertifikat einer einzelnen Website (einschließlich des CN) in einem Browser speichern kann, ohne es auch als Zertifizierungsstelle für andere Websites anzuordnen. Ist dies konzeptionell möglich oder liegt dies außerhalb des Designs des PKI-Systems?

Bearbeiten, um zu klären : Nehmen wir an, ich arbeite an einem lokalen Server megaserver. Ich greife darauf über https: // Megaserver im Browser zu. Es verfügt über ein selbstsigniertes Zertifikat. Um vorerst sicher auf diesen Server zuzugreifen, füge ich das Zertifikat in meinem CA-Store in meinem Browser hinzu. Jemand stiehlt dieses Zertifikat, erstellt ein neues Zertifikat für https://www.google.com, signiert es mit den megaserverZertifikaten und greift mich im Man-in-the-Middle-Stil an. Mein Browser akzeptiert das Google-Zertifikat, da es auf meinem System von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde. Ist dieses hypothetische Szenario möglich?

0
Es ist das Kernmerkmal des gesamten SSL-Ökosystems. Wenn Sie einer bestimmten Zertifizierungsstelle vertrauen, würde Ihr Browser alles, was von dieser Zertifizierungsstelle signiert wurde, als vertrauenswürdig einstufen. Es ist der springende Punkt, CA als vertrauenswürdiges Verifizierungssystem von Drittanbietern zu verwenden. Wenn Sie für temporäre Sites von selbst signierten Zertifikaten sprechen, sollte deren CN nur mit diesem bestimmten CN übereinstimmen. Diese Art von Zertifikaten kann vor Ort für jeden Standort einzeln als vertrauenswürdig eingestuft werden Alex vor 7 Jahren 0
@alex Ich habe eine Klarstellung hinzugefügt. Beschränkt die CN des Zertifikats die Fähigkeit, andere Zertifikate zu signieren? Ethan T vor 7 Jahren 0
Nein, CA's CN kann beispielsweise abcd.com sein und sie können xyz.net, qwert.com unterschreiben, aber bevor sie dies tun, überprüfen sie die Besitzer von xyz.net oder qwert.com entweder durch einfache E-Mail-Bestätigung und bis zu einer Anfrage Pass, Telefonrechnungen und so weiter. Aus diesem Grund vertrauen Sie der Zertifizierungsstelle, da diese Domäneninhaber überprüft und deren Zertifikate erfolgreich signiert haben. Es gibt drei große Browser und einige Betriebssysteme, die die Verwaltung von CA-Vertrauensstellungen und die Auslieferung der CAs mit ihren Produkten ermöglichen. Wenn sich die Zertifizierungsstelle nicht in solchen Listen vertrauenswürdiger Zertifizierungsstellen befindet, können Sie die Zertifizierungsstelle manuell zum Zertifikatsspeicher hinzufügen und allen anderen signierten Zertifikaten vertrauen Alex vor 7 Jahren 0

2 Antworten auf die Frage

2
garethTheRed

Ja.

Ab RFC 5280:

4.2.1.9. Grundlegende Einschränkungen

Die Erweiterung für grundlegende Einschränkungen gibt an, ob der Antragsteller des Zertifikats eine Zertifizierungsstelle ist, und die maximale Tiefe der gültigen Zertifizierungspfade, die dieses Zertifikat enthalten.

Dann heißt es weiter:

Wenn die Erweiterung für grundlegende Einschränkungen nicht in einem Zertifikat der Version 3 vorhanden ist oder die Erweiterung vorhanden ist, der Boolean cA jedoch nicht aktiviert ist, DÜRFEN der zertifizierte öffentliche Schlüssel NICHT zur Überprüfung der Zertifikatsignaturen verwendet werden.

Das Überprüfen der Zertifikatsignaturen bedeutet, dass Sie als Zertifizierungsstelle fungieren.

Wenn für Ihr selbstsigniertes Zertifikat die Basiszertifizierungsstellenzertifizierungsstelle nicht auf true festgelegt ist, kann es daher nicht zum Signieren untergeordneter Zertifikate verwendet werden.

Sind Sie sicher, dass für alle diese selbstsignierten Zertifikate dieses Flag auf true gesetzt ist? In diesem Fall müssen Sie unbedingt mit dem Erzeuger sprechen, der sie generiert, und in die Richtung der kostenlosen Online-PKI-Schulungsressourcen weisen.

Ein Zertifikat zu stehlen ist kein Risiko - schließlich sind Zertifikate allgemein bekannt. Das Stehlen des zugehörigen privaten Schlüssels ist jedoch und macht Ihr Zertifikat unbrauchbar. Dieses jahrelange Problem (innerhalb der PKI-Welt) der Sicherung des privaten Schlüssels hat zur Entwicklung von Hardware-Sicherheitsmodulen geführt, um zu verhindern, dass der private Schlüssel in die falschen Hände gerät. Ich bezweifle jedoch, dass Sie so viel Geld für das selbstsignierte Zertifikat Ihres Intranets aufbringen möchten.

Ein besserer Ansatz besteht darin, sicherzustellen, dass Sie die Personen verwalten, die sich auf den Geräten anmelden, die diese Zertifikate erstellen. Systeme, die OpenSSL, GnuTLS, Java usw. verwenden, können den privaten Schlüssel mit einem Kennwort schützen. Windows verschlüsselt den privaten Schlüssel, aber sobald sich ein Administrator an diesem Windows-Computer angemeldet hat, ist der private Schlüssel tatsächlich für die Übernahme verfügbar.

0
Alex

F: Ich füge das Zertifikat zu meinem CA-Store in meinem Browser hinzu. Jemand stiehlt dieses Zertifikat, erstellt ein neues Zertifikat für https://www.google.com

Sie fügen dem Zertifikatsspeicher den öffentlichen Schlüssel der selbst erstellten lokalen Zertifizierungsstelle hinzu. Der einzige Inhaber des privaten Schlüssels von CA kann ein Zertifikat einer Person signieren (wie Sie es für https://www.google.com angegeben haben ). Das Stehlen des öffentlichen CA-Schlüssels von Ihrem Browser ist daher sinnlos, da er kein Geheimnis ist und nicht verwendet werden kann zum unterschreiben anderer zertifikate.

F: Mein Browser akzeptiert das Google-Zertifikat, da es von einem vertrauenswürdigen Zertifizierungsstellenzertifikat auf meinem System signiert wurde. Ist dieses hypothetische Szenario möglich?

Sie vertrauen Ihrem Browser, der wiederum bestimmten Bereichen von Zertifizierungsstellen vertraut. Wenn Sie Ihrem lokalen Browser Ihre lokale Zertifizierungsstelle als vertrauenswürdig für den Zertifikatspeicher hinzugefügt haben, vertrauen Sie automatisch allen von dieser lokalen Zertifizierungsstelle signierten Zertifikaten.

Auf diese Weise kann die IT-Abteilung, die Ihre lokale Zertifizierungsstelle verwaltet, ein falsches Zertifikat für google.com ausstellen und signieren, und Ihr Browser vertraut darauf, aber ... Hier sind zwei technische Details, die Sie kennen müssen.

Wenn Sie sich httpsdirekt mit einer Domäne verbinden, antworten Webserver mit einem öffentlichen Zertifikat, das Informationen enthält, die dieses Zertifikat signiert haben, und der Browser sucht in seinem Zertifikatsspeicher nach einer Zertifizierungsstelle, die das Zertifikat des Webservers signiert hat Leute, die versuchen, google.com zu fälschen, die eine gefälschte Kopie von google.com als eigenen Webserver einrichten und den DNS-Eintrag überschreiben sollten, der auf die gefälschte Website verweist, die vorgibt, google.com zu sein

Aber in der Realität könnte es relativ einfach sein. Es klingt zwar nach unmöglich (oder schwer, das zu tun), aber ich sollte Sie darauf hinweisen, dass es nicht zu schwierig ist, dies zu tun. Dies ist in vielen Unternehmen üblich, den httpsVerkehr aus verschiedenen Gründen zu beobachten / abzufangen (Filtern, Überwachen und Protokollieren). durch Verwendung eines transparenten (oder mit Autorisierung) HTTP-Proxy.

Wenn Sie dem Zertifikatsspeicher eine lokale Zertifizierungsstelle hinzugefügt haben, kann Ihr Proxy, wenn Ihr Unternehmen HTTP-Proxy verwendet, im Handumdrehen gefälschte Zertifikate für beliebige httpsVerbindungen generieren und Ihrem Browser zuführen, und Ihr Browser vertraut solchen gefälschten Zertifikaten (wie zuvor beschrieben) an . Ein Proxy auf seiner Seite kann solche Verbindungen entschlüsseln, da er seine eigenen privaten Schlüssel für alle ausgestellten Zertifikate zum Filtern, Überwachen, Protokollieren entschlüsselt. Falls die Verbindung den Proxy-Filter umgeht, fragt der Proxy-Server den eigentlichen Standort als Client selbst und verschlüsselt ihn anschließend erneut antworten und zum ursprünglichen Ziel zurückkehren (oder es kann sich entscheiden, eine falsche Timeout-Verbindung zu spielen, wenn einige Regeln dies erfordern).

Was ich Ihnen empfehlen kann, wenn Sie nicht Gegenstand der httpsFilterung sein sollen - richten Sie eine virtuelle Maschine (z. B. VirtualBox) mit einem Betriebssystem ein, in dem Sie sich wohl fühlen, und fügen Sie Ihre lokale Zertifizierungsstelle hinzu, während die Host-Maschine nicht mit der lokalen Zertifizierungsstelle infiziert ist.
Eine andere Lösung: Sie können verschiedene Profile in Ihrem Browser verwenden (Firefox ist diesbezüglich gut), eines für die Arbeit, das Ihr lokales Zertifizierungsstellenzertifikat enthält, und ein anderes privates Profil, das keine lokalen Zertifizierungsstellen enthält. Auf diese Weise können Sie (tatsächlich Browser) Ereignisse schnell erkennen, wenn Ihr httpsDatenverkehr über einen Proxy gefiltert wird.

Verwandte Probleme