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を比較的安全に使うのはどうすれば良いのか思案中です。お知恵を貸して下さい。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2014/04/24 07:15:46
  • 終了:2014/04/29 07:46:58

ベストアンサー

id:JULY No.2

JULY回答回数966ベストアンサー獲得回数2472014/04/24 21:39:13

ポイント750pt

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

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

他1件のコメントを見る
id: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 の設定に対応するためのバックポートが行われていない、ということだと妄想しています。

2014/04/25 09:09:36
id: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を外す手間をかけてもらうか、慎重に検討したいと思います。

2014/04/29 07:34:40

その他の回答(1件)

id:snow0214 No.1

snow0214回答回数470ベストアンサー獲得回数1162014/04/24 19:21:31

ポイント500pt

今回問題になった脆弱性は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年近くにわたってバグらしいバグが出ていなかったので、安定しているバージョンだと思います。

他1件のコメントを見る
id:snow0214

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

また、ApacheやOpenSSLといったメジャーのソフトの方が脆弱性を発見されることが多いですが、修正パッチがリリースされるのも早いですから、総合的に見てリスクは低いと考えられます。

2014/04/24 21:26:27
id:sasada

脆弱性を発見されることが多いですが、修正パッチがリリースされるのも早いですから、総合的に見てリスクは低いと考えられます。

そういう考え方もありますね。活性化しているオープンソフトの長所ともいえます。
今までに出たバブをもう一度検証して、負うべきリスクをどこまで許すか考えてみます。
ありがとうございます!!

2014/04/25 07:03:26
id:JULY No.2

JULY回答回数966ベストアンサー獲得回数2472014/04/24 21:39:13ここでベストアンサー

ポイント750pt

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

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

他1件のコメントを見る
id: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 の設定に対応するためのバックポートが行われていない、ということだと妄想しています。

2014/04/25 09:09:36
id: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を外す手間をかけてもらうか、慎重に検討したいと思います。

2014/04/29 07:34:40
  • id:sasada
     回答を下さった御両名に感謝申し上げます。

     今回のケースでの1.01gの利用に関しては、会社の信用情報を扱うサーバーのため、堅牢さ重視の運用になるかと思います。
     ただ、同じようなケースを抱えてる方にとっては、反面教師になる部分を含めて、お役に立てたのではないでしょうか。

     もう一つの質問も含め、私には、とても勉強になりました。

     人力検索にも良い回答者がいらっしゃることが分かって、長年の愛好者としては、これも嬉しい発見でした。
     おつきあい下さった皆様、ありがとうございました!

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません