web-dev-qa-db-ja.com

OpenSSLハンドシェイクの失敗

GoDaddyがクラウドサーバーサービスを終了するため、最近、運用クラウドサーバーをGoDaddyからAzureに移行せざるを得なくなりました。

私たちのサーバーの1つは、JasperReports Bitnamiスタックを実行するCentOS 5.7でした。移行プロセス中に、すべてのサーバーを最新のディストリビューションにアップグレードし、Ubuntu 12.04LTS上のAzure Bitnami JasperイメージからJasperを再構築しました

JasperServerにSSL証明書がインストールされており、正しく機能している

すべての新しいサーバーは美しく機能しています。ここで問題が発生します。

また、GoDaddyには専用のCentOS 5.8仮想サーバーがあり(現在のところ)、サーバーにはJasperからSoapを介してレポートを提供するサイトのコレクションがあります。

ただし、接続しようとするとハンドシェイクに失敗します

#openssl s_client -connect newjasperserver.com:443
CONNECTED(00000003)
9092:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:583:

そして:

#openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

新しいサーバーが実行されています:

#openssl version
OpenSSL 1.0.1c 10 May 2012

多くの調査の結果、OpenSSL <0.9.8kとOpenSSL1.0.1の間に非互換性があるようです。

私が特定したオプションは次のとおりです。

  1. サーバーをAzure上のCentOS6.4サーバーに移行します(理想的ですが、政治的に難しいため、理由を尋ねないでください)

  2. サーバーをインプレースでアップグレードします(サポートされていません。運用サーバーで試したくありません)

  3. サーバーをワイプして6.4で再構築します(可能であれば、オプション1を強制します)

  4. サーバーからOpenSSLを削除し、新しいバージョンをインストールします(もう一度、実稼働サーバーでは使いにくいものです)。

  5. OpenSSLの2番目のインスタンスをインストールします(私の#2オプションですが、続行する方法がわかりません)

  6. OpenSSLの代替をインストールします(これを検討し始めたことさえあります)

  7. Jasperサーバーで強制暗号化を無効にし、http経由の接続を許可します(これは、サーバーを強制的にAzureに移行できるようになるまで、これが私の最善の一時的な修正のように見えます)

私が逃したオプションはありますか? Jasper側で古いOpenSSLからの接続を許可する方法はありますか?

3
Matt Bear

あなたが遭遇した非互換性はこれです:

RHEL5(およびその派生物)上のOpenSSLのバージョンは、TLSのサポートをまったくアドバタイズしません。 SSLv3およびSSLv2のみを実行します。

RHEL6(およびその派生物)上のOpenSSLのバージョンは、TLSv1.2までのTLSをサポートします。 SSLv3も実行しますが、TLSをネゴシエートする必要があります。

彼らすべき両方に共通の暗号の(小さい)リストがあるので、セッションをネゴシエートすることができますが、サーバーの暗号設定に選択したものに依存します(たとえば、 BEAST、低セキュリティの暗号などを削除します。)クライアントとサーバーが通信に使用できる一般的な暗号がない場合があります。

サーバーの暗号スイートは、Tomcat <Connector ciphers=server.xml、またはApacheの背後にある場合はApacheのSSLCipherSuiteに設定されます。クライアントは、使用するように構成されたものを何でも使用し、そうでない場合はDEFAULTを使用します。

解決策は、サーバー上の暗号スイートをチェックすることです。 openssl ciphers -v STRINGを使用します。ここで、STRINGはサーバーで構成したものであり、クライアントでも同じことを繰り返し、両方がネゴシエートする暗号スイートが使用可能になるまで一方または両方を調整します。

5
Michael Hampton