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からの接続を許可する方法はありますか？

centos5openssllinux
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