TLS Protokoll - Versionsgeschichte

Thomas.will: /* TLS Handshake Protocol */

2021-07-13T18:37:45Z

TLS Handshake Protocol

Thomas.will: /* = TLS Alert Protocol */

2021-06-11T12:32:46Z

= TLS Alert Protocol

Thomas.will: /* Sicherheit */

2021-06-11T12:29:41Z

Sicherheit

Thomas.will: /* Handshake selbst kann in vier Phasen unterteilt werden */

2021-06-11T12:29:20Z

Handshake selbst kann in vier Phasen unterteilt werden

Thomas.will: /* Handshake selbst kann in vier Phasen unterteilt werden */

2021-06-11T12:22:33Z

Handshake selbst kann in vier Phasen unterteilt werden

Thomas.will: /* Handshake selbst kann in vier Phasen unterteilt werden */

2021-06-11T12:16:19Z

Handshake selbst kann in vier Phasen unterteilt werden

Thomas.will: /* Handshake selbst kann in vier Phasen unterteilt werden */

2021-06-11T12:12:41Z

Handshake selbst kann in vier Phasen unterteilt werden

Thomas.will: /* Handshake selbst kann in vier Phasen unterteilt werden */

2021-06-11T12:12:04Z

Handshake selbst kann in vier Phasen unterteilt werden

Thomas.will: /* Handshake selbst kann in vier Phasen unterteilt werden */

2021-06-11T12:08:17Z

Handshake selbst kann in vier Phasen unterteilt werden

Thomas.will: /* Handshake selbst kann in vier Phasen unterteilt werden */

2021-06-11T12:07:57Z

Handshake selbst kann in vier Phasen unterteilt werden

@@ Zeile 49: / Zeile 49: @@
 = TLS Handshake Protocol =
-[[Datei:tls-31.png|1000px]]
+[[Datei:tls-31.png|1400px]]
 *Baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen
@@ Zeile 84: / Zeile 84: @@
 **zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden.
 **Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden sind verschlüsselt übertragen
 = TLS Change Cipher Spec Protocol =
 *Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht.

@@ Zeile 90: / Zeile 90: @@
 *Protokoll wurde gewählt weil man expliziert keine Record Übertragung wollte.
-== TLS Alert Protocol =
+= TLS Alert Protocol =
-*unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.
+*unterscheidet etwa zwei Dutzend verschiedene Mitteilungen.
 Der Aufbau einer Fehlermeldung lautet wie folgt: ''AlertLevel'' (1 Byte: ''Warning'' = 1, ''Fatal'' = 2) | ''AlertDescription'' (1 Byte: ''close_notify'' = 0, […], ''no_renegotiation'' = 100).
@@ Zeile 157: / Zeile 160: @@
 |}
-=== TLS Application Data Protocol ===
+= TLS Application Data Protocol =
+*Die Anwendungsdaten werden über das Record Protocol
-Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS nicht näher interpretiert.
+*transportiert
 === Berechnung des Master Secrets ===
-Aus dem ''pre-master-secret'' wird in früheren Protokollversionen mit Hilfe der [[Hashfunktion]]en [[SHA-1]] und [[MD5]], in TLS 1.2 mit Hilfe einer durch eine ''Cipher Suite'' spezifizierten Pseudozufallsfunktion das ''Master Secret'' berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das ''Master Secret'' immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.
+=Quelle=

← Nächstältere Version		Version vom 11. Juni 2021, 12:29 Uhr
Zeile 164:		Zeile 164:

	Aus dem ''pre-master-secret'' wird in früheren Protokollversionen mit Hilfe der [[Hashfunktion]]en [[SHA-1]] und [[MD5]], in TLS 1.2 mit Hilfe einer durch eine ''Cipher Suite'' spezifizierten Pseudozufallsfunktion das ''Master Secret'' berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das ''Master Secret'' immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.		Aus dem ''pre-master-secret'' wird in früheren Protokollversionen mit Hilfe der [[Hashfunktion]]en [[SHA-1]] und [[MD5]], in TLS 1.2 mit Hilfe einer durch eine ''Cipher Suite'' spezifizierten Pseudozufallsfunktion das ''Master Secret'' berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das ''Master Secret'' immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.
