TLSv1ハンドシェイクの失敗

（免責事項：私はその想像力にとらわれず、セキュリティの専門家でもWindowsの専門家でもありません）

セットアップ：

• 私たちの側のサーバー：Windows 2003サーバー上のjava 1.6（すでにセキュリティファイルにbouncycastleが追加されています）
• サードパーティクライアント：biztalkを搭載したWindows 2008サーバー
• 再ネゴシエーション攻撃によって導入されたすべての再ネゴシエーションシステムプロパティは、サーバー側で「有効」になっています（私が知っていると安全ではありません）。

理想的にはこれを最後に修正したいのですが、必要に応じてクライアントに修正を提案することができます。

クライアントサーバーはHTTPS接続を介してサーバーに接続する必要がありますが、常に失敗します。wiresharkは次の会話を示します。

> TLSv1: Client Hello
< TLSv1: Alert (21): Unexpected Message

RFC（http://www.ietf.org/rfc/rfc2246.txt）に従って、alert（21）は失敗した復号化を参照しており、wiresharkで確認できることから、クライアントによって提案された暗号は実際にはありませんJRE 1.6でサポート（http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuitesによる）エラーを再現して、より詳しく調査できるようにするため、他のソフトウェアでテストしました：

• 「https」が選択されたWindows XPのwfetchは、SSLv2で初期クライアントハンドシェイクを実行し、サーバーはTLSv1に切り替えて応答します。これは機能します
• 初期ハンドシェイクに「TLSv1」を使用するように構成されたWindows XPのwfetchは、biztalkサーバーと同じように失敗します
• 「https」が設定されたWindows 2008のwfetchは、初期ハンドシェイクに「TLSv1」を使用し、biztalkサーバーと同じように失敗します
• IE（Windows XPの場合）は、最初に同じ失敗した結果でTLSv1ハンドシェイクを試行しますが、すぐに機能するSSLv3を使用して再試行します（この時点で、すべてのMicrosoftソフトウェアはHKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ Schannel）
• firefoxは会話全体にSSLv3を使用するため、問題ありません
• OpenSSLはSSLv2で初期ハンドシェイクを実行し、サーバーは応答するとTLSv1に切り替えます。そこで問題はありません。
• OpenSSLはTLSv1でも最初のハンドシェイクを強制することができ、27の暗号のリストを提供し（Windowsベースのソフトウェアによって提案された11の暗号とは対照的）、問題なく接続できます。

私の訓練されていない目には、これは互換性のない暗号命題が根本的な原因であり、WindowsがJVM（TLSv1の場合）でサポートされていない暗号スイートのみをサポートするという考えを強化します。弾む城をjava.securityファイルの追加プロバイダーとしてインストールしましたが、役に立ちません。私は高低を検索しましたが、websphereがTLSv1のWindows暗号をサポートしている可能性があるが、それをテストするためにスタンドアロンプ​​ロバイダーをダウンロードする方法がないという参照のみを見つけました。JRE 1.7は、JVMで実行しているソフトウェアではサポートされていないため、アップグレードはオプションではありません（おそらく、セキュリティプロバイダーを安全にダウングレードできますか？まだダウンロードが見つかりません）追加する方法が見つかりませんc ++コードを作成する前にウィンドウを暗号化します（上記のレジストリ設定をいじってみました）。

結論として、私は次のいずれかがそれを修正するかどうか、そしてそれらがどのように達成されるべきかを疑問に思います：

• Windowsによって提案されたTLSv1の暗号を使用できるプロバイダーをjvmに追加する
• どういうわけかクライアントにSSLv3（できればSSLv2ではない）で初期ハンドシェイクを強制するか、少なくともTLSv1ハンドシェイクが失敗した場合は再試行する
• どういうわけか、クライアントウィンドウにTLSv1のJVMサポート暗号を追加します

もちろん、他のソリューションも評価されます。

編集する

JavaのバージョンはJava version (64 bit): 1.6.0_19-b04です。

提案されている暗号のリストは次のとおりです。

• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_DES_CBC_SHA
• TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

無制限の強度の暗号化ポリシーファイルがインストールされます。javax.net.debug=allコンソールからサーバーを設定して起動しようとしましたが、追加の出力は表示されませんでした。sun.security.ssl.allowUnsafeRenegotiation=true無駄に設定しました。

編集2

使用しているソフトウェアは、デフォルトの代わりにHTTPのカスタムスタックを使用していることがわかりました。TLSリクエストのどの部分がエラーをトリガーしたかは正確にはわかりませんが、ほとんどのTLSv1ハンドシェイクが成功したため、問題を解決するように見える修正が発行されました。

フィードバックをお寄せいただきありがとうございます。無駄な検索であると興味深いものでした。生活し、学びます。