私の職場は最近、POODLEの脆弱性に対処するためにサーバーの1つにパッチを適用しました。それ以降、古いOracle Linux 5クライアント(RHEL 5に基づく)は、どのアプリケーションでもサーバーに安全に接続できなくなりました。クライアントコンピューターはOpenSSLバージョン0.9.8eを使用します。これらのコンピューター(0.9.8e-31)にOpenSSLの最新バージョンをインストールしても違いはありませんが、クライアントにTLSv1のみを使用するように強制するdoes問題を修正します。
例えば、 s_client
はこれをもたらします:
$ openssl s_client -connect foo.bar.com:443
CONNECTED(00000003)
5529:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
ただし、これは正しく機能します。
$ openssl s_client -connect foo.bar.com:443 -tls1
同様に、wget https://foo.bar.com/testFile
失敗しますが、wget --secure-protocol=TLSv1 https://foo.bar.com/testFile
動作します。
私の主な質問は、これらのクライアントマシンでOpenSSLをグローバルに構成して、再度接続できるようにする方法ですなし使用する、または将来使用する可能性のあるすべてのアプリケーションを手動で再構成する必要があります。これらのボックスを新しいバージョンのLinuxにアップグレードすることはできません。この動作の原因を正確に説明できる場合は、ボーナスポイントがあります。
ありがとう!
まず、なぜですか? s_client
のドキュメントでは、opensslはデフォルトで、正しいプロトコルを把握するハンドシェイクを使用すると記載されています。これがPOODLE攻撃の基本です。問題は、0.9.8では、ハンドシェイクがSSL_V23で始まり、後のある時点でTLSv1を試行することです。多くのサーバーは、クライアントがSSL_V23を使用して接続する場合、クライアントが安全でないことを行っていることを示す危険信号であるため、これを嫌います。したがって、問題が発生します。
それを修正する方法は? 「ねえ、デフォルトではTLSv1を使用するだけです」と言うことができるopenssl.cnfのオプションが見つかりませんでした。 このスレッド では、v1.0.0 +でこれが可能であることを示唆しているようです。 1時間のグーグル検索の後、私はあなたの最善の策は opensslを再コンパイルしてSSLv2とSSLv3を無効にする であると決めました。 opensslを再コンパイルする場合は、おそらく0.9.8を使用する方がはるかに簡単です。RHELのようなものでopensslを1.x +にアップグレードしようとすると、まったく悪夢になる可能性があります。
RHEL 5にも同じ問題があるので、私は彼らのbugzillaをチェックしました: https://bugzilla.redhat.com/show_bug.cgi?id=1152789
彼らはTomcat6とそのJBossのものにかなり焦点を合わせています。これは、アプリケーションサーバー構成の数行を変更することです。
しかし、そのbugzilla内には、RHEL5のopenssl問題につながるスレッドがあります。
https://rhn.redhat.com/errata/RHSA-2014-1653.html
openssl-0.9.8e-31.el5_11は、必要なアップストリームで再コンパイルされたopensslです。
つまり、私見では、そのパッチをインストールし、Web /アプリケーションサーバーに安全でないプロトコルを使用しないように強制する必要があります。