−
−	~~== Sicherheit ==~~
−
−	~~Auf SSL und TLS sind jeweils eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben.<ref name="RFC7457" /> Die folgende Liste stellt einen Teil der bekannten Angriffe dar.~~
−
−	~~=== Padding-Oracle-Angriffe ===~~
−
−	Der Kryptologe [[Serge Vaudenay]] entdeckte 2002, dass ein [[Man-in-the-Middle-Angriff\|Man-in-the-Middle-Angreifer]] aus dem [[Padding (Informatik)\|Padding]] einer mit dem [[Cipher Block Chaining Mode]] (CBC) verschlüsselten Nachricht Informationen erhalten kann, die zur Entschlüsselung der Nachricht genutzt werden können. Durch gezielte Manipulation einer verschlüsselten Nachricht lernt der Angreifer, ob der Server ein gültiges Padding meldet und damit ein Teil des Klartexts richtig erraten wurde.<ref name="Vaudenay2002" />
−
−	Als Schutzmaßnahme sollte der Server ungültige Nachrichten verwerfen, ohne dabei zu offenbaren, ob das Padding oder die Nachrichtenauthentizität ungültig war. Allerdings kann ein Angreifer diese Information auch durch eine Analyse der Antwortzeiten herleiten (Timing-Angriff). Betroffen sind SSL, TLS bis Version 1.2 und DTLS, sofern eine [[Cipher Suite]] mit CBC verwendet wird. Cipher Suites mit [[Authenticated Encryption]] sind nicht betroffen.<ref name="AlFardan2013" />
−
−	Im Oktober 2014 demonstrierten Sicherheitsforscher den [[Poodle\|POODLE-Angriff]] (''Padding Oracle On Downgraded Legacy Encryption''), mit dem ein Angreifer ein Versions-Downgrade einer TLS-Verbindung erzwingt, um einen Padding-Oracle-Angriff gegen SSL 3.0 durchzuführen. Zwecks Kompatibilität wurde SSL 3.0 trotz zu dem Zeitpunkt bekannter Sicherheitsschwächen noch von Webbrowsern und anderen Implementierungen unterstützt. Im Nachgang hat die [[Internet Engineering Task Force]] SSL 3.0 als überholt gekennzeichnet<ref name="RFC7568" /> und ein Verfahren zum Schutz vor Downgrade-Angriffen auf TLS spezifiziert.<ref name="RFC7507" />

@@ Zeile 78: / Zeile 78: @@
 ***Wenn Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt
 ***sind die Voraussetzungen für Perfect Forward Secrecy erfüllt.
-Nach der Übertragung des ''pre-master-secrets''  identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen ''CertificateRequest'' geschickt hat. Dazu schickt der Client per ''Certificate'' das Client-Zertifikat, gefolgt von einem ''CertificateVerify.'' Die ''CertificateVerify'' Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten. Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt. Ab hier ist dem Server also bekannt, mit wem er kommuniziert.
+== TLS Alert Protocol =
-*Diese Phase schließt den Handshake ab. Aus dem vorhandenen ''pre-master-secret'' kann das ''master secret'' abgeleitet werden, das einen einmaligen [[Sitzungsschlüssel]] ({{enS|session key}}) darstellt. Aus dem ''master secret'' werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. Falls sich der Server nicht im Schritt 2 via ''CertificateVerify'' authentisiert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert.
+*unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.
 Der Aufbau einer Fehlermeldung lautet wie folgt: ''AlertLevel'' (1 Byte: ''Warning'' = 1, ''Fatal'' = 2) | ''AlertDescription'' (1 Byte: ''close_notify'' = 0, […], ''no_renegotiation'' = 100).

@@ Zeile 71: / Zeile 71: @@
 **Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab.
 *Das zuvor erhaltene Server-Zertifikat enthält den öffentlichen Schlüssel des Servers
