phpのcURLでPOODLE対策に嵌った
SSL 3.0の脆弱性「POODLE」。
見つかったのは去年の秋が終る頃だったかな？
ちょっとよく覚えてないですけど、とにかくそのころ見つかって、対策なんかも色々と紹介されてたりしてたのって結構覚えている人も多いと思うんですけど、これ絡みの問題でハマったので今回はその話。
って言っても、脆弱性をついた攻撃を受けたとかではなく、以下の様な感じ。
先日、ある決済サービスから「POODLE 対応のために SSL 3.0 での通信を遮断する対応を行う」という通知が来ました。
なので、「TLSなどを使って通信するようにしてくれ」って話だと理解。
この手の話は昨年末あたりから色々なところから言われていたり、自分たちのサーバーでも通信を遮断する対応を行っていたので、今回問題が起こったサーバーに関しても他のシステムとの通信自体は確認していたので「はいはい」と言う感じで流していました。
が、その決済サービスに関しては、POODLE対応が実施されたと思われる時間帯から、全く通信が出来なくなったのです...
現象としては、完全に接続を拒否されているような状態で、ヘッダーとかも何も返ってこないような状態。
原因は暗号スイート(cipher) だったのですが、ここまでたどり着くのにかなり時間が係ってしまいました。
一般的に、クライアント側で行う POODLE対策としては単純に SSLv3 ではなく TLS などで接続するようにすればよいだけで、この対応であれば他のシステムとの接続で問題なかったので特に対応は必要ないと考えていたのですが、問題が発生したサービスは SSLv3 を無効化するだけではなく使用する暗号スイートまで限定していたようで、そことのマッチングが原因だったようです。
まぁ、これはこちらのシステムが古すぎるせいもあると思います、比較的新しい環境からなら問題なかったので。
とにかく、普通に curl を使うと先方が許可している暗号スイートを利用してくれないので接続できない。
ただ、curl コマンドでは接続できないけど、openssl コマンドで接続を試すとできる...
？
なんで？
っとなって、phpinfo() の結果をよく見てみると、どうやら openssl ではなくて NSS を利用しているらしい...
うーん、もう何だか良く分からないので色々と試行錯誤していたのですが、NSS の Cipher Suite の一覧はここで確認できたので参考に以下のような感じでテスト。
$ curl https://<接続先のホスト> --ciphers rsa_aes_128_sha
--ciphers を付けないと接続できない意味が分からないのですが、curlコマンド自体は上記の様にオプションで指定したら接続できました。
さて、では php のcURL を使った場合はどうなのか？って話。
結論から書くと下記の様に指定すると接続できました。
curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, 'rsa_aes_128_sha');
CURLOPT_SSL_CIPHER_LIST の説明を php のマニュアルで見ると
SSL で使用する暗号のリスト。例えば RC4-SHA および TLSv1 が 使用可能です。
と言ったような感じで、分かったような分からないような説明が書いてあり、そこには NSS の Cipher Suite は書いてありませんけど指定は出来るようですね・・・
本来ならサーバー自体を新しい環境で構築しなおして移植するのがベストなんでしょうけど、そうもいかない事って多々あるので、ちょっとハマりました。
まぁ、かなり限定されたシチュエーションでしか発生しない問題だとは思いますが・・・
コメント