Handshake zwischen Client und Server
1)
Das ClientHello liefert dem Server eine Liste der unterstützten Protokollversionen /Varianten, die unterstützten Cipher Suites* in seiner bevorzugten Reihenfolge, eine Liste von Komprimierungsalgorithmen, eine 32 Oktett Zufallszahl, die später für die Berechnung des symmetrischen Schlüssels verwendet wird sowie eine Sitzungs-ID die gleich NULL ist sofern keine vorherige Sitzung bestand.
(2)
Das ServerHello liefert dem Client seine Auswahl der Protokollversion /Variante, die Cipher Suite den Komprimierungsalgorithmus, eine 32 Oktett Zufallszahl, der später für die Berechnung des symmetrischen Schlüssels verwendet wird. War die vom Client übertragene Sitzungs-ID gleich NULL** berechnet der Server dem Client eine Sitzungs-ID. Wenn der Client dem Server aber eine bekannte Sitzungs-ID mitteilt kommt es zu einem reduzierten Handshake. Wenn der Client dem Server eine Sitzungs-ID anbot die ihm nicht bekannt ist, dann sendet der Server ein vollständiges Handshake Ergebnis zurück.
(3)
Zugleich sendet der Server dem Client ein Zertifikat, das den öffentlichen Schlüssel des Servers enthält und dessen Algorithmus wobei der Schlüsselaustauschalgorithmus (Key-Exchange) mit der ausgewählten Cipher Suite übereinstimmen muss. Das Ziel von Punkt 3 ist, dass der Client den öffentlichen Schlüssel des Servers von einer vertrauenswürdigen Quelle bekommt, um weitere Nachrichten verschlüsselt senden zu können.
(4)
Das Server Hello Done beendet die Dialog Sequenz serverseitig und übergibt das Wort dem Client. Optional könnte der Server aber noch ein Client Zertifikat anfordern, diese Methode wird in der Regel nicht eingesetzt.
(5)
Beim ClientKeyExchange berechnet der Client ein Pre-Master-Schlüssel unter Verwendung der zuvor erstellen und ausgetauschten Zufallszahlen. Dieser Pre-Master-Schlüssel wird mit dem öffentlichen Schlüssel des Servers verschlüsselt. Nachdem der Server diese Nachricht empfangen hat, kann der Server diese mit seinem privaten Schlüssel entschlüsseln. Nun ist beiden Seiten der Pre-Master-Schlüssel bekannt und beide berechnen für sich einen Master-Key unter Verwendung des definierten Algorithmus. Ab jetzt wird jeder weitere Sitzungsschlüssel von dem jeweiligen Masterschlüssel abgeleitet.
(6)
Beim ChangeCipherSpec*** werden alle nachfolgenden Daten vom Client aus mit dem ausgehandelten Verschlüsselungsprotokoll verschlüsselt und enthält den ausgehandelten MAC*.
(7)
Das ClientFinished enthält alle während des Handshakes gesendeten und empfangenen Nachrichten. Diese Nachricht wird mit dem ausgehandelten Verschlüsselungsprotokoll verschlüsselt und mit dem ausgehandelten MAC gehascht. Wenn der Server diese Nachricht mit seinem Sitzungsschlüssel entschlüsseln kann, den Inhalt verifiziert hat dann war dieser Teil des Dialogs erfolgreich. Wenn nicht, dann wird die Sitzung hier beendet und es kommt zu einer Fehlermeldung.
(8)
Beim ChangeCipherSpec werden alle nachfolgenden Daten vom Server aus mit dem ausgehandelten Verschlüsselungsprotokoll verschlüsselt und enthält den ausgehandelten MAC* z.B. SHA384.
(9)
Das ServerFinished enthält alle während des Handshakes gesendeten und empfangenen Nachrichten. Diese Nachricht wird mit dem ausgehandelten Verschlüsselungsprotokoll verschlüsselt und mit dem ausgehandelten MAC gehascht. Wenn der Client diese Nachricht mit seinem Sitzungsschlüssel entschlüsseln kann, den Inhalt verifiziert hat dann war dieser Teil des Dialogs erfolgreich. Wenn nicht, dann wird die Sitzung hier beendet und es kommt zu einer Fehlermeldung.
(10)
HandshakeFinished
*Jede Cipher Suite besteht aus einem Schlüsselaustauschalgorithmus, einem Cipher Algorithmus und einem MAC (Hash) Algorithmus. Message Authentication (MAC) sind Algorithmen die Hashes und Signaturen erzeugen um die Integrität einer Nachricht sicherzustellen.
** NULL Aushandlungen (erster Handshake) sollten abgeschaltet werden, unsicher.
*** ChangeCipherSpec Nachrichten werden verwendet um anzuzeigen, das ab jetzt die Kommunikation von unverschlüsselt zu verschlüsselt wechselt.
Eine CipherSuite (ein Satz kryptografischer Algorithmen) besteht aus verschiedenen Algorithmen (Schlüsselaustausch (KeyExchange), BulkEncryption (Massen Verschlüsselung), Nachrichtenauthentifizierung (Message Authentication) und Protokollen.
Sicherheits-Info:
Im März 2018 wurde bekannt gegeben, dass es seit Anbeginn eine Lücke im Credential Security Support Provider existiert CVE-2018-0886.
Microsoft hat damit angefangen nicht gepatchten Systeme den Zugang via RDP zu untersagen. Aufgebaute RDP- und WinRM- Verbindungen können dazu führen, dass Daten gestohlen oder Malware platziert werden kann.
CredSSP wird zur verschlüsselten Übertragung von Anmeldeinformationen eingesetzt.
Ein Fallback, falls eine Verbindung nicht aufgebaut werden kann, ist die Deaktivierung von NLA auf dem betroffenen Windows Server (nicht zu empfehlen).
NLA erfordert eine Authentifizierung des Nutzers, bevor eine Remote Desktop Session mit dem Server aufgebaut wird.
Wichtig: Alle Systeme müssen sauber gepatcht sein, damit die RDP-Verbindung aufgebaut werden kann!
RDP Anmeldung ausgehandelte Cipher Suite
Handshake zwischen Server und Client