Hinweis: Ich habe meine ursprüngliche Antwort sehr hastig geschrieben, aber seitdem hat sich dies zu einer ziemlich beliebten Frage / Antwort entwickelt. Deshalb habe ich sie ein wenig erweitert und präzisiert.
TLS-Funktionen
"SSL" ist der Name, der am häufigsten verwendet wird, um auf dieses Protokoll zu verweisen. SSL bezieht sich jedoch speziell auf das proprietäre Protokoll, das Netscape Mitte der 90er Jahre entwickelt hat. "TLS" ist ein IETF-Standard, der auf SSL basiert, daher werde ich TLS in meiner Antwort verwenden. Heutzutage besteht die Wahrscheinlichkeit, dass fast alle Ihre sicheren Verbindungen im Web tatsächlich TLS und nicht SSL verwenden.
TLS verfügt über mehrere Funktionen:
- Verschlüsseln Sie die Daten Ihrer Anwendungsschicht. (In Ihrem Fall ist das Protokoll der Anwendungsschicht HTTP.)
- Authentifizieren Sie den Server beim Client.
- Authentifizieren Sie den Client beim Server.
# 1 und # 2 sind sehr häufig. # 3 ist weniger verbreitet. Sie scheinen sich auf # 2 zu konzentrieren, also werde ich diesen Teil erklären.
Authentifizierung
Ein Server authentifiziert sich bei einem Client mithilfe eines Zertifikats. Ein Zertifikat ist ein Datenblock [1], der Informationen zu einer Website enthält:
- Domainname
- Öffentlicher Schlüssel
- Das Unternehmen, dem es gehört
- Als es ausgestellt wurde
- Wenn es abläuft
- Wer hat es ausgestellt?
- Etc.
Sie können Vertraulichkeit erreichen (Nr. 1 oben), indem Sie den im Zertifikat enthaltenen öffentlichen Schlüssel verwenden, um Nachrichten zu verschlüsseln, die nur mit dem entsprechenden privaten Schlüssel entschlüsselt werden können, der sicher auf diesem Server gespeichert werden sollte. [2] Nennen wir dieses Schlüsselpaar KP1, damit wir später nicht verwirrt werden. Sie können auch überprüfen, ob der Domainname auf dem Zertifikat mit der Site übereinstimmt, die Sie besuchen (Nr. 2 oben).
Was aber, wenn ein Gegner Pakete ändern kann, die an und vom Server gesendet werden, und wenn dieser Gegner das Ihnen vorgelegte Zertifikat ändert und seinen eigenen öffentlichen Schlüssel einfügt oder andere wichtige Details ändert? In diesem Fall könnte der Gegner alle Nachrichten abfangen und ändern, von denen Sie glaubten, dass sie sicher verschlüsselt sind.
Um genau diesen Angriff zu verhindern, wird das Zertifikat vom privaten Schlüssel eines anderen kryptografisch signiert, sodass die Signatur von jedem überprüft werden kann, der über den entsprechenden öffentlichen Schlüssel verfügt. Nennen wir dieses Schlüsselpaar KP2, um zu verdeutlichen, dass dies nicht dieselben Schlüssel sind, die der Server verwendet.
Zertifizierungsstellen
Wer hat KP2 erstellt? Wer hat das Zertifikat unterschrieben?
Ein bisschen zu stark vereinfachen, eine Zertifizierungsstelle vereinfacht KP2 und verkauft den Dienst, ihren privaten Schlüssel zum Signieren von Zertifikaten für andere Organisationen zu verwenden. Zum Beispiel erstelle ich ein Zertifikat und bezahle eine Firma wie Verisign, um es mit ihrem privaten Schlüssel zu signieren. [3] Da niemand außer Verisign Zugriff auf diesen privaten Schlüssel hat, kann keiner von uns diese Signatur fälschen.
Und wie würde ich persönlich den öffentlichen Schlüssel in KP2 erhalten, um diese Signatur zu überprüfen?
Nun, wir haben bereits gesehen, dass ein Zertifikat einen öffentlichen Schlüssel enthalten kann - und Informatiker lieben die Rekursion - warum also nicht den öffentlichen KP2-Schlüssel in ein Zertifikat einfügen und auf diese Weise verteilen? Das klingt zunächst etwas verrückt, aber genau so funktioniert es. In Fortsetzung des Verisign-Beispiels erstellt Verisign ein Zertifikat, das Informationen darüber enthält, wer sie sind, welche Arten von Dingen sie signieren dürfen (andere Zertifikate) und ihren öffentlichen Schlüssel.
Wenn ich jetzt eine Kopie dieses Verisign-Zertifikats habe, kann ich damit die Signatur auf dem Serverzertifikat für die Website überprüfen, die ich besuchen möchte. Einfach richtig?!
Na ja, nicht so schnell. Ich musste das Verisign-Zertifikat von irgendwoher bekommen . Was ist, wenn jemand das Verisign-Zertifikat fälscht und dort seinen eigenen öffentlichen Schlüssel ablegt? Dann können sie die Signatur auf dem Zertifikat des Servers fälschen, und wir sind wieder da, wo wir angefangen haben: ein Man-in-the-Middle-Angriff.
Zertifikatsketten
Wenn wir weiterhin rekursiv denken, könnten wir natürlich ein drittes Zertifikat und ein drittes Schlüsselpaar (KP3) einführen und damit das Verisign-Zertifikat signieren. Wir nennen dies eine Zertifikatskette: Jedes Zertifikat in der Kette wird verwendet, um das nächste Zertifikat zu überprüfen. Hoffentlich können Sie bereits sehen, dass dieser rekursive Ansatz nur aus Schildkröten / Zertifikaten besteht. Wo hört es auf?
Da wir nicht unendlich viele Zertifikate erstellen können, muss die Zertifikatskette offensichtlich irgendwo anhalten , und dazu wird ein Zertifikat in die Kette aufgenommen, das selbst signiert ist .
Ich werde einen Moment innehalten, während Sie die Stücke von Hirnsubstanz von Ihrem explodierenden Kopf aufheben. Selbstsigniert?!
Ja, am Ende der Zertifikatskette (auch als "Root" bezeichnet) befindet sich ein Zertifikat, das sein eigenes Schlüsselpaar verwendet, um sich selbst zu signieren. Dies beseitigt das Problem der unendlichen Rekursion, behebt jedoch nicht das Authentifizierungsproblem. Jeder kann ein selbstsigniertes Zertifikat erstellen, auf dem etwas steht, genauso wie ich ein gefälschtes Princeton-Diplom erstellen kann, das besagt, dass ich ein dreifaches Hauptfach in Politik, theoretischer Physik und angewandter Arschtritt habe und dann unten meinen eigenen Namen unterschreibe.
Die [etwas nicht aufregende] Lösung für dieses Problem besteht darin, nur einige selbstsignierte Zertifikate auszuwählen, denen Sie ausdrücklich vertrauen. Zum Beispiel könnte ich sagen: "Ich vertraue diesem selbstsignierten Verisign-Zertifikat."
Mit diesem expliziten Vertrauen kann ich jetzt die gesamte Zertifikatskette validieren. Egal wie viele Zertifikate sich in der Kette befinden, ich kann jede Signatur bis zum Stamm validieren. Wenn ich zum Stammverzeichnis komme, kann ich überprüfen, ob dieses Stammzertifikat eines ist, dem ich ausdrücklich vertraue. Wenn ja, dann kann ich der gesamten Kette vertrauen.
Verliehenes Vertrauen
Die Authentifizierung in TLS verwendet ein System des verliehenen Vertrauens . Wenn ich einen Automechaniker einstellen möchte, kann ich keinem zufälligen Mechaniker vertrauen, den ich finde. Aber vielleicht bürgt mein Freund für einen bestimmten Mechaniker. Da ich meinem Freund vertraue, kann ich diesem Mechaniker vertrauen.
Wenn du einen Computer kaufst oder einen Browser herunterlädst, werden einige hundert Stammzertifikate mitgeliefert, denen er ausdrücklich vertraut. [4] Die Unternehmen, die diese Zertifikate besitzen und betreiben, können dieses Vertrauen durch die Unterzeichnung ihrer Zertifikate anderen Organisationen verleihen.
Dies ist alles andere als ein perfektes System. Manchmal stellt eine Zertifizierungsstelle möglicherweise fälschlicherweise ein Zertifikat aus. In diesen Fällen muss das Zertifikat möglicherweise widerrufen werden. Der Widerruf ist schwierig, da das ausgestellte Zertifikat immer kryptografisch korrekt ist. Ein Out-of-Band-Protokoll ist erforderlich, um herauszufinden, welche zuvor gültigen Zertifikate widerrufen wurden. In der Praxis sind einige dieser Protokolle nicht sehr sicher, und viele Browser überprüfen sie sowieso nicht.
Manchmal ist eine gesamte Zertifizierungsstelle gefährdet. Wenn Sie beispielsweise in Verisign einbrechen und den Root-Signaturschlüssel stehlen, können Sie jedes Zertifikat der Welt fälschen . Beachten Sie, dass dies nicht nur Verisign-Kunden betrifft: Auch wenn mein Zertifikat von Thawte (einem Konkurrenten von Verisign) signiert ist, spielt dies keine Rolle. Mein Zertifikat kann weiterhin mit dem kompromittierten Signaturschlüssel von Verisign gefälscht werden.
Das ist nicht nur theoretisch. Es ist in freier Wildbahn passiert. DigiNotar wurde bekanntermaßen gehackt und ging anschließend bankrott. Comodo wurde ebenfalls gehackt , aber unerklärlicherweise bleiben sie bis heute im Geschäft.
Selbst wenn Zertifizierungsstellen nicht direkt gefährdet sind, gibt es in diesem System andere Bedrohungen. Beispielsweise zwingt eine Regierung eine Zertifizierungsstelle zur Unterzeichnung eines gefälschten Zertifikats. Ihr Arbeitgeber kann ein eigenes CA-Zertifikat auf Ihrem Mitarbeitercomputer installieren. In diesen verschiedenen Fällen ist der Datenverkehr, von dem Sie erwarten, dass er "sicher" ist, für die Organisation, die dieses Zertifikat kontrolliert, tatsächlich vollständig sichtbar / änderbar.
Einige Ersetzungen wurden vorgeschlagen, einschließlich Konvergenz , TACK und DANE .
Endnoten
[1] TLS-Zertifikatdaten werden gemäß dem X.509-Standard formatiert . X.509 basiert auf ASN.1 ("Abstract Syntax Notation # 1"), was bedeutet, dass es sich nicht um ein binäres Datenformat handelt. Daher muss X.509 in ein Binärformat codiert werden. DER und PEM sind die beiden häufigsten Codierungen, die ich kenne.
[2] In der Praxis wechselt das Protokoll tatsächlich zu einer symmetrischen Verschlüsselung, aber das ist ein Detail, das für Ihre Frage nicht relevant ist.
[3] Vermutlich überprüft die Zertifizierungsstelle tatsächlich, wer Sie sind, bevor Sie Ihr Zertifikat unterschreiben. Wenn sie das nicht taten, konnte ich einfach ein Zertifikat für google.com erstellen und eine Zertifizierungsstelle bitten, es zu unterschreiben. Mit diesem Zertifikat konnte ich jede "sichere" Verbindung zu google.com in der Mitte managen. Daher ist der Validierungsschritt ein sehr wichtiger Faktor beim Betrieb einer Zertifizierungsstelle. Leider ist nicht sehr klar, wie streng dieser Validierungsprozess bei Hunderten von Zertifizierungsstellen auf der ganzen Welt ist.
[4] Siehe Mozillas Liste vertrauenswürdiger Zertifizierungsstellen .
