it-swarm.com.de

Wie funktioniert SSL wirklich?

Wie funktioniert SSL?

Wo ist das Zertifikat auf dem Client (oder Browser?) Und dem Server (oder Webserver?) Installiert?

Wie startet der Vertrauens-/Verschlüsselungs-/Authentifizierungsprozess, wenn Sie die URL in den Browser eingeben und die Seite vom Server abrufen?

Wie erkennt das HTTPS-Protokoll das Zertifikat? Warum kann HTTP nicht mit Zertifikaten arbeiten, wenn es die Zertifikate sind, die die gesamte Vertrauens-/Verschlüsselungs-/Authentifizierungsarbeit leisten?

129
Vicky

Hinweis: Ich habe meine ursprüngliche Antwort sehr hastig geschrieben, aber seitdem hat sich dies zu einer ziemlich beliebten Frage/Antwort entwickelt, sodass ich sie etwas erweitert und präzisiert habe.

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 Mitte der 90er Jahre von Netscape entwickelt wurde. "TLS" ist ein IETF-Standard, der auf SSL basiert, daher werde ich in meiner Antwort TLS verwenden. Heutzutage besteht die Wahrscheinlichkeit, dass fast alle Ihre sicheren Verbindungen im Internet TLS und nicht SSL verwenden.

TLS verfügt über mehrere Funktionen:

  1. Verschlüsseln Sie die Daten Ihrer Anwendungsebene. (In Ihrem Fall ist das Protokoll der Anwendungsschicht HTTP.)
  2. Authentifizieren Sie den Server beim Client.
  3. Authentifizieren Sie den Client beim Server.

Nr. 1 und Nr. 2 sind sehr verbreitet. # 3 ist weniger verbreitet. Sie scheinen sich auf # 2 zu konzentrieren, also erkläre ich diesen Teil.

Authentifizierung

Ein Server authentifiziert sich gegenüber einem Client mithilfe eines Zertifikats. Ein Zertifikat ist ein Datenblock [1], der Informationen zu einer Website enthält:

  • Domain Name
  • Öffentlicher Schlüssel
  • Die Firma, die es besitzt
  • Wann es ausgestellt wurde
  • Wenn es abläuft
  • Wer hat es ausgestellt?
  • Etc.

Du kannst Vertraulichkeit (Nr. 1 oben) erreichen, indem du den im Zertifikat enthaltenen öffentlichen Schlüssel zum Verschlüsseln von Nachrichten verwendest, die nur mit dem entsprechenden privaten Schlüssel entschlüsselt werden können, der auf diesem Server sicher 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 Angreifer Pakete ändern könnte, die an den und vom Server gesendet werden, und wenn dieser Angreifer das Ihnen vorgelegte Zertifikat geändert und seinen eigenen öffentlichen Schlüssel eingefügt oder andere wichtige Details geändert hat? In diesem Fall könnte der Gegner alle Nachrichten abfangen und ändern, die Sie für sicher verschlüsselt hielten.

Um genau diesen Angriff zu verhindern, wird das Zertifikat mit dem privaten Schlüssel einer anderen Person kryptografisch signiert, sodass die Signatur von jeder Person überprüft werden kann, die über den entsprechenden öffentlichen Schlüssel verfügt. Nennen wir dieses Schlüsselpaar KP2, um zu verdeutlichen, dass es sich nicht um dieselben Schlüssel handelt, die der Server verwendet.

Zertifizierungsstellen

Also, wer hat KP2 erschaffen? Wer hat das Zertifikat unterschrieben?

Wenn man es ein bisschen vereinfacht, erstellt eine Zertifizierungsstelle KP2 und sie verkaufen 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?

Wie wir bereits gesehen haben, kann ein Zertifikat einen öffentlichen Schlüssel enthalten - und Informatiker lieben die Rekursion - warum also nicht den öffentlichen Schlüssel KP2 in ein Zertifikat einfügen und auf diese Weise verteilen? Das klingt zunächst etwas verrückt, aber genau so funktioniert es. Weiter mit dem Verisign-Beispiel 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 validieren, die ich besuchen möchte. Einfach richtig?!

