Windows 10で脆弱な暗号を削除すると、発信RDPが破損する
TrustWaveの脆弱性スキャナーは、RDPを実行しているWindows 10マシンが原因でスキャンに失敗します。
Sweet32として知られている64ビットのブロックサイズのブロック暗号アルゴリズム（DESおよび3DESなど）の誕生日攻撃（CVE-2016-2183）
注：RDP（リモートデスクトッププロトコル）を実行しているWindows 7/10システムでは、無効にする必要がある脆弱な暗号には「TLS_RSA_WITH_3DES_EDE_CBC_SHA」というラベルが付いています。
IIS Crypto（by Nartac））を使用して、「ベストプラクティス」テンプレートとPCI 3.1テンプレートを適用しようとしましたが、どちらにも安全でない暗号（TLS_RSA_WITH_3DES_EDE_CBC_SHA）が含まれています。
この暗号を無効にすると、RDP from多くのWindowsステーションへのこのコンピューターが機能しなくなります（一部の2008 R2および2012 R2サーバーでは機能します）。 RDPクライアントは単に「内部エラーが発生しました」とイベントログを提供します。
TLSクライアント資格情報の作成中に致命的なエラーが発生しました。内部エラー状態は10013です。
いずれかのサーバーのサーバーイベントログを確認し、これら2つのメッセージを確認しました
TLS 1.2接続要求がリモートクライアントアプリケーションから受信されましたが、クライアントアプリケーションでサポートされている暗号スイートがサーバーでサポートされていません。 SSL接続要求が失敗しました。
次の致命的なアラートが生成されました：40。内部エラー状態は1205です。
送信RDPを壊すことなくセキュリティの脆弱性を修正するにはどうすればよいですか？
または、上記が不可能な場合は、接続できない各RDPホストで、その側で処理できる何かがありますか？
---アップデート＃1---
Windows 10マシンでTLS_RSA_WITH_3DES_EDE_CBC_SHAを無効にした後、いくつかのRDPホストに接続しようとしました（それらの半分は「内部エラー...」で失敗しました）。したがって、私はcanに接続するこれらのホストの1つを、cannotに接続するホストと比較しました。どちらも2008 R2です。両方に同じRDPバージョンがあります（6.3.9600、RDPプロトコル8.1をサポート）。
IIS Cryptoを使用して現在の設定で「テンプレートを保存」することでTLSプロトコルと暗号を比較し、テンプレートファイルを比較できるようにしました。これらは同じでした！したがって、問題は何でもありませんホスト上に欠けているチファースイートの問題のようです。ファイルのBeyond Compareのスクリーンショットは次のとおりです。
この問題の原因となる2つのRDPホストの違いと、それを修正する方法
IIS Cryptoには、サーバー側（受信）とクライアント側（送信）の両方のオプションを設定するオプションがあります。互換性のためにクライアント側で有効にしておく必要がある暗号がいくつかあります。
あなたが望むことをするために、私は個人的に次のようにします：
- 3.1テンプレートを適用
- すべての暗号スイートを有効のままにします
- クライアントとサーバーの両方に適用します（チェックボックスをオンにします）。
- 「適用」をクリックして変更を保存します
必要に応じて、ここで再起動します（マシンに物理的にアクセスできます）。
- 3.1テンプレートを適用
- すべての暗号スイートを有効のままにします
- サーバーに適用します（チェックボックスをオフにします）。
- 3DESオプションのチェックを外します
ここで再起動すると、正しい終了状態になります。
事実上、3DESインバウンドを無効にしたいが、それでも上記の暗号スイートのアウトバウンド使用を許可したい。
編集（2018-09-26）：2012R2で3DESを無効にしてもRDPは無効になりませんが、2008 R2では無効になることがわかりました。サポートされているオプションはカーネルによって異なるようです。
TechNetからの回答をお伝えします thread ですが、最初のBLUF：
Serverfaultの結論：システム間に他の違いがある可能性があります。異なるOSバージョン間で接続しています。1つのシステムでFIPS=が有効で他のシステムで有効になっていないか、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphersで異なる暗号制限が設定されています。私は確かにSCHANNELを有効にしますシステムにログオンしてはどの暗号が使用されているかを判別するために機能します。
投稿のコピー：
うまくいきました！
どうやら2008と2012には構文の問題があり、2008/7には末尾に/ 168が必要です。 2012/8.1/10ではサポートされていません。
2008のキーは次のようになります：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168そして2012年のキーは次のようになります：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168
"Triple DES 168/168"を使用しても、システムの3DESは無効になりません。プロトコルスキャナー（Nessusなど）を使用するか、SCHANNELのログを有効にすることで、これを証明できます。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007その後、たとえば、SYSTEMログにイベントが記録されます。
SSLクライアントハンドシェイクが正常に完了しました。ネゴシエートされた暗号化パラメーターは次のとおりです。
プロトコル：TLS 1.0 CipherSuite：0x2f交換強度：1024
私にとって結果は0xaであり、GoogleはこれをTLS_RSA_WITH_3DES_EDE_CBC_SHAとして明らかにします。
「トリプルDES 168」（/ 168なし）を使用すると、システムイベントID 36880が表示されず、RDPセッションがブロックされます。
記事ごと： システム暗号化：FIPS暗号化、ハッシュ、署名に準拠したアルゴリズムを使用
リモートデスクトップサービス（RDS）リモートデスクトップサービスのネットワーク通信を暗号化する場合、このポリシー設定は、トリプルDES暗号化アルゴリズムのみをサポートします。
記事ごと： "システム暗号化：FIPS暗号化、ハッシュ、署名に準拠したアルゴリズムを使用する" Windowsのセキュリティ設定効果XP and Windowsの新しいバージョン
この設定は、Windows Server 2003以降のバージョンのWindowsのターミナルサービスにも影響します。効果は、サーバー認証にTLSが使用されているかどうかによって異なります。
サーバー認証にTLSが使用されている場合、この設定により、TLS 1.0のみが使用されます。
既定では、TLSが使用されておらず、クライアントまたはサーバーでこの設定が有効になっていない場合、サーバーとクライアント間のリモートデスクトッププロトコル（RDP）チャネルは、128ビットのRC4アルゴリズムを使用して暗号化されますキーの長さ。 Windows Server 2003ベースのコンピューターでこの設定を有効にすると、次のようになります。RDPチャネルは、暗号化ブロックチェーン（CBC）モードの3DESアルゴリズムを使用して、168ビットのキー長で暗号化されます。 SHA-1アルゴリズムは、メッセージダイジェストを作成するために使用されます。クライアントは、RDP 5.2クライアントプログラムまたはそれ以降のバージョンを使用して接続する必要があります。
したがって、これらは両方とも、RDPは3DESしか利用できないという考えをサポートしています。ただし、この記事では、より広い範囲の暗号が利用可能であることを示唆しています： FIPS 140 Validation
リモートデスクトッププロトコル（RDP）サーバーが使用する暗号化アルゴリズムのセットは、次の範囲に適用されます。-CALG_RSA_KEYX-RSA公開キー交換アルゴリズム-CALG_3DES-トリプルDES暗号化アルゴリズム-CALG_AES_128-128ビットAES -CALG_AES_256-256ビットAES-CALG_SHA1-SHAハッシュアルゴリズム-CALG_SHA_256-256ビットSHAハッシュアルゴリズム-CALG_SHA_384-384ビットSHAハッシュアルゴリズム-CALG_SHA_512-512ビットSHAハッシュアルゴリズム
FIPSモードが有効になっている場合、RDPが3DES以外のプロトコルをサポートできるかどうかは最終的に明確ではありませんが、証拠はそうではないことを示唆しています。
Server 2012 R2がServer 2008 R2とは機能が異なるという証拠はありませんが、Server 2008 R2はFIPS 140-1準拠であり、Server 2012 R2が準拠しているFIPS 140-2なので、Server 2012 R2が追加のプロトコルをサポートすることは完全に可能です。追加のプロトコルは FIPS 140検証 リンクに記載されています。
結論：Server 2008 R2はFIPS 3DESを無効にしたモードでRDPをサポートできるとは思いません。推奨事項システムがSWEET32攻撃の条件（単一のセッションで送信される768GB以上）を満たしているかどうか、および3DESを無効にすることはRDP機能を削除する価値があるかどうかを確認することです。特に仮想化が非常に一般的である世界では、RDP以外のサーバーを管理する他のユーティリティが存在します。
同じ問題がありました。サーバーにKB3080079パッチをインストールすると、tls 1.1および1.2のサポートが有効になります。
Windows 7クライアントの場合は、rdpクライアントアップデート（KB2830477）をインストールする必要があります。そうしないと、Windows 8以降のみが接続できます。
どうやら2008と2012には構文の問題があり、2008/7には末尾に/ 168が必要です。 2012/8.1/10ではサポートされていません。
2008のキーは次のようになります。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168
**すばらしい結果私は一部のWindows 2008 R2ドメインコントローラーでまったく同じ問題を抱えていました。奇妙なことに、私のメンバー2008R2サーバーは大丈夫なようです...そして、私の2012R2サーバーも正常に動作します。これらの古いDCを分解することをクラックする必要があります:)