_ 注: わしゃ暗号は素人です。
_ ここ最近の流れ。
こんな感じで CBC でないストリーム暗号の RC4 を使うべき的な風潮になってきたところで、今月になって RC4 にも穴(*1)が発表されてちゃぶ台をひっくりかえされる。ということで、安全な設定について考える。Apache mod_ssl で。
- 2011/9 BEAST: CBC モードの暗号はうまいことごにょごにょすると解読されやすくなるよ
- 2012/9 CRIME: 圧縮機能を使うと解読されやすくなるよ
- 2013/2 Lucky 13: CBC モードの暗号はうまいことごにょごにょすると解読されやすくなるよ
_ えーと、まず、RC4 については現時点ではどうしようもない(?)っぽいので、捨てる方向で考える。先月まではとりあえず RC4 を強制しとけ、でも許されたんだけれど、これからはそれじゃダメ。CBC モードの暗号を安全に使うように考えないといけない。
_ BEAST attack については TLSv1.1 以降(openssl 1.0.1 以降)であれば問題ないそうな。SSLv3、TLSv1 でも、openssl では 2002年の 0.9.6d で 対策されてるそうな。穴が見つかるずっと前のことで時系列がなんかおかしいけど、とにかくそういうことらしい。既知の手法をいくつか組み合わせて洗練させた攻撃らしいので、その既知の手法をちゃんとふさいでいれば安全、ということなのかな？
_ CRIME attack は圧縮をしなければいいだけの話。が、mod_ssl で SSLCompression off の設定ができるのは 2.2.24、2.4.3 以降で、要するに最新版が必須。以前 SSLRequire でなんとかする設定を試してみたら、うまいことネゴって圧縮しないようにしてくれるわけではなく、圧縮してたらつながらなくするという残念なもので使いものにならなかった。今調べてみたら RedHat 系の openssl には環境変数で圧縮をやめさせるパッチが当たってるらしいので、それを利用して回避することもできそうだが、RedHat 以外では使えない。Debian 系では SSLCompression がバックポートされてるらしい。
_ Lucky 13 は OpenSSL 最新版で対策されたのでこれに入れ替える。入れ替えなくても GCM とか CCM とかの AEAD な方式(←それっぽいキーワードを列挙してみただけで中身はあまり理解していない)を使うことで回避できるけど、これらは TLSv1 では使えない(= 喋れないブラウザが多い)ので、現時点では完全な対策にはならない。
_ 以上まとめると、まず、設定だけじゃどうにもならないので、apache と openssl は最新版に入れ替える。その上で以下の設定をする。
SSLCipherSuite の ECDHE-RSA-AES128-SHA256 と AES128-GCM-SHA256 は このへんをパクってみたものだけど、TLSv1.2 な暗号形式でブラウザが対応してないので事実上意味なし。あとは mod_ssl のデフォルト(HIGH:MEDIUM:!aNULL:!MD5)に RC4 禁止を追加しただけ。ちなみに mod_ssl のデフォルトというのは 2.2.22(?)から変更になっていて、それより前のバージョンよりもだいぶ固くなってる。SSLProtocol all -SSLv2 # SSLv3、TLSv1.[012] SSLCompression off # 圧縮しない SSLHonorCipherOrder On # ネゴるときにクライアントではなくサーバの設定を優先 SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:MEDIUM:!aNULL:!MD5:!RC4_ この設定で SSL Server Testにかけてみると、BEAST attack に対して INSECURE と判定されるが、これは前述のとおり大昔に openssl が対策済みなので気にしなくてもいい、はず、だよね、たぶん、きっと。誰か教えて。それ以外の点についてはかなり高いスコアになるので、まあ大丈夫なんじゃないかなー (*2)。
_ いちおう念のため。脆弱性があるからといってすぐに解読されるわけではない。理論上考えられていたよりはかなり弱くなって現実的な時間で解読される危険性は高まったものの、それでも平文よりははるかに解読困難であることにはかわりない。危険であるという認識は持ってないといけないけど。
_ まだ花粉が飛んでるというのに。もう7月になってたのか。今年は夏が早いな。
_ 今回の 重複なんだけどさぁ、なにこれ。workaround が #define HAVE_REGEX_H を #undef しろ、って。はあ？ 正規表現？ なんで？
_ ソースを読むと、 NAPTRの RDATA に書かれる正規表現をチェックするところに問題があったらしい。NAPTR が正規表現を使うって初めて知ったよ…。apple.com 以外に NAPTR を書いてるところを見たことないし。現象としては これとか これとかと同じ。つまり、実は BIND 自体のバグではなく、OS 標準のバグありライブラリをそのまま使ってるのが原因ということ。BIND は責任転嫁せず自分の穴だと認めたのはむしろ潔い。
_ が、やっぱおかしいだろ。DNS なんてただの入れ物にすぎなくて、値の解釈をするのは DNS を利用するアプリの仕事だろ。DNS サーバは正規表現が壊れてようがどうしようが気にせず応答するのが仕事だ。値を解釈することは期待されてないのに、よけいなことをしたあげくにコケるとかどういうこっちゃ。named-checkzone でゾーンファイルの文法チェックするところでやるのであればまだ理解できなくもないんだが、named の中でやる理由がさっぱりわからん。場所が libdns の中なので、named ではなくライブラリが勝手にやってるんだ、と強弁できなくもないけど、でもやっぱりいらん処理でしょ。
_ 実際、9.6 までのバージョンが今回の脆弱性の対象外なのは正規表現チェックが実装される前だったからだし、今回の修正もその正規表現チェックをしないようにしている(ただし、ソースの方は穴ありバージョンとまったく変わらず、configure で regex.h を探さないようにするだけという手抜き)。この正規表現チェックしないというというのが正しい実装だと思うんだけど、9.9.3b2 を見ると該当箇所を OS の正規表現ライブラリを使わないように書き直してバリデーションが復活してる。だから何でそんなよけいなことするんだってばよ。
_ まあ、BIND が値をチェックしてもしなくても、NAPTR を聞くアプリ(ってどんなのがあるの？)が結局この正規表現の脆弱性を踏むだろうことは容易に想像できるわけだが。NAPTR は使っちゃダメってことだな要するに。
_ Spamhaus/Cloudflare への DNS ampの件に関して、まあキャッシュサーバの対策もそうなんだけど、最近は権威サーバも DNS amp の踏み台にされることが多いので対応しなきゃダメだよね。ということで、まだろくに日本語情報のない RRL をネタにしようかと思ったけど、そう思った矢先に オレンジさんから解説が出てきたので、その気が失せた:-)。
_ …というのはあんまりなので、少しだけ。
_ RRL の導入効果。Afilias (.org とか .info とかのレジストリ)が RRL を導入したら、外向きのトラフィックが 2.3Gbps から 70Mbps に落ちたという 報告が。というか、RRL の効果よりも amp だけで 2Gbps も吐いてたんかい、というそっちの方が衝撃だったわけだが。聞くところによると、ほかにもいくつかの ccTLD がすでに RRL を導入済みらしい。
_ で、うちでは先月出た NSD 3.2.15 を使って RRL がすでに動いてたり。ふだんヒマしてるサーバなので、
とかなり厳しめの設定が入ってる(同じ名前を1秒あたり10回聞くとアウト)。rrl-ratelimit: 10と叩くとかんたんにひっかかるのでお試しくださいませ。同じ名前を100個並列で dig させるけど、そのうちのいくつかは RRL の制限にひっかかってタイムアウトするはず。また、制限を受けずに応答が得られたものも、よく見るとそのうちのいくつかは tc フラグつきの応答(= TCP で聞き直せ)になってるのが確認できると思う。% yes chigumaya.jp | head -100 | xargs -n1 -P100 dig @ns.maya.st +norec +ignore +tries=1 +noall +comments