-**Wird eine Cipher Suite mit RSA-Schlüsselaustausch verwendet (siehe Abbildung), so wird das vom Client generierte ''pre-master-secret'' mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch der [[Diffie-Hellman-Schlüsselaustausch]] verwendet werden, um ein gemeinsames ''pre-master-secret'' zu generieren. Werden die Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt, sind die Voraussetzungen für [[Perfect Forward Secrecy]] erfüllt. Nach der Übertragung des ''pre-master-secrets''  identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen ''CertificateRequest'' geschickt hat. Dazu schickt der Client per ''Certificate'' das Client-Zertifikat, gefolgt von einem ''CertificateVerify.'' Die ''CertificateVerify'' Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten. Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt. Ab hier ist dem Server also bekannt, mit wem er kommuniziert.
+**Wird eine Cipher Suite mit RSA-Schlüsselaustausch verwendet
 *Diese Phase schließt den Handshake ab. Aus dem vorhandenen ''pre-master-secret'' kann das ''master secret'' abgeleitet werden, das einen einmaligen [[Sitzungsschlüssel]] ({{enS|session key}}) darstellt. Aus dem ''master secret'' werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. Falls sich der Server nicht im Schritt 2 via ''CertificateVerify'' authentisiert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert.

@@ Zeile 69: / Zeile 69: @@
 **CertificateVerify'' Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten.
 **Server beweist, dass er einen Secret-Key besitzt, der zu dem auf dem Server-Zertifikat enthaltenen passt.
-*Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab. Außerdem kann der Server optional per ''CertificateRequest'' ein Zertifikat zur Client-Authentifizierung anfordern. Diese Phase darf nur weggelassen werden, wenn eine anonyme Cipher Suite ohne Authentifizierung verwendet wird.
+**Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab.
 *Das zuvor erhaltene Server-Zertifikat enthält den [[Asymmetrisches Kryptosystem|öffentlichen Schlüssel]] des Servers. Wird eine [[Cipher Suite]] mit [[RSA-Kryptosystem|RSA]]-Schlüsselaustausch verwendet (siehe Abbildung), so wird das vom Client generierte ''pre-master-secret'' mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch der [[Diffie-Hellman-Schlüsselaustausch]] verwendet werden, um ein gemeinsames ''pre-master-secret'' zu generieren. Werden die Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt, sind die Voraussetzungen für [[Perfect Forward Secrecy]] erfüllt. Nach der Übertragung des ''pre-master-secrets''  identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen ''CertificateRequest'' geschickt hat. Dazu schickt der Client per ''Certificate'' das Client-Zertifikat, gefolgt von einem ''CertificateVerify.'' Die ''CertificateVerify'' Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten. Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt. Ab hier ist dem Server also bekannt, mit wem er kommuniziert.
 *Diese Phase schließt den Handshake ab. Aus dem vorhandenen ''pre-master-secret'' kann das ''master secret'' abgeleitet werden, das einen einmaligen [[Sitzungsschlüssel]] ({{enS|session key}}) darstellt. Aus dem ''master secret'' werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. Falls sich der Server nicht im Schritt 2 via ''CertificateVerify'' authentisiert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert.

@@ Zeile 65: / Zeile 65: @@
 ** Optional den gewünschten FQDN für die Unterstützung von Server Name Indication
 ** in der TLS 1.3 Version (mit Diffie-Hellman-Schlüsselaustausch) werden die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
-*Der Server identifiziert sich gegenüber dem Client. Hierzu wird per C''ertificate'' ein [[X.509]]v3-[[Digitales Zertifikat|Zertifikat]]  an den Client geschickt, gefolgt von einem ''CertificateVerify'' (in einigen TLS Versionen). Die C''ertificateVerify'' Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten. Damit beweist der Server, dass er einen [[Asymmetrische Verschlüsselung|Secret-Key]] besitzt, der zu dem auf dem Server-Zertifikat enthaltenen [[Public-Key-Kryptografie|Public-Key]] passt. Der Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab. Außerdem kann der Server optional per ''CertificateRequest'' ein Zertifikat zur Client-Authentifizierung anfordern. Diese Phase darf nur weggelassen werden, wenn eine anonyme Cipher Suite ohne Authentifizierung verwendet wird.
+*Der Server identifiziert sich gegenüber dem Client.
 *Das zuvor erhaltene Server-Zertifikat enthält den [[Asymmetrisches Kryptosystem|öffentlichen Schlüssel]] des Servers. Wird eine [[Cipher Suite]] mit [[RSA-Kryptosystem|RSA]]-Schlüsselaustausch verwendet (siehe Abbildung), so wird das vom Client generierte ''pre-master-secret'' mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch der [[Diffie-Hellman-Schlüsselaustausch]] verwendet werden, um ein gemeinsames ''pre-master-secret'' zu generieren. Werden die Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt, sind die Voraussetzungen für [[Perfect Forward Secrecy]] erfüllt. Nach der Übertragung des ''pre-master-secrets''  identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen ''CertificateRequest'' geschickt hat. Dazu schickt der Client per ''Certificate'' das Client-Zertifikat, gefolgt von einem ''CertificateVerify.'' Die ''CertificateVerify'' Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten. Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt. Ab hier ist dem Server also bekannt, mit wem er kommuniziert.
 *Diese Phase schließt den Handshake ab. Aus dem vorhandenen ''pre-master-secret'' kann das ''master secret'' abgeleitet werden, das einen einmaligen [[Sitzungsschlüssel]] ({{enS|session key}}) darstellt. Aus dem ''master secret'' werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. Falls sich der Server nicht im Schritt 2 via ''CertificateVerify'' authentisiert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert.

