it-swarm.com.de

TLS-RSA gegen TLS-ECDHE-RSA gegen statische DH

Ich verstehe, dass es viele Artikel gibt, die dieses Thema erklären, und bevor ich meine Frage poste, ist dies mein aktuelles Verständnis darüber:

ECDHE-RSA = Der Server generiert zufällig ein DH-Schlüsselpaar, da das Zertifikat nicht über genügend Informationen verfügt, um zur geheimen Generierung des Masters an den Client gesendet zu werden. Der öffentliche DH-Schlüssel wird in einem "Server Key Exchange" -Paket gesendet. Das Geheimnis wird niemals über das Kabel gesendet. Der "RSA" in der Cipher Suite bezieht sich auf die zufällige öffentliche DH-Schlüsselsignatur, nicht jedoch auf die Zertifikatsignatur.

Statischer DH = Der Server verfügt über einen festen öffentlichen DH-Schlüssel im Zertifikat, der vom Client für die gemeinsame geheime Generierung verwendet wird. Das Geheimnis wird niemals über das Kabel gesendet. Da diese Informationen ausreichen, wird die Nachricht zum Austausch des Serverschlüssels nicht benötigt.

RSA = Der Client verwendet den öffentlichen Schlüssel des Servers, um das PMS zu verschlüsseln und an den Server zu senden. Der Server entschlüsselt das PMS und generiert dasselbe PMS. Das Geheimnis wird über den Draht geschickt.

Legen Sie statische DH vorerst beiseite, da sie im Internet nicht häufig verwendet wird - ich kann mit Wireshark keine finden.

Das ist meine Frage:

Ich vergleiche die PCAP zwischen TLS-RSA und TLS-ECDHE-RSA und stelle fest, dass:

  • In dem vom Server vorgelegten Zertifikat enthalten beide einen öffentlichen RSA-Schlüssel (Betreff öffentlicher Schlüssel) und das Zertifikat hat eine RSA-Signatur (Sha256withRSAencryption).

  • Im Paket "Server Key Exchange" für TLS-ECDHE-RSA befindet sich ein DH-Schlüssel mit RSA-Signatur.

Die RSA-Signatur für den "dh-Schlüssel" und das "Zertifikat" wird für Authentifizierungszwecke/digitale Signatur für den Server verwendet, um zu beweisen, wer er zu sein behauptet.

"Öffentlicher RSA-Schlüssel" im Zertifikat für TLS-RSA wird vom Client zum Verschlüsseln des PMS verwendet. Dies ist im Paket "Client Key Exchange" zu sehen. Welche Funktion hat es dann bei TLS-ECDHE-RSA?

5
Nelson Gee

Ich gehe davon aus, dass Sie im Zusammenhang mit TLS, insbesondere TLS-Chiffren, darüber sprechen. Es scheint einige Verwirrung darüber zu geben, was jede Komponente tut. Es ist alles einfacher zu verstehen, wenn Sie das ganze Bild sehen, also hier ist es.

