人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

OpenSSLの1.01で、TLS1.1/TLS1.2の認証を非活性にしている場合、今回の脆弱性は避けられたのでしょうか。
職場の外部向けサーバーでapache 2.2+OpenSSL 0.98を使ってます。
OpenSSLの1.01はバグ(最近ではhttp://www.openssl.org/news/secadv_20140407.txt)が怖くて移行できないでいるのですが、いつまもでも移行しないではいられません。
バージョン1.01を比較的安全に使うのはどうすれば良いのか思案中です。お知恵を貸して下さい。

●質問者: sasada
●カテゴリ:ウェブ制作
○ 状態 :終了
└ 回答数 : 2/2件

▽最新の回答へ

1 ● snow0214
●500ポイント

今回問題になった脆弱性はHeartbeat拡張の実装の問題なので、TLSだけでなくSSLにも及びます。なので、TLS1.1/TLS1.2認証を非活性にしていても避けられません。

Heartbleed bug によるサーバ設定の状況変化(IIJ)

https://sect.iij.ad.jp/d/2014/04/157355.html

この脆弱性はバージョン1.01gにアップデートすれば改善します。
修正済みバージョンの適用が困難な場合は、以下の回避策の適用を検討してください。
「-DOPENSSL_NO_HEARTBEATS」オプションを有効にして OpenSSL を再コンパイルする。

OpenSSL の脆弱性に関する注意喚起(JPCERT)

http://www.jpcert.or.jp/at/2014/at140013.html

バージョン1.01については、今回の脆弱性が指摘されるまで1年近くにわたってバグらしいバグが出ていなかったので、安定しているバージョンだと思います。


sasadaさんのコメント
『TLS1.1/TLS1.2認証を非活性にしていても避けられません』 やはりそうですか。ありがとうございます。 我々は1.01を使ってなかったので、今回の件でのアップデートも電子証明書の再配布も必要なかったんですが、参考にある方も多いと思います。 バージョン1.01が最近安定してきたので移行を考えてた矢先に、今回の騒ぎが起こったので、頭が痛いです。 まだ何が隠れてるか分からないので、信用を求められるサービスでは待ちの体勢かもですね。時流に逆らってるとは思いますが。 うーん。1.01gを信用するべきなのか。信用するにしても当面TLS1.1/1.2は非活性にするべきなのか。。。引き続き回答での助言をお待ちしております。。。

snow0214さんのコメント
たとえばApache 2.xについては、2013年の1年間に6件ほどの脆弱性が報告されています。 運用しているOS/ミドルウェア/フレームワーク/アプリケーションのセキュリティ情報を常に監視し、リスクが顕在化したときには速やかに修正パッチを当てられる体制を整えてください。 逆に考えると、OS/ミドルウェア/フレームワーク/アプリケーションの種類が少ない方が運用は楽です。 また、ApacheやOpenSSLといったメジャーのソフトの方が脆弱性を発見されることが多いですが、修正パッチがリリースされるのも早いですから、総合的に見てリスクは低いと考えられます。

sasadaさんのコメント
>> 脆弱性を発見されることが多いですが、修正パッチがリリースされるのも早いですから、総合的に見てリスクは低いと考えられます。 << そういう考え方もありますね。活性化しているオープンソフトの長所ともいえます。 今までに出たバブをもう一度検証して、負うべきリスクをどこまで許すか考えてみます。 ありがとうございます!!

2 ● JULY
●750ポイント ベストアンサー

CentOS 6.5 上で実験してみました。
サーバ側:

openssl s_server -cert 証明書ファイル -key 秘密鍵ファイル -ssl3

クライアント側:

echo B | openssl s_client -connect localhost:4433

結果:

(略)
SSL-Session:
 Protocol : SSLv3
 Cipher : ECDHE-RSA-AES256-SHA
 Session-ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 Session-ID-ctx:
 Master-Key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 Key-Arg : None
 Krb5 Principal: None
 PSK identity: None
 PSK identity hint: None
 Start Time: 1398341090
 Timeout : 300 (sec)
 Verify return code: 18 (self signed certificate)
---
HEARTBEATING
DONE

SSLv3 でつながっているのけど heartbeat は使えています。

余談:
検証してみようと試している中で、RHEL / CentOS 6.5 の httpd で SSLProtocol で SSLv3 のみを指定している場合、TLSv1.0 でのネゴシエーションに失敗するのに、TLSv1.1、TLSv1.2 ではつながる、という不思議な現象を発見...。

閑話休題。

結論としては、TLSv1.1、1.2 を無効にしても heartbeat が使えるので、Heartbleed の問題は避けられないことになります。

うーん。1.01gを信用するべきなのか。信用するにしても当面TLS1.1/1.2は非活性にするべきなのか。。。

ピンポイントで今回の Heartbleed の問題に対して、1.0.1g や各ディストリビューションの update での修正が信用できるか? ということであれば、十分に信用できます。というのは、原因が極めて単純なバグだったからです。ですので、Heartbleed の問題は、きちんとアップデートして置けば、今後は発生しません。

ただ、OpenSSL というプログラムがどうか? という事に関しては、ケチが付いた格好にはなります。

一度、こういった事があると、「他に同様の問題はないか?」と疑心暗鬼になるのは仕方がないことです。OpenSSL のプロジェクトのあり方にも疑問が示され、OpenBSD プロジェクトが LibreSSL という代替プログラムのプロジェクトを立ち上げています。

なので、OpenSSL 自体を信用ならないとするなら、どのバージョンを使うべきか、ではなく、OpenSSL 以外の実装(例えば GnuTLS)を選択する、という話になります。

確かに Heartbleed は、久しぶりに見る「大きな穴」でしたが、正直、これほどの大きな穴が、ほいほいと見つかるかというと、確率は低いと思います。

これよりも小さな穴は、どんなソフトでも見つかる話で、一番肝心なのは、アップデートが出たら、面倒がらずにアップデートする、という方が、トータルで考えると、簡単で確実な方法だと思います。


sasadaさんのコメント
検証ありがとうございます! 非常に参考になりました!! >> TLSv1.0 でのネゴシエーションに失敗するのに、TLSv1.1、TLSv1.2 ではつながる << これ、不思議ですね。必要ならば明示的に-TLS1.1 -TLS1.2することにします。 >> これよりも小さな穴は、どんなソフトでも見つかる話で、一番肝心なのは、アップデートが出たら、面倒がらずにアップデートする、という方が、トータルで考えると、簡単で確実な方法だと思います。 << はい。今回の問題に限らず、細かいバグも出てくるでしょうし、こまめにバージョンアップします。

JULYさんのコメント
>> これ、不思議ですね。必要ならば明示的に-TLS1.1 -TLS1.2することにします。 << ところが、CentOS 6.5 上では、このキーワードが httpd に蹴られてしまいます。 http://bugs.centos.org/view.php?id=7077 上記ページは、+TLSv1.1 などとした時のバグ報告ですが、手元の CentOS 6.5 で -TLSv1.1 でも同じ事が発生しました。 おそらく、RHEL 6.5 でも同様だと思いますが、httpd が設定ファイルのキーワードとして TLSv1.1、TLSv1.2 を認識せず、その結果、openssl 側でデフォルトで有効になっている TLSv1.1、1.2 が勝手に有効になる、という現象に見えます。だとすれば、SSLProtocol で SSLv3 だけをしても、TLSv1.0 では失敗し、1.1、1.2 で成功する現象も説明できます。 Ver. 6.5 で、openssl のバージョンが 1.0.0 → 1.0.1 になって、TLSv1.1、1.2 に対応したのに、mod_ssl のベースのバージョンが古く、SSLProtocol の設定に対応するためのバックポートが行われていない、ということだと妄想しています。

sasadaさんのコメント
>> httpd が設定ファイルのキーワードとして TLSv1.1、TLSv1.2 を認識せず、その結果、openssl 側でデフォルトで有効になっている TLSv1.1、1.2 が勝手に有効になる << なるほど。そう考えると、私の方で行ったテストの結果も納得がいきます。 案外やっかいですね。 TLS1.xがらみでは、1.01eや1.01fでfixされたバグも多かったと記憶しています。おそらく1.01g以降も未修正の細かいバグが非公開のまま残っているのだろうと推測しています。 1.01gを信用してTLS1.xの利用に踏み切るか、数ヶ月以上先になるかもしれない1.01h以降を待って、クライアント側のIEの設定でTLS1.xを外す手間をかけてもらうか、慎重に検討したいと思います。
関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