it-swarm.com.de

Korrespondenz mit SSL-Zertifikaten und Cipher Suites

Ich habe etwas über das SSL/TLS-Protokoll gelernt (von https://tools.ietf.org/html/rfc5246 ) und habe einige konzeptionelle Fragen zum Protokoll.

  1. Der Client und der Server tauschen "Hallo" -Nachrichten aus, in denen sie die SSL/TLS-Version und die Cipher Suites auswählen. Insbesondere schlägt der Client eine Liste von Chiffresuiten vor und der Server wählt eine aus (Wenn der Server nichts auswählt, schlägt der Handshake fehl). Wählt der Server nun die Verschlüsselungssuite aus, die den im Zertifikat verwendeten entspricht?

    Zum Beispiel: Ausführen von openssl x509 -in <server_cert>.pem -text -noout gibt Ihnen Informationen zum Serverzertifikat. Auf einem Beispielzertifikat sehe ich, dass der Public-Key-Algorithmus rsaEncryption (2048bit) und der Signaturalgorithmus sha256WithRSAEncryption ist. Bestimmt dies nicht bereits einen Teil der im Handshake verwendeten Chiffresuite?

  2. Nehmen wir an, Server und Client vereinbaren eine Verschlüsselungssuite. Jetzt sehe ich auch, dass Clients später im Handshake auch ein Zertifikat vorlegen können. Bedeutet das, dass die Chiffren auf dem Client-Zertifikat mit der ausgewählten Chiffresuite kompatibel sein müssen?

    (Ähnliche Frage, beantwortet aber nicht, was ich will: Auswahl von Chiffresuiten für HTTPS )

25
iart

Für das Serverzertifikat: Die Verschlüsselungssuite gibt die Art des Schlüsselaustauschs an, die vom Schlüsseltyp des Serverzertifikats abhängt. Sie haben im Grunde Folgendes:

  • Bei TLS_RSA_ * -Cipher-Suites verwendet der Schlüsselaustausch die Verschlüsselung eines vom Client ausgewählten Zufallswerts mit dem öffentlichen RSA-Schlüssel des Servers. Daher muss der öffentliche Schlüssel des Servers vom Typ RSA sein und für die Verschlüsselung geeignet sein (das Serverzertifikat darf keinen Key Usage enthalten) Erweiterung mit der Aufschrift "Nur Signatur").

  • Für TLS_DHE_RSA_ * -Cipher-Suites verwendet der Schlüsselaustausch einen kurzlebigen Diffie-Hellman, und der Server signiert seinen Teil des DH-Schlüsselaustauschs mit seinem RSA-Schlüssel. Der öffentliche Schlüssel des Servers muss also vom Typ RSA sein und für Signaturen geeignet sein (auch hier darf das Zertifikat die Schlüsselverwendung nicht nur auf die Verschlüsselung beschränken).

  • Die Verschlüsselungssuiten TLS_DHE_DSS_ * und TLS_DHE_ECDSA_ * verwenden einen kurzlebigen Diffie-Hellman-Schlüsselaustausch, und der Serverschlüssel muss vom Typ DSA bzw. EC sein und für Signaturen geeignet sein.

  • TLS_ECDHE_ * Cipher Suites ähneln TLS_DHE_ * Cipher Suites, außer dass der Diffie-Hellman-Schlüsselaustausch eine elliptische Kurvenvariante ist. Die Bedingungen auf dem Serverzertifikat bleiben unverändert.

  • Die Verschlüsselungssuiten TLS_DH_ * und TLS_ECDH_ * sind unterschiedlich (beachten Sie das Fehlen von 'E' nach dem 'DH'). Für diese Suites enthält das Serverzertifikat direkt einen öffentlichen Diffie-Hellman-Schlüssel (oder eine elliptische Kurvenvariante davon), und die Verschlüsselungssuite qualifiziert dann den Algorithmus, der von der ausstellenden Zertifizierungsstelle zum Signieren des Zertifikats verwendet wird. Zum Beispiel bedeutet TLS_DH_RSA_ * "Server hat einen öffentlichen DH-Schlüssel in einem Zertifikat gespeichert, das von einer Zertifizierungsstelle mit RSA signiert wurde". Dies ist der einzige Fall, in dem der Signaturtyp auf dem Zertifikat in irgendeiner Beziehung zur Verschlüsselungssuite steht. Da in der Praxis niemand diese Art von Zertifikat verwendet, kann dieser Fall vernachlässigt werden.

Für das Client-Zertifikat: Der Client legt ein Zertifikat vor, wenn der Server danach fragt. Der Client-Zertifikatstyp hat keinerlei Beziehung zur Cipher Suite (mit Ausnahme des äußerst seltenen Falls statischer DH-Zertifikate, aber ich habe noch nie gesehen, dass dies in der Praxis verwendet wird). Das Client-Zertifikat muss für Signaturen geeignet sein. Als Teil der Handshake-Nachricht, die ein Client-Zertifikat anfordert, sendet der Server einige Informationen zu den unterstützten Algorithmen (siehe der Standard ). Tatsächlich erweitert TLS 1.2 diesen Mechanismus weiter, indem es eine flexible Liste der unterstützten Algorithmus- und Hash-Funktionskombinationen bereitstellt.

24
Thomas Pornin