Na ja, nicht so schnell. Ich musste das Verisign-Zertifikat von irgendwo bekommen. Was ist, wenn jemand das Verisign-Zertifikat fälscht und dort seinen eigenen öffentlichen Schlüssel einfügt? Dann können sie die Signatur des Serverzertifikats 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 dieses zum Signieren des Verisign-Zertifikats verwenden. Wir nennen dies eine Zertifikatskette: Jedes Zertifikat in der Kette wird verwendet, um das nächste Zertifikat zu verifizieren. Hoffentlich können Sie bereits erkennen, dass es sich bei diesem rekursiven Ansatz nur um Schildkröten/Zertifikate handelt. Wo hört es auf?

Da wir keine unbegrenzte Anzahl von Zertifikaten erstellen können, muss die Zertifikatskette natürlich anhalten irgendwo und dazu muss ein Zertifikat in die Kette aufgenommen werden, das selbstsigniert ist.

Ich werde für einen Moment innehalten, während Sie die Stücke der Gehirnmaterie von Ihrem explodierenden Kopf aufheben. Selbst signiert? !

Ja, am Ende der Zertifikatskette ("root") befindet sich ein Zertifikat, das sein eigenes Schlüsselpaar verwendet, um sich selbst zu signieren. Dadurch wird das Problem der unendlichen Rekursion beseitigt, das Authentifizierungsproblem jedoch nicht behoben. Jeder kann ein selbstsigniertes Zertifikat erstellen, auf dem alles steht, genauso wie ich ein falsches Princeton-Diplom erstellen kann, das besagt, dass ich drei Hauptfächer in Politik, theoretischer Physik und angewandter Kick-Methode habe und dann unten meinen eigenen Namen unterschreibe.

Die [etwas unaufregende] Lösung für dieses Problem besteht darin, einige selbstsignierte Zertifikate auszuwählen, denen Sie ausdrücklich vertrauen. Zum Beispiel könnte ich sagen: "Ich vertraue dieses von Verisign selbst signierte Zertifikat."

Mit diesem ausdrücklichen Vertrauen kann ich jetzt die gesamte Zertifikatskette validieren. Egal wie viele Zertifikate sich in der Kette befinden, ich kann jede Signatur bis zur Wurzel validieren. Wenn ich zum Stammverzeichnis komme, kann ich überprüfen, ob es sich bei diesem Stammzertifikat um ein Zertifikat handelt, dem ich ausdrücklich vertraue. Wenn ja, dann kann ich der gesamten Kette vertrauen.

Übertragenes Vertrauen

Die Authentifizierung in TLS verwendet ein System mit verliehenem Vertrauen. Wenn ich einen Automechaniker beauftragen 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 ein paar hundert Root-Zertifikate mitgeliefert, denen er ausdrücklich vertraut. [4] Die Unternehmen, die diese Zertifikate besitzen und betreiben, können dieses Vertrauen durch Signieren ihrer Zertifikate an andere Organisationen übertragen.

Dies ist alles andere als ein perfektes System. Manchmal kann eine Zertifizierungsstelle fälschlicherweise ein Zertifikat ausstellen. 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 festzustellen, 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 deren Stammsignierungsschlüssel stehlen, können Sie das Zertifikat any weltweit 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 manipulierten 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 aus unerklärlichen Gründen sind sie bis heute im Geschäft.

Auch wenn Zertifizierungsstellen nicht direkt gefährdet sind, birgt dieses System andere Bedrohungen. Beispielsweise zwingt eine Regierung eine Zertifizierungsstelle, ein gefälschtes Zertifikat zu unterzeichnen. Ihr Arbeitgeber installiert möglicherweise ein eigenes CA-Zertifikat auf dem Computer Ihres Mitarbeiters. In diesen verschiedenen Fällen ist der Datenverkehr, von dem Sie erwarten, dass er "sicher" ist, für die Organisation, die dieses Zertifikat kontrolliert, vollständig sichtbar bzw. verä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 not ein binäres Datenformat ist. Daher muss X.509 codiert in ein Binärformat umgewandelt werden. DER und PEM sind die beiden häufigsten mir bekannten Kodierungen.