Während eines TLS-Handshakes passieren folgende Dinge: Authentifizierung, Schlüsselaustausch. Die Details dazu hängen von der sogenannten Cipher Suite ab. Hier ist ein Beispiel.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Dies sagt im Grunde das Folgende.

  1. Der Server stellt ein Zertifikat bereit, das einen öffentlichen Schlüssel [~ # ~] rsa [~ # ~] enthält. Dies wird zur Authentifizierung verwendet.
  2. Der Schlüsselaustausch erfolgt mit [~ # ~] ecdhe [~ # ~] .
  3. Die nach dem Schlüsselaustausch verwendete symmetrische Chiffre ist AES-GCM mit einem 128 Bitschlüssel.
  4. Die während des Austauschs zu verwendende PRF (Pseudozufallsfunktion) ist SHA256 (sie kann auch den MAC mit älteren TLS-Versionen anzeigen).

Schauen Sie genau hin und Sie werden sehen, wie all diese in der Chiffresuite dargestellt werden.

Nun wollen wir sehen, was diese bedeuten könnten: ECDHE-RSA , Statische DH , [~ # ~] rsa [~ # ~]

ECDHE-RSA = Server generiert zufällig ein DH-Schlüsselpaar, da das Zertifikat keine ausreichenden Informationen enthält, um es zur Generierung des Master-Geheimnisses an den Client zu senden. Der öffentliche DH-Schlüssel wird im Paket "Server Key Exchange" gesendet. Das Geheimnis wird niemals in der Leitung gesendet. Der "RSA" in der Cipher Suite bezieht sich auf die zufällige öffentliche DH-Schlüsselsignatur, nicht jedoch auf die Zertifikatsignatur

Sie sind hier auf dem richtigen Weg, und jetzt, mit dem Wissen über das ganze Bild, ist es einfacher, dies zu verstehen. Während eines "klassischen" Schlüsselaustauschs wird der öffentliche Schlüssel im Zertifikat (und sein privates Paar) verwendet, um einen symmetrischen Schlüssel zu vereinbaren. Dies führt jedoch zu Problemen, wenn der Schlüssel des Servers jemals kompromittiert wird. Wenn ein privater Schlüssel, der dem öffentlichen Schlüssel im Zertifikat entspricht, jemals gestohlen wird, kann zuvor aufgezeichneter Datenverkehr problemlos entschlüsselt werden.

Dies möchten wir generell vermeiden. Geben Sie Weiterleitungsgeheimnis ein . Das Protokoll bietet die Möglichkeit eines separaten Schlüsselaustauschs, der nicht so stark vom RSA-Schlüsselpaar abhängt. Der normalerweise dafür verwendete Algorithmus heißt Diffie-Hellman .

Damit DH funktioniert, benötigen Sie die sogenannten DH-Parameter, die im Grunde ein Primzahlmodul und ein Generator sind. Diese Parameter sind öffentlich. Diese werden während der Server-Setup-Zeit vorberechnet und während des Schlüsselaustauschs für jeden Client freigegeben. Clients verwenden dann in Zusammenarbeit mit dem Server diese Parameter, um einen Schlüssel zu vereinbaren, ohne ihn tatsächlich über das Kabel zu senden, wie Sie gesagt haben. Hier ist ein tolles Video dazu von der Khan Academy. Der private Schlüssel des DH-Schlüsselpaares ist im Wesentlichen die private Nummer im Video. Während der öffentliche Schlüssel ist, was auf der Leitung gesendet wird.

Zusammenfassend ist ECDHE Ephemeral Elliptic Curve Diffie-Hellman, dh DH über elliptischen Kurven. Der kurzlebige Teil bezieht sich auf die Tatsache, dass jede Verbindung ein DH-Schlüsselpaar verwendet.

Statischer DH = Server hat einen festen öffentlichen DH-Schlüssel im Zertifikat, der vom Client für die geheime Generierung von Freigaben verwendet wird. Das Geheimnis wird niemals in der Leitung gesendet. Da Informationen ausreichen, wird keine Nachricht zum Austausch von Serverschlüsseln benötigt

Statischer DH bezieht sich darauf, dass der Server für jede Clientverbindung dasselbe DH-Schlüsselpaar auswählt (private Nummer im Video). Oder, wie Sie vorgeschlagen haben, kann es in das Zertifikat eingebettet werden. Dies ermöglicht die passive Überwachung von TLS-Verbindungen. Dies deaktiviert im Wesentlichen das Vorwärtsgeheimnis.

RSA = Der Client verwendet den öffentlichen Schlüssel des Servers, um das PMS zu verschlüsseln und an den Server zu senden. Der Server entschlüsselt das PMS und generiert dasselbe PMS. Das Geheimnis wird in der Leitung gesendet

Genau so.

Kommen wir nun zu Ihrer Frage.

"Öffentlicher RSA-Schlüssel" im Zertifikat für TLS-RSA wird vom Client zum Verschlüsseln des PMS verwendet. Es kann am Paket "Client Key Exchange" gesehen werden. Welche Funktion hat es dann bei TLS-ECDHE-RSA?

Dies ist leicht zu beantworten. Wenn es einen expliziten Schlüsselaustauschalgorithmus gibt, wird der Schlüssel im Zertifikat (in diesem Fall der öffentliche RSA-Schlüssel) nur zur Authentifizierung verwendet. Stellen Sie sicher, dass Sie eine Verbindung zu dem Host herstellen, den Sie beabsichtigen, indem Sie die Zertifikatkette überprüfen und sicherstellen, dass der Server den privaten Schlüssel für den öffentlichen Schlüssel des angegebenen Zertifikats enthält. Es signiert auch den öffentlichen DH-Schlüssel, den es an den Client sendet, mit seinem privaten RSA-Schlüssel, den der Client während des Handshakes überprüft.

11
Daniel Szpisjak

"RSA" in der Verschlüsselungssuite bezieht sich auf die zufällige öffentliche DH-Schlüsselsignatur, nicht jedoch auf die Zertifikatsignatur

"RSA" bezieht sich sowohl auf die DH-Schlüsselsignatur als auch auf den öffentlichen Schlüssel des Serverzertifikats.

Die zum Signieren/Überprüfen des öffentlichen DH-Schlüssels verwendeten Schlüssel stammen aus dem Zertifikatsaustausch, oder wir können nicht sicherstellen, dass wir den tatsächlichen öffentlichen Schlüssel des Servers verwenden.

das Zertifikat hat eine RSA-Signatur (Sha256withRSAencryption).

Der Signaturalgorithmus des Zertifikats (Sha256withRSAencryption) liegt beim Aussteller des Serverzertifikats und wird zur Überprüfung des Serverzertifikats verwendet. Es nimmt nicht am eigentlichen Datenaustausch teil und ist hier irrelevant.

Welche Funktion hat es dann bei TLS-ECDHE-RSA?

Wie Sie bereits betont haben, stellt "ECDHE" sicher, dass der symmetrische geheime Schlüssel nicht über das Kabel gesendet wird. Selbst wenn der geheime Schlüssel des Serverzertifikats eines Tages kompromittiert wird, wird der zuvor ausgetauschte geheime Schlüssel nicht entschlüsselt und die zuvor gesendeten Daten bleiben sicher. Es ist als "Vorwärtsgeheimnis" bekannt.

1
DDoSolitary