Wie funktioniert der SSL-Handshake/das SSL-Protokoll, wenn der Client bereits über ein Serverzertifikat verfügt?

Question

Meine Erfahrung mit dem SSL/TLS-Protokoll und der OpenSSL-Bibliothek ist sehr begrenzt. Ich habe im Wesentlichen erst diese Woche damit begonnen, mich damit zu beschäftigen, aber ich bin stolz auf die Menge an Wissen, die ich bis jetzt gelernt habe.

Ich habe allerdings eine Frage, auf die ich noch keine Antwort gefunden habe. Ich habe versucht, sie zu googeln und in anderen mir zur Verfügung stehenden Ressourcen zu suchen, aber es scheint, dass ich nicht weiß, wie ich meine Frage richtig stellen soll. Es geht um das Handshake-Verfahren und was passiert, wenn der Client bereits das Serverzertifikat besitzt?

Ich habe verstanden, dass der erste Teil des Handshakes diese hochrangigen Schritte umfasst:

1. Client sendet Begrüßungsnachricht
2. Server antwortet mit seiner eigenen Hallo-Nachricht
3. Server sendet Zertifikat
4. Client prüft das Server-Zertifikat
5. Server sendet Nachricht, dass die Verhandlung abgeschlossen ist

Ich kann nur nicht herausfinden, wie dieses Verfahren funktionieren soll, wenn der Client bereits das Serverzertifikat besitzt. Ich weiß, dass Sitzungskennungen verwendet werden können, um einen erneuten Handshake durchzuführen, bei dem nur die Begrüßungsnachrichten gesendet werden und dann eine Nachricht, die besagt, dass alle Daten nach dieser Nachricht verschlüsselt werden, wodurch die Schlüsselerzeugung im asymmetrischen Handshake vermieden wird. Die Verwendung dieser Sitzungskennungen scheint mir jedoch keine gute Idee zu sein, da sie im Wesentlichen sehr lange bestehen bleiben müssten, was Sicherheitsprobleme aufwerfen könnte (ich weiß nicht wie, aber es scheint einfach schlecht zu sein, eine sehr lange bestehende Sitzungskennung zu haben. Vielleicht liege ich da falsch). Ich dachte mir, dass das Verhalten ähnlich dem eines Webbrowsers sein könnte, konnte aber keine Informationen dazu finden.

Ich habe mir die OpenSSL-API angeschaut, um einige Nachforschungen anzustellen, und auch dabei sind Fragen offen geblieben. Die API-Methode:

int SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type);

beim Initialisieren/Einrichten aller meiner OpenSSL-Strukturen ließ mich denken, dass dies die Zertifikatsdatei des Servers sein würde, falls sie bereits existiert. Aber ich habe weiter recherchiert und es kann sowohl für Client- als auch für Serveranwendungen verwendet werden. In dem Fall, wo ich ein Client bin und das Serverzertifikat noch nicht habe, würde ich also einfach darauf verzichten, die obige API-Methode zu verwenden, bevor ich die SSL_connect() API aufrufe, um den SSL-Handshake durchzuführen? Ich schätze, wenn dies der Fall wäre, würde ich irgendwie die OpenSSL-APIs verwenden, um das Serverzertifikat ebenfalls zu speichern?

Danke, dass Sie meinen Beitrag gelesen haben. Ich bin dankbar für jede Hilfe/jeden Ratschlag/jede Anregung, die Sie mir geben können. Wenn meine Fragen/Gedanken nicht klar sind, lassen Sie es mich bitte wissen und ich werde versuchen, sie zu klären.

Answer 1

Sie scheinen die Zwischenspeicherung des Zertifikats ("Client hat bereits das Serverzertifikat") mit der Zwischenspeicherung des Verbindungsstatus ("Vermeidung der Schlüsselgenerierung im asymmetrischen Handshake") zu verwechseln.

Das Zwischenspeichern des Serverzertifikats stellt sicherlich kein Sicherheitsproblem dar. Es spielt keine Rolle, wie Sie dieses Zertifikat erhalten, denn es ist eine völlig öffentliche Information; sein Zweck ist es, Ihnen den öffentlichen Schlüssel des Servers zu übermitteln. Die Schlüsselaushandlung funktioniert nur, wenn der Server über den entsprechenden privaten Schlüssel verfügt, unabhängig davon, wie Sie das Zertifikat erhalten haben.

Ich weiß jedoch nicht, ob die OpenSSL-API (oder das SSL-Protokoll) es Ihnen erlaubt, davon auszugehen, dass Sie das Zertifikat des Servers bereits haben und diesen Teil des Handshakes zu überspringen. Wie Sie bereits herausgefunden haben, ist SSL_CTX_use_certificate_file() das, was Sie auf dem Client aufrufen, um das Kunde Zertifikat. Und es ist das, was ein Webserver aufrufen würde, um sein eigenes Serverzertifikat zu identifizieren. Es dient nicht zur Identifizierung des Server-Zertifikats auf dem Client oder umgekehrt.

Die Wiederverwendung einer bestehenden Sitzungs-ID (um die Schlüsselgenerierung ganz zu überspringen) ist ebenfalls sehr sicher. Zumindest ist es nicht schlechter als eine langlebige SSL-Verbindung. Und wenn jemand ein Problem damit entdeckt, wäre das Ergebnis mindestens einen Doktortitel wert.

[Update zur Wiederaufnahme der Sitzungen]

Abschnitt 7.3 von RFC 5246 bietet einen Überblick über den SSL-Handshake, einschließlich des Falls, dass Sie eine Sitzung wieder aufnehmen. Die Wiederaufnahme einer Sitzung bedeutet, dass Sie den Austausch und die Überprüfung von Zertifikaten überspringen und direkt mit der verschlüsselten Sitzung beginnen können, beginnend mit einer ChangeCipherSpec-Nachricht zur Aushandlung des geheimen Schlüssels.

Im Übrigen glaube ich nicht, dass es in der Praxis üblich ist, SSL-Sitzungen wieder aufzunehmen. Der Handshake ist nicht dass langsam, und die Erhaltung des Zustands ist lästig. Soweit ich weiß, verwenden Webbrowser und Server diese Funktion im Allgemeinen nicht; sie führen bei jeder SSL-Verbindung einfach den vollständigen Handshake durch.