_ んーと、MITM によって、攻撃者が強制的に強度の弱い暗号を使わせるようにすることができる、という直球ド真ん中のダウングレード攻撃ということかな？ とはいえ、おそらくクライアント/サーバがサポートしない暗号を使わせることまではできないだろうから、平文(eNULL)まで弱くなるということはないような気がする。つまり apache でいえば、SSLCipherSuite HIGH:MEDIUM と設定してある場合、この脆弱性を突いて HIGH じゃなくて MEDIUM な暗号を使わせるようにすることはできても、LOW な暗号にさせることはできないんじゃないかということ。
_ ……あ、いや、違う？ もしかして鍵交換に介入して共通鍵を奪われちゃう？ だとすれば、どんな暗号アルゴリズムでも自由に復号できちゃうから、攻撃者が通信内容を完全に把握できちゃうな。どうなんだろ。うーん、よくわからんな。あとでちゃんと調べておこう。
_ ま、とりあえず、今回のは発動条件がクライアント、サーバともに脆弱な場合のみなんで影響は意外と小さそう。openssl ってサーバ側ではよく使われるけど、クライアント側でのシェアははっきりいってひじょーに小さいので。通常のブラウザで HTTPS なサイトにアクセスするぶんにはほぼ影響なし。lynx とか w3m とか wget とか curl とかスクリプト言語の SSL なライブラリで HTTPS なサイトにアクセスしているとヤバいけど、それぐらいか？ メールの場合は、SMTP/POP/IMAP の STARTTLS/STLS はもともとプロトコルの仕様上今回の脆弱性の方法よりもっと簡単な MITM 攻撃で平文通信させることができるので今さら騒いでも意味はなく(HTTP/1.1 の Upgrade: も同様)、SMTPS/POP3S/IMAPS は可能性あるけど MUA がたいてい openssl を使ってないので影響なし。fetchmail とか getmail とかそのぐらい？ あとは LDAPS とかヤバそうだけど、あんなの外に晒してる人いないでしょ。…対応しなくていいと言ってるわけではないので念のため。
_ どーでもいいけど、
てな感じで、大量のアクセスをさばけるようにこの脆弱性の案内サイトだけ CDN に外注して強化してるあたりが、今回の件で会社の名を上げようという強い意思を感じます:-)ccsinjection.lepidum.co.jp. 300 IN CNAME d1iec0qksshyc8.cloudfront.net.
_ さらに調べたり入れ替えたり。MITM な攻撃者に鍵を盗まれるというより、攻撃者が準備しておいた鍵を使うように仕向けることができる、という脆弱性の模様。つまり、信頼できない通信路上で SSL を使って保護したつもりでも中身がバレバレになっちゃうかもよ、ということで。
_ バグの根本的な原因は OpenSSL の最初からあったらしいけど(もしかしたら OpenSSL が fork する前の SSLeay の時代からだったりする？)、実際に脆弱性が発現するきっかけとなったのは openssl 1.0.1 の NPN 拡張のサポートのようだ。ソースの修正箇所とか詳しく追いかけてはいないけど、脆弱性のあるバージョンでも NPN 拡張を使わないようにコンパイルすれば MITM できなくなるという 話が。…あれ、もしかして、HTTP2 とか SPDY とかで遊ぶために openssl に NPN パッチを当ててると、1.0.1 じゃなくてもサーバ側の穴を踏むんじゃね？ この手の気の早い遊びをやってるサイトは注意した方がいいかも。
SMTP/POP/IMAP の STARTTLS/STLS はもともとプロトコルの仕様上今回の脆弱性の方法よりもっと簡単な MITM 攻撃で平文通信させることができるというところについて。_ SMTP の STARTTLS ってのは、まず通常の SMTP で平文接続をしてからネゴして TLS 通信に入る、という手順を踏む。なので、ネゴが終わって TLS になった後で今回の脆弱性を狙うことはもちろん可能。しかし、それよりももっと単純に、平文でネゴしている部分に「いや、うちのサーバは TLS なんかサポートしてないし」という偽造応答を MITM な攻撃者が割り込ませることができれば、そもそも TLS になることもなく通常の平文のまま通信するので、攻撃者は簡単に通信を盗むことができる。TLS なら通信の改竄を検知できるけど、これは TLS に移行する前の改竄なので通信当事者が検知することができない。SMTP にかぎらず、平文で通信を開始してからネゴによって TLS に移行するプロトコルはぜんぶこれで攻撃できる。
_ ただし、通信相手が TLS に対応している、という知識が事前にある場合は、TLS へのネゴに失敗した時点で通信を止めることで回避は可能。submission や pop3 などは、不特定のサーバに接続するわけではないので、TLS 以外はぜったいに使わないという設定をしておけばよい。MX を調べて不特定のサーバにメールを配送する MTA は、相手サーバについてのそのような知識を事前に入手することができず、STARTTLS のネゴに失敗してる理由が攻撃されてるせいなのかほんとに TLS をサポートしていないせいなのかを判別できないので、STARTTLS は飾り。ぶっちゃけぜんぜん信用できないので、HTTPS なんかと違って SMTP の STARTTLS はオレオレ証明書でも警告とか出さず平気で送りつけるのがあたりまえ。
_ さて、HTTP2 なんだけど。SSL が必須とかオプションだとか、URL は http:// だとか https:// だとか http2:// だとか、何ヶ月か放置してから最新の仕様を見ると毎度変わってるような感じなんだけどどうなるんですかね。HTTP2 は動きが早くて追いかけるのを諦めたので、現在どっちの方向に向かってるのかよくわかってないんだけど、もし URL が http:// のままで SSL を使えるようにする仕様がもし正式になってしまった場合、とーぜん平文か SSL かのネゴが必要になるのでこの問題にブチ当たるはず。実際のところはよく知らんので、確定したら教えてください。あんなコロコロ変わる仕様を追いかけるのは、それ自体を仕事にするかよほどのヒマ人かどっちかじゃないと無理。