RemoteAppで接続できなくなった(Schannel 36874)

AWSに建てたWindowsインスタンス（以下サーバー）にリモートデスクトップで繋がらなくなったという、いわゆる半分『詰み』の状態からスタートです。

単なる作業メモです。残念ながら、解決策ではありません。

PowerShellでWindowsファイアーウォールの制限を緩和によりサーバー側のログが見れるようになったので、早速調査を開始します。OS の組み合わせは以下の通りです。

• クライアント
  • Windows10 Enterprise 10.0.10586
  • Windows7 Professional 6.1.7601
• サーバー
  • Windows 2012 R2

サーバー側のログは以下の通りです：

リモート クライアント アプリケーションから TLS 1.2 接続要求を受信しましたが、クライアントでサポートされている暗号がサーバーでサポートされていません。SSL 接続要求は失敗しました。
ソース：Schannel, イベントID：36874

Schannel イベント 36874

クライアント アプリケーションは、サーバーでサポートされていない SSL 接続を要求しています。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
に一覧表示されている値を調査し、サーバーで使用されるバージョンが含まれていることを確認します。

端末(Windows10)側で確認してみました：

PS C:\> reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols /s

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client
    DisabledByDefault    REG_DWORD    0x1

なぜ SSL 2.0 しかない？しかも DisabledByDefault なのであれば、有効になっているプロトコルは皆無という意味？？？
参考までに Windows7 から接続してみましたが同じエラーでした。レジストリの内容も全く同じでした。

サポートされる暗号スイートおよび Schannel SSP のプロトコル

• SSL 2.0
  • SSL 2.0 は Netscape Corporation 独自のプロトコルでした。 このトピックの冒頭にある「適用対象」リストで指定されている Windows クライアント コンピューターでは、既定で無効になっています。

まぁ、そうでしょうね。

特定の暗号化アルゴリズムおよび Schannel.dll のプロトコルの使用を制限する方法

• SCHANNEL\Protocols サブキー
  • (TLS 1.1 および TLS 1.2) などの既定ではネゴシエーションされませんが、プロトコルを使用するシステムを有効にするには、 DisabledByDefault値の DWORD 値のデータをプロトコルのキーの下の次のレジストリ キーには、 0x0に変更します。
    • SCHANNEL\Protocols\TLS 1.1\Client
    • SCHANNEL\Protocols\TLS 1.1\Server
    • SCHANNEL\Protocols\TLS 1.2\Client
    • SCHANNEL\Protocols\TLS 1.2\Server

（日本語が残念な感じなので、中の人に改善案を提示しておきました）

　やっぱりタイトルの通り、このレジストリエントリはプロトコルの使用を『制限する』ためのしくみであって、明示されていないものはデフォルトで使われるのではないのかなぁ。ちなみにパケットを拾ってみると、端末側から切断しています。

　試しに TLS 1.1 を追加して、それを『無効としない』にしてみました（レジストリエントリを変更する場合、『PowerShell を管理者として実行』しないと怒られます）。

PS C:\> reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0x0
この操作を正しく終了しました。
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols /s
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client
    DisabledByDefault    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
    DisabledByDefault    REG_DWORD    0x0

でも、やっぱり同じ。

[Windows Azure] イベントログエラーSchannel 36874 および 36888 について

本現象は、クライアント側で利用されている暗号化方式がサーバー側で利用できないものの場合、クライアント側で古いOSを利用されている場合、暗号化方式が破損したOS 等で発生することがあります。

サーバーの観点から見ると、暗号化方式が利用できないためリクエストを受け付けていないだけですので、多く発生していない場合には本エラーは基本的に無視をしてよいものになります。

クライアント側から見ると、接続できない状況のためサーバーで利用可能な暗号化方式をご利用いただくか、古いOSをご利用の際には、新しいOSにアップグレードしていただく必要があります。

このエラーは、IIS や Exchange などいろんなサービスで検出される、有名なもののようです。『基本的には無視していいよ』的なもののようですが、こちとらこれができないとサーバーに入れないので洒落になりません。

Windows10 をアップグレードするわけにもいかないし :-(

ネットをさまよっていると、こういうのを見つけました。
Why does Window's SSL Cipher-Suite get restricted under certain SSL certificates?

４年ほど前のスレですが、これに約３年ぶりについたレスが以下の通り：

Disabling logging of events simply to "hide the error" is never good security practice.

To understand what the zero (0) does at this Registry key, have a look at "How to enable Schannel event logging in IIS" (http://support.microsoft.com/en-us/kb/260729).
A better solution is to configure appropriate cipher suites that your IIS web server supports. See the OpenSSL cookbook for an ordered list of cipher suites: https://www.feistyduck.com/books/openssl-cookbook/
In 2015, that means disabling SSL v2 and SSL v3.

（試訳）

（マイクロソフトサポートの中の人がいつもオススメするところの）イベントのログを無効にして単に『エラーを隠す』のは、よいセキュリティの習慣とは決して言えません。

このレジストリキーでゼロ(0)が何をしているのかを理解するには、IISでSchannelイベントログを有効にするにはを見てみるとよいでしょう。
よりよい解決策は、あなたのIIS Webサーバーがサポートすべき、適切な暗号化スイート（暗号化方式の組み合わせ）を設定することです。OpenSSL のクックブックに暗号化スイートの順序を記載したリストがあります。
これによると、2015 年時点では、SSL v2 と SSL v3 を無効にするのがおすすめです。

念のため端末側で SSL v3 を無効にしてみましたが、現象変わらずでした。

PS C:\> reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocol
s\SSL 3.0\Client" /v DisabledByDefault /t REG_DWORD /d 0x1
この操作を正しく終了しました。
PS C:\> reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protoco
ls /s

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client
    DisabledByDefault    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client
    DisabledByDefault    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
    DisabledByDefault    REG_DWORD    0x0

たしかに問題となったサーバーでは、Let's Encrypt を使ってSSLサーバー証明書を導入していました。ただ、それをリモートデスクトップ関連コンポーネントの中で指定したかどうかは、残念ながら覚えていません。また AD CS（証明書サービス）も同時に試そうとしていて、ごちゃごちゃになっていました。

それにしても、RemoteApp はコンポーネントをいじり損ねると、最悪インスタンスにつながらなくなる（ことがある）というのは恐ろしいですね。

ということで、今回のインスタンスは諦めて作り直します。ただ元のインスタンスは数日寝かせておきますので、何か解決策につながるヒントがありましたらお願いします。