web-dev-qa-db-ja.com

IIS 8.5サーバーがWindowsServer2003からのTLS1.0接続を受け入れない

（非推奨の暗号スイートを有効にしようとしている理由がわからない場合は、簡単に言えば、Windows Server 2003に固執しているために、実際には新しいものを使用できない少数の人々のためのものです。彼らはそれについて何でもすることができ、私たちがそれを助けることができれば、私たちが彼らに提供するサービスが機能しなくなることを望んでいません。）

IIS Crypto を使用して、製品に必要なものを網羅する必要のある多数のプロトコル、暗号、ハッシュ、鍵交換、および暗号スイート（ 完全なリスト ）を有効にしました。 Windows Server 2003でのSchannelの機能を考慮して、TLS 1.0を介してこのサーバーに接続します。（IIS Crypto。）で変更が適用されたため、サーバーは再起動されました。）

ただし、サーバーは接続を切断し、Schannelによってシステムイベントログに記録された次の2つのイベントログエントリで接続を文書化します。

「リモートクライアントアプリケーションからTLS1.0接続要求を受信しましたが、クライアントアプリケーションでサポートされている暗号スイートはどれもサーバーでサポートされていません。SSL接続要求は失敗しました。」 -イベントID36874

に続く

「致命的なアラートが生成され、リモートエンドポイントに送信されました。これにより、接続が終了する可能性があります。TLSプロトコルで定義された致命的なエラーコードは40です。WindowsSChannelエラー状態は1205です。」 -イベントID36888

クライアントでWiresharkを使用すると、次の暗号スイートをネゴシエートしようとしていることがわかります。

            Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
            Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
            Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
            Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
            Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
            Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)

これらのうち：

TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_3DES_EDE_CBC_SHA

IIS Cryptoで有効にしたものに含まれています。それでも、サーバーはこれらの暗号スイートにアクセスして接続を許可することを望んでいません。代わりに、接続を切断するだけです。 OpenSSLを使用して接続するこの試み 。

IISまたはSchannelがこれらの暗号スイートの使用を許可しないのは、私が知る限り、デフォルトに関係なく両方を使用するように構成したのになぜですか？

windows-server-2012-r2tlsiis-8.5schannel
2
Jesper

TL; DR：あきらめて LinuxとNginxを使用。

欠けていたものに対する答えは見つかりませんでした。上記のWindowsServer 2012 R2サーバー以外に、Windows Server 2008 R2サーバーをセットアップして完全に更新し、同じようにIIS Cryptoを使用しましたが、何らかの種類があったようです。特に、パッチ適用のためにダウンしていない別のWindows Server 2012 R2サーバーが同じことを行わないため、文書化された方法で非アクティブ化できないラインに沿った更新で展開されたRC4キルスイッチの一部。

Windows Updateを実行することを恐れて生きることができないため、Nginxを実行するUbuntuサーバーをセットアップし、TLSターミネーションを処理し、サーバー上のプレーンHTTPでサーバーへのリバースプロキシを行う必要がありました。公に。マイクロソフトの網羅的で正確なドキュメントの欠如と、マイナーアップデートでの動作を劇的に変更したいという願望は、顧客とそのビジネスに対する軽蔑を示しています。彼ら自身の判断で。

1
Jesper

私はこれが古いことを知っていますが、誰かがもっと知りたい場合のために、これのためのレジストリ内の場所もあります。私の考えでは、おそらくTLS1.0はEnabled = 0またはDisabledByDefault = 1ですか？

SSL/TSL：

レジストリの場所：\ HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

プロトコルレジストリフォルダにクライアントとサーバーのサブキーを持つキーがあり、その中にDisabledByDefaultとEnabledのDWORDSがある場合は、それが構成されています。 Win 2012（r1）のデフォルトの状態は、TLS1が許可され、デフォルトで許可されていました。 （そうでない場合は、それらを追加できます）

（サーバーは着信接続用であり、クライアントは発信接続用であることに注意してください。）

参照：

暗号：

レジストリの場所：\ HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

たくさん調べて、誰もがこのプログラムを使用していることがわかった後、IIS Cryptoも使用しました（グループポリシーエディターの暗号スイートリストに1023文字の制限があることから解放されました。 ）

（余談：Win XP 3DES（トリプルDES）がカリングされると、HTTPSとのすべての接続が失われます）

参照：

2
Mark

ほとんどの組織は、ここでIIS 8つの強化ガイドラインに従います： https://benchmarks.cisecurity.org/tools2/iis/CIS_Microsoft_IIS_8_Benchmark_v1.0.0.pdf

ここで定義されている値を確認することをお勧めします：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 SchUseStrongCrypto

Strong Cryptoをオンにすると、RC4サポートが自動的に無効になり、IIS Cryptoツールが触れるものではありません。

0
louis xie