[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 signieren. Wenn dies nicht der Fall wäre, könnte ich einfach ein Zertifikat für google.com erstellen und eine Zertifizierungsstelle bitten, es zu signieren. Mit diesem Zertifikat konnte ich jede "sichere" Verbindung zu google.com herstellen. Daher ist der Validierungsschritt ein sehr wichtiger Faktor beim Betrieb einer Zertifizierungsstelle. Leider ist nicht klar, wie streng dieser Validierungsprozess bei Hunderten von Zertifizierungsstellen auf der ganzen Welt ist.

[4] Siehe Mozillas Liste der vertrauenswürdigen Zertifizierungsstellen .

137
Mark E. Haase

HTTPS ist eine Kombination aus [~ # ~] http [~ # ~] und SSL (Secure Socket Layer) zur Bereitstellung einer verschlüsselten Kommunikation zwischen Client (Browser) und Webserver (Anwendung wird hier gehostet).

Warum wird es benötigt?

HTTPS verschlüsselt Daten, die über das Netzwerk vom Browser zum Server übertragen werden. Daher kann niemand die Daten während der Übertragung abhören.

Wie wird eine HTTPS-Verbindung zwischen Browser und Webserver hergestellt?

  1. Der Browser versucht, eine Verbindung zu https://payment.com herzustellen.
  2. der Server von payment.com sendet ein Zertifikat an den Browser. Dieses Zertifikat enthält den öffentlichen Schlüssel des payment.com-Servers und einige Hinweise darauf, dass dieser öffentliche Schlüssel tatsächlich zu payment.com gehört.
  3. Der Browser überprüft das Zertifikat, um zu bestätigen, dass es über den richtigen öffentlichen Schlüssel für payment.com verfügt.
  4. Der Browser wählt einen zufälligen neuen symmetrischen Schlüssel K für die Verbindung zum Server payment.com. Es verschlüsselt K unter dem öffentlichen Schlüssel payment.com.
  5. payment.com entschlüsselt K mit seinem privaten Schlüssel. Jetzt kennen sowohl der Browser als auch der Zahlungsserver K, aber niemand anderes.
  6. Immer wenn der Browser etwas an payment.com senden möchte, verschlüsselt er es unter K; Der Server von payment.com entschlüsselt sie nach Erhalt. Immer wenn der Server von payment.com etwas an Ihren Browser senden möchte, verschlüsselt er es unter K.

Dieser Fluss kann durch das folgende Diagramm dargestellt werden: enter image description here

48
sanjay_kv

Ich habe einen kleinen Blog-Beitrag geschrieben, der den Vorgang kurz beschreibt. Schauen Sie doch einfach mal rein.

SSL-Handshake

Ein kleiner Ausschnitt davon ist wie folgt:

"Der Client sendet eine Anfrage über HTTPS an den Server. Der Server sendet eine Kopie seines SSL-Zertifikats + seines öffentlichen Schlüssels. Nachdem die Identität des Servers mit seinem lokalen vertrauenswürdigen CA-Speicher überprüft wurde, generiert der Client einen geheimen Sitzungsschlüssel und verschlüsselt ihn mit dem öffentlichen Schlüssel des Servers Schlüssel und sendet ihn. Der Server entschlüsselt den geheimen Sitzungsschlüssel mit seinem privaten Schlüssel und sendet eine Bestätigung an den Client.

3
Abhishek Jain

Mehaase hat es bereits ausführlich erklärt. Ich werde meine 2 Cent zu dieser Serie hinzufügen. Ich habe viele Blogposts, die sich um SSL-Handshakes und Zertifikate drehen. Während sich das meiste davon um IIS Web-Server dreht, ist der Beitrag für den SSL/TLS-Handshake im Allgemeinen immer noch relevant.

Behandeln Sie nicht [~ # ~] Zertifikate [~ # ~] & [~ # ~] ssl [~ # ~] als ein Thema. Behandle sie als zwei verschiedene Themen und versuche dann herauszufinden, mit wem sie zusammenarbeiten. Dies hilft Ihnen bei der Beantwortung der Frage.

Herstellen von Vertrauen zwischen Kommunikationspartnern über den Zertifikatspeicher

Die SSL/TLS-Kommunikation erfolgt ausschließlich auf Vertrauensbasis. Jeder Computer (Client/Server) im Internet verfügt über eine Liste der von ihm verwalteten Stammzertifizierungsstellen und Zwischenzertifizierungsstellen. Diese werden regelmäßig aktualisiert. Während des SSL-Handshakes wird dies als Referenz verwendet, um Vertrauen herzustellen. Beispielsweise während des SSL-Handshakes, wenn der Client dem Server ein Zertifikat bereitstellt. Der Server versucht zu prüfen, ob die Zertifizierungsstelle, die das Zertifikat ausgestellt hat, in der Liste der Zertifizierungsstellen vorhanden ist. Wenn dies nicht möglich ist, wird angegeben, dass die Zertifikatkettenüberprüfung nicht durchgeführt werden konnte. (Dies ist ein Teil der Antwort. Es wird auch nach [~ # ~] aia [~ # ~] gesucht.) Der Client tut dies auch eine ähnliche Überprüfung für das Serverzertifikat, das es in Server Hello erhält. Unter Windows können Sie die Zertifikatspeicher für Client und Server über PowerShell anzeigen. Führen Sie das Folgende von einer PowerShell-Konsole aus.

PS-Zertifikat:> ls Speicherort: CurrentUser StoreNames: {TrustedPublisher, ClientAuthIssuer, Root, UserDS ...}

Speicherort: LocalMachine StoreNames: {TrustedPublisher, ClientAuthIssuer, Remotedesktop, Stamm ...}

Browser wie Firefox und Opera) verlassen sich nicht auf das zugrunde liegende Betriebssystem für die Zertifikatverwaltung. Sie unterhalten ihre eigenen separaten Zertifikatspeicher.

Der SSL-Handshake verwendet sowohl die symmetrische Kryptografie als auch die Kryptografie mit öffentlichen Schlüsseln. Die Serverauthentifizierung erfolgt standardmäßig. Die Clientauthentifizierung ist optional und hängt davon ab, ob der Serverendpunkt für die Authentifizierung des Clients konfiguriert ist oder nicht. Verweisen Sie auf meinen Blog-Beitrag, da ich dies ausführlich erklärt habe.

Zum Schluss zu dieser Frage

Wie erkennt das HTTPS-Protokoll das Zertifikat? Warum kann HTTP nicht mit Zertifikaten arbeiten, wenn es die Zertifikate sind, die die gesamte Vertrauens-/Verschlüsselungs-/Authentifizierungsarbeit leisten?

Zertifikate ist einfach eine Datei, deren Format durch X.509 Standard definiert ist. Es ist ein elektronisches Dokument, das die Identität einer kommunizierenden Partei nachweist. HTTPS = HTTP + SSL ist ein Protokoll, das die Richtlinien definiert, wie zwei Parteien miteinander kommunizieren sollen.

WEITERE INFORMATIONEN

  • Um Zertifikate zu verstehen, müssen Sie wissen, was Zertifikate sind, und Sie müssen auch über die Zertifikatsverwaltung lesen. Das ist wichtig.
  • Sobald dies verstanden ist, fahren Sie mit TLS/SSL-Handshake fort. Sie können die RFCs dafür verweisen. Aber sie sind das Gerüst, das die Richtlinien definiert. Es gibt mehrere Blogposts, einschließlich meiner, die dies detailliert erklären.

Wenn die oben genannten Aktivitäten ausgeführt werden, verfügen Sie über ein angemessenes Verständnis für Zertifikate und SSL.