Bearbeiten (2018-09-26): Ich habe festgestellt, dass das Deaktivieren von 3DES auf 2012R2 RDP NICHT unterbricht, jedoch auf 2008 R2. Die unterstützten Optionen scheinen sich zwischen den Kerneln zu unterscheiden.
Ich werde meine Antwort von einem TechNet- Thread teilen, aber zuerst BLUF:
Serverfehler-Schlussfolgerung: Höchstwahrscheinlich haben Sie einen anderen Unterschied zwischen den Systemen. Sie stellen eine Verbindung zwischen verschiedenen Betriebssystemversionen her, auf einem System ist FIPS aktiviert und auf dem anderen System nicht, oder es gelten andere Verschlüsselungsbeschränkungen HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. Ich würde auf jeden Fall die SCHANNEL Protokollierung auf dem System ermöglichen , das tut der Arbeit zu bestimmen , welche Chiffre verwendet wird. Würde gerne zurückhören, wenn Sie RDP irgendwie dazu bringen, mit einer alternativen Verschlüsselung zu arbeiten.
Kopie der Post:
Wir haben es geschafft zu arbeiten!
Anscheinend haben 2008 und 2012 Syntaxprobleme und die Version 2008/7 erfordert ein Trailing / 168. 2012 / 8.1 / 10 nicht.
Der Schlüssel für 2008 sieht folgendermaßen aus: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168
Und der Schlüssel für 2012 sieht so aus: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168
Ich kann bestätigen, dass die Verwendung von "Triple DES 168/168" 3DES auf dem System NICHT deaktiviert. Sie können sich dies mit einem Protokollscanner (wie Nessus) oder durch Aktivieren der SCHANNEL-Protokollierung beweisen:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007
Sie haben dann beispielsweise Ereignisse im SYSTEM-Protokoll.
Ein SSL-Client-Handshake wurde erfolgreich abgeschlossen. Die ausgehandelten kryptografischen Parameter lauten wie folgt.
Protokoll: TLS 1.0 CipherSuite: 0x2f Austauschstärke: 1024
Für mich ist das Ergebnis 0xa, das Google als TLS_RSA_WITH_3DES_EDE_CBC_SHA anzeigt.
Wenn ich "Triple DES 168" (ohne / 168) verwende, wird die Systemereignis-ID 36880 nicht angezeigt und die RDP-Sitzung wird blockiert.
Laut Artikel: Systemkryptografie: Verwenden Sie FIPS-kompatible Algorithmen für die Verschlüsselung, das Hashing und das Signieren
Remotedesktopdienste (RDS) Zum Verschlüsseln der Remotedesktopdienste-Netzwerkkommunikation unterstützt diese Richtlinieneinstellung nur den Triple DES-Verschlüsselungsalgorithmus.
In dem Artikel heißt es: "Systemkryptografie: Verwenden Sie FIPS-kompatible Algorithmen für die Verschlüsselung, das Hashing und das Signieren" Sicherheitseinstellungseffekte in Windows XP und späteren Versionen von Windows
Diese Einstellung wirkt sich auch auf die Terminaldienste in Windows Server 2003 und späteren Versionen von Windows aus. Der Effekt hängt davon ab, ob TLS für die Serverauthentifizierung verwendet wird.
Wenn TLS für die Serverauthentifizierung verwendet wird, wird mit dieser Einstellung nur TLS 1.0 verwendet.
Wenn TLS nicht verwendet wird und diese Einstellung auf dem Client oder dem Server nicht aktiviert ist, wird der RDP-Kanal (Remote Desktop Protocol) zwischen dem Server und dem Client standardmäßig mithilfe des RC4-Algorithmus mit 128-Bit verschlüsselt Schlüssellänge. Nachdem Sie diese Einstellung auf einem Windows Server 2003-Computer aktiviert haben, gilt Folgendes: Der RDP-Kanal wird mithilfe des 3DES-Algorithmus im CBC-Modus (Cipher Block Chaining) mit einer Schlüssellänge von 168 Bit verschlüsselt. Der SHA-1-Algorithmus wird zum Erstellen von Nachrichtenauszügen verwendet. Clients müssen das RDP 5.2-Clientprogramm oder eine neuere Version verwenden, um eine Verbindung herzustellen.
Beide unterstützen die Idee, dass RDP nur 3DES verwenden kann. In diesem Artikel wird jedoch vorgeschlagen, dass ein größerer Bereich von Chiffren verfügbar ist: FIPS 140-Validierung
Die Gruppe der kryptografischen Algorithmen, die ein Remote Desktop Protocol-Server (RDP) verwendet, umfasst Folgendes: - CALG_RSA_KEYX - RSA-Algorithmus für den öffentlichen Schlüsselaustausch - CALG_3DES - Dreifacher DES-Verschlüsselungsalgorithmus - CALG_AES_128 - 128-Bit-AES - CALG_AES_256 - 256-Bit-AES - CALG_SHA1 - SHA-Hashing-Algorithmus - CALG_SHA_256 - 256-Bit-SHA-Hashing-Algorithmus - CALG_SHA_384 - 384-Bit-SHA-Hashing-Algorithmus - CALG_SHA_512 - 512-Bit-SHA-Hashing-Algorithmus
Letztendlich ist nicht klar, ob RDP Nicht-3DES-Protokolle unterstützen kann, wenn der FIPS-Modus aktiviert ist, aber es gibt Hinweise darauf, dass dies nicht der Fall ist.
Ich sehe keinen Hinweis darauf, dass Server 2012 R2 anders funktionieren würde als Server 2008 R2. Es scheint jedoch, dass Server 2008 R2 auf der Einhaltung von FIPS 140-1 basiert und Server 2012 R2 FIPS 140-2 folgt, sodass es durchaus möglich ist, dass Server 2012 R2 dies unterstützt zusätzliche Protokolle. Sie werden die zusätzlichen Protokolle im Link zur FIPS 140-Validierung beachten .
Fazit: Ich glaube nicht, dass Server 2008 R2 RDP im FIPS-Modus mit deaktiviertem 3DES unterstützen kann. Meine Empfehlung lautet, festzustellen, ob Ihr System die Bedingungen für einen SWEET32-Angriff erfüllt (mehr als 768 GB werden in einer einzigen Sitzung gesendet) und ob das Deaktivieren von 3DES das Entfernen der RDP-Fähigkeit wert ist. Es gibt andere Dienstprogramme zum Verwalten von Servern außerhalb von RDP, insbesondere in einer Welt, in der Virtualisierung weit verbreitet ist.