@@ Zeile 64: / Zeile 64: @@
 ** die zu verwendende Cipher Suite (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung)
 ** Optional den gewünschten FQDN für die Unterstützung von Server Name Indication
-** in der TLS 1.3 Version (mit [[Diffie-Hellman-Schlüsselaustausch]]) werden hier auch schon die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
+** in der TLS 1.3 Version (mit Diffie-Hellman-Schlüsselaustausch) werden die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
-# Der Server identifiziert sich gegenüber dem Client. Hierzu wird per C''ertificate'' ein [[X.509]]v3-[[Digitales Zertifikat|Zertifikat]]  an den Client geschickt, gefolgt von einem ''CertificateVerify'' (in einigen TLS Versionen). Die C''ertificateVerify'' Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten. Damit beweist der Server, dass er einen [[Asymmetrische Verschlüsselung|Secret-Key]] besitzt, der zu dem auf dem Server-Zertifikat enthaltenen [[Public-Key-Kryptografie|Public-Key]] passt. Der Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab. Außerdem kann der Server optional per ''CertificateRequest'' ein Zertifikat zur Client-Authentifizierung anfordern. Diese Phase darf nur weggelassen werden, wenn eine anonyme Cipher Suite ohne Authentifizierung verwendet wird.
+*Der Server identifiziert sich gegenüber dem Client. Hierzu wird per C''ertificate'' ein [[X.509]]v3-[[Digitales Zertifikat|Zertifikat]]  an den Client geschickt, gefolgt von einem ''CertificateVerify'' (in einigen TLS Versionen). Die C''ertificateVerify'' Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten. Damit beweist der Server, dass er einen [[Asymmetrische Verschlüsselung|Secret-Key]] besitzt, der zu dem auf dem Server-Zertifikat enthaltenen [[Public-Key-Kryptografie|Public-Key]] passt. Der Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab. Außerdem kann der Server optional per ''CertificateRequest'' ein Zertifikat zur Client-Authentifizierung anfordern. Diese Phase darf nur weggelassen werden, wenn eine anonyme Cipher Suite ohne Authentifizierung verwendet wird.
 # Das zuvor erhaltene Server-Zertifikat enthält den [[Asymmetrisches Kryptosystem|öffentlichen Schlüssel]] des Servers. Wird eine [[Cipher Suite]] mit [[RSA-Kryptosystem|RSA]]-Schlüsselaustausch verwendet (siehe Abbildung), so wird das vom Client generierte ''pre-master-secret'' mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch der [[Diffie-Hellman-Schlüsselaustausch]] verwendet werden, um ein gemeinsames ''pre-master-secret'' zu generieren. Werden die Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt, sind die Voraussetzungen für [[Perfect Forward Secrecy]] erfüllt. Nach der Übertragung des ''pre-master-secrets''  identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen ''CertificateRequest'' geschickt hat. Dazu schickt der Client per ''Certificate'' das Client-Zertifikat, gefolgt von einem ''CertificateVerify.'' Die ''CertificateVerify'' Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten. Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt. Ab hier ist dem Server also bekannt, mit wem er kommuniziert.
 # Diese Phase schließt den Handshake ab. Aus dem vorhandenen ''pre-master-secret'' kann das ''master secret'' abgeleitet werden, das einen einmaligen [[Sitzungsschlüssel]] ({{enS|session key}}) darstellt. Aus dem ''master secret'' werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. Falls sich der Server nicht im Schritt 2 via ''CertificateVerify'' authentisiert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert.