自堕落な技術者の日記

いやぁ、年の瀬ですねぇ。最近、SSL/TLS関連の調査に全く時間が取れてないっす。 SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 10月に引き続き2015年12月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましょう。 今月は、なかなかデータ公開が早かったっぽいですが、気づくのに遅れました。

SPDYが下がっています。HTTP/2への移行が始まっています。実はSSL PulseでHTTP/2の対応状況も4ヶ月前あたりから取れるようになっているので、そろそろ可視化したいと思っています。

DH鍵交換のサポート率は、ほぼ横ばいであるのに対して、

ECDH(E)への対応は進んでいることがわかります。

年末進行で、そんなに呑みに行っている気もしませんが、なんか仕事が山積みですorz コメント少なめですみません。今月はこの辺で。

• SSL Pulseの統計情報でみるSSL/TLSの引越しについて (2016.04.10)
• SSL Pulseの統計情報で見るSSL/TLS (2015年12月版) (2015.12.16)
• SSL Pulseの統計情報で見るSSL/TLS (2015年10月版) (2015.10.24)
• SSL Pulseの統計情報で見るSSL/TLS (2015年8月版) (2015.08.12)
• SSL Pulseの統計情報で見るSSL/TLS (2015年6月版) (2015.06.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 8月に引き続き2015年10月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましょう。 今月は、なかなかデータ公開してくれなくて、確か10月19日頃ようやくアップデートされたようです。新しい項目増えているわけでもないのに、なんででしょうね。

RC4の利用可能率が順調に継続して下がっており、今月では53%のサイトしか使えなくなりました。 また、ECDHEやDHEの鍵交換をサポートするPFSに対応したサイトは71.5%にまで上がっており、かなりのサーバーで使えるようになってきました。

POODLEの影響でSSLv3が使えるサイトが32.5%にまで下がっています。

Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、今月も順調にSHA2移行が進んでおりSHA1withRSAが24.1%、SHA256withRSAが74.9%まで進んでいます。あと残り1/4になりましたね〜〜〜。

HSTSも、OCSP Staplingも、EVも徐々に上がっていますが、全く大したことない。

鍵交換の鍵長は順調に、512bit、1024bitの利用をやめ、2048bit相当に移行が進んでいるようですが、、、

DH鍵交換をサポートしないサイトが48.2%もあり、暗号強度が十分でないDH1024bitも減ってはいるものの、28.9%もあり、いろんな意見はあるでしょうが、DH(E)は使わずにECDH(E)を使うのが良いのではと思います。

ECDH/ECDHEが使えていないサイトが34.2%にまで減り、ECC 256bitを使えるサイトが61.9%にまで増えています。かなり普及してきたという感があり、「何も考えずにとりあえずECDHE使えるようにしとけ！」と思います。

講演資料2本作らないとマジでやばす。今日はこの辺で。

• SSL Pulseの統計情報で見るSSL/TLS (2015年8月版) (2015.08.12)
• SSL Pulseの統計情報で見るSSL/TLS (2015年6月版) (2015.06.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 6月に引き続き今月も8月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましょう。

RC4の利用可能率が順調に下がっているなど、おおむね順調な感じがしますね。つまらん。

POODLEの影響でSSLv3の無効化が35.0%まで順調に下がっています。これもつまらん。

Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、今月も順調にSHA2移行が進んでおりSHA1withRSAが31.9%、SHA256withRSAが67.2%まで進んでいます。

う〜む、これもつまらん。

鍵交換の鍵長は順調に、512bit、1024bitの利用をやめ、2048bit相当に移行が進んでいます。

暗号強度の十分でないDH1024bit、512bitの利用は順調に減り、2048bitは増えていますが、そうはいっても大した率でなく、やはりDH/DHEは使わないのが良いと思います。

ECDH/ECDHEが使えていないサイトが順調に減り、使えるサイトが増えており、ECC 256bitのECDH/ECDHEが使えるサイトが58.5%まで増えています。

今週は、セキュリティ・キャンプ全国大会に来ているので、あっさり風味で。

• SSL Pulseの統計情報で見るSSL/TLS (2015年6月版) (2015.06.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 5月に引き続き6月のSSL PulseでのSSL/TLSの状況推移をグラフ化してみましょう。 本当は隔月にしようと思ってたんですが、Logjamの影響が見たかったので今月はやってしまいました。 (ウソ、今月はやらなくて良い月だったのに忘れててグラフを作ってしまっただけですorz )

POODLEの影響でSSLv3の無効化が順調に下がっており、サポートするサイトは37.6%までに減りました。

Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、SHA1とSHA2証明書の比率が5月に逆転しましたが、順調にSHA2移行が進み、SHA2が60%、SHA1が40%まできていることがわかります。

OCSP stapling対応率は伸びかかったのにまた戻ってしまいました。

鍵交換の情報が3月から取れるようになり、ようやく傾向がつかめるようになってきています。

弱い輸出グレードのDH(E)鍵のダウングレードによるLogjam脆弱性が5月に公表されたことで、全体的にDH鍵交換の鍵長が増えていますが、とは言っても2、3%の変化しかなく、 やはりDH鍵交換の鍵長を増やすよう設定するよりも、DH鍵交換は使わず、ECDH系の鍵交換を使うのが良いように思います。

Logjam脆弱性の発見者の一人であるMatthew Green先生のブログによると、この攻撃を成功させるには中間者がハンドシェイク中の十分短い時間でDH鍵の解読をしなければならないそうですが、ある鍵パラメーターについて事前計算をしておけばこれは可能であり、512bitなら一般的な環境でも数十秒で解くことは可能であり、1024bitの場合、一般的な環境では無理かもしれないがNSAのような諜報機関であれば、その予算と比較して全く不可能という値でもないということです。怖いですね〜〜〜。

ECDH系の鍵交換を使えるサイトと、使えないサイトの比率が5月に逆転しましたが、ECC 256bitの利用が順調に進んでいていることがわかります。

来週月曜はJNSAの勉強会なので、早く資料作らんといかんなぁ。しかし、おぎゃ〜さんは、ものすごい集客力だなぁ。

• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 3月に引き続き5月のSSL PulseでのSSL/TLSの状況推移をグラフ化してみましょう。 隔月で見ていけたらと思っています（＾＾；

POODLEの影響でSSLv3の無効化が順調に下がっており、サポートするサイトは40%までに減りました。

Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、SHA1とSHA2証明書の比率が逆転しました。今月のグラフで最も特徴的な事かと思います。

OCSP stapling対応率は順調に伸びていますが。大したことはありません。

鍵交換の情報が3月から取れるようになり、ようやく傾向がつかめるようになってきています。

DH鍵交換に対応するサイトはわずかながら増えていますが、2048bitだけでなく、安全でないとされる1024bitも増えていること、またそれ以上に安全でない512bitが使われていることは非常に問題です。このような傾向からも、DH鍵交換の鍵長を増やすよう設定するよりも、DH鍵交換は使わず、ECDH系の鍵交換を使うのが良いように思います。

先日ブログに書いたTLSの実装と導入上の推奨をまとめたRFC 7525の4.4節にもDH鍵交換の課題が整理されており、RFC 7525では「使うな」とは言っていませんが、これを読むとDH系の鍵交換は使うべきではないように思います。

ECDH系の鍵交換を使えるサイトと、使えないサイトの比率が逆転し、ECDH系の鍵交換への対応が半数を超えてきました。ECDH系鍵交換を使えない比率の減り方がDHに比べて顕著です。

なんか今週末はブログラッシュっすね。メッセージ入りSSLサーバー証明書の件が書けなかったなぁ。今日はこの辺で。

• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 1月に引き続き3月のSSL PulseでのSSL/TLSの状況推移をグラフ化してみましょう。

2015年3月より、以下のデータを追加で観測するようになりました。

• POODLE攻撃の緩和策としてGoogleからインターネットドラフトが出され、 Google Chrome、OpenSSLの最新版などでは対応している TLS_FALLBACK_SCSVのサポート状況
• 通信障害等によるOCSPレスポンダへのアクセス不能により、失効した証明書のサイトにつながってしまったり、認証局が利用者のサイト訪問記録を取得しないように導入されたOCSP staplingのサポート状況
• 鍵交換の際の最低鍵長(DC、ECDHに分けた値もあるが円グラフ表示はされてない)

今月からPOODLE攻撃を緩和する「TLS_FALLBACK_SCSVをサポートしていない率」の情報が追加されています。45%近いサイトが対応しているようです。

POODLEの影響でSSLv3の無効化が順調に下がっていますが、下がり方が鈍化しているようです。

Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、順調にSHA1からSHA2証明書への移行が進んでいていて、SHA2が42%、SHA1が57%ともう少しでクロスしそうな所まで来ています。

今月からOCSP staplingのサポート状況がグラフに記載されるようになりました。20%のサイトがOCSP staplingに対応しているようです。意外と多いなという印象です。

SSL Pulseで鍵交換の最低鍵長が今月から表示されるようになりました。 証明書はRSA 2048bit以上の証明書になっているので、 グラフ中の2048bitはRSAで鍵交換しているケース、 1024bitおよび512bitはDH(Diffie-Hellman)かDHEで鍵交換しているケース、 であると言えます。NISTの暗号アルゴリズム移行のガイドラインによれば、 鍵長1024bit以下のRSA、DH、DSAなどの共通鍵暗号は使ってはならないことになっており、 DH、DHEを使った暗号スイートが使えるサイトはかなりあり、 あえてDH、DHEを使うのは安全ではないことはよくわかります。 サーバー側で止めたり充分な鍵長となる設定をしていないので、 クライアント側で配慮するしかないのでは？という気がしています。 特に、PFS(Perfect Forward Secrecy)のために、DH、DHEを使おうとする 傾向がありますが、そのような場合にはECDH、ECDHEを選択するべきだと思います。

このグラフを見ても明らかな事に、DH、DHEでは十分な安全性を持たない鍵長1024bitか512bitがほとんどであることがわかります。 怖いですね〜〜。このグラフはSSL Pulseのサイトでは見られない値になっています(つまり、データだけある)。

ECDH、ECDHEが使える場合にはほとんどが鍵長256bit(RSA 3076bit相当)になっており、 一般に安心して利用できることがわかります。 go.jpドメインの調査でも 紹介したように571bitのECC鍵が少し使われていることも驚きます。256bit未満だと224bit、163bitがごくわずかに使われており、192bitが無いということも意外でした。 このグラフも、SSL Pulseのサイトでは見られない値になっています(つまり、データだけある)。

以上、今月のSSL Pulseのデータからいろんな推移を見てみました。 今日はこの辺で。

• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

前にもお話した通り、 SSL Pulse (https://www.trustworthyinternet.org/ssl-pulse/)サイトは、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 以前、2014年11月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましたが、 2ヶ月たってどうなったのか、また今月もグラフ化してみました。

BEAST対応(CBC対応?)を除いて、全体的に順調に良くなる方向にあります。 悪い状態が上、良い状態が下になるようにグラフを統一したので、見やすくなったかと思いますが、どうですかね。

このあたりは、どれも普及が10%未満のままだと、、、

• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

先週のInternet Week 2014でHTTPSサーバー設定の話をさせて頂きました。お越し頂いた方、ありがとうございました。マニアックな内容だったのですが、何か参考になる所があれば嬉しいです。

さて、今日はパネルネタで仕込んでおいたのに陽の目を見なかった話をちょっとブログで書こうと思います。SSL/TLS関連で統計データみたいなものを出しているサイトが幾つかあって、そこから世の中の傾向がわかったり、それを元に自分のサーバーはどう設定するかなぁ、などと考えるのに役に立つのではと思い紹介したいと思います。

SSL Pulse

まず最初に紹介したいのがSSL Pulseというサイトです。

出典：SSL Pulse https://www.trustworthyinternet.org/ssl-pulse/
このサイトSSL Pulse (https://www.trustworthyinternet.org/ssl-pulse/) はssllabsでも有名なQualys社が 運営しているサイトで、Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しているもので、以下のような情報を公開しています。

• サーバー設定強度ランクA〜F
• プロトコルバージョン状況(SSLv3, TLSv1.2等)
• サーバー証明書の状況(SHA2対応、鍵長)
• 最近の脆弱性の対応率(HeartBleed, BEAST, CRIME, RC4等)

https://www.trustworthyinternet.org/asset/project/ssl-pulse/data/index.json
https://www.trustworthyinternet.org/asset/project/ssl-pulse/data/ssl-pulse_2014-11.json

SSL Pulse: SSLプロトコルバージョン推移

これは、2012年4月からのSSL/TLSのプロトコルバージョンの推移です。

• ずっとSSLv3、TLSv1.0はほぼ100%のサポートだったが、 2014年10月に発見されたPOODLE攻撃の影響でSSLv3が60%にまで下がった。
• TLSv1.1、TLSv1.2は順調にのびているが、まだ50%程度しかない。
• SSLv2を使っているサイトが、未だ20%近くある。

SSL Pulse: SSL脆弱性の対応推移

今年はSSL/TLSに関しても脆弱性の当たり年でしたが、脆弱性への対応の推移をまとめてみました。 元データのせいで評価の仕方が「対応してる率」なのか「してない率」なのかバラバラで、本当は統一できればよかったんですが、わかりにくくてすみません。

• HeartBleedについては重大な問題だったためか発生直後で大多数が対応しているようだ。
• CCSInjectionについても対応率が高いが影響自体が少なかったせいかもしれない。
• 再ネゴシエーション攻撃についても対応率が高く残り数%の所まできている。
• CRIME、TIMEなどSSL圧縮による攻撃の影響を受けるSSL圧縮を無効化していない サイトも数%までに現象した。
• スノーデンの告白でわかったNSAなどの大量監視から身を守る Perfect Forward Secrecy対応のため、ECDHE、DHEの暗号スイートを使えないサイトは 40%程度まで減ってきており対応がかなり進んだ。
• ストリーム暗号RC4の危殆化と、Microsoft製品がRC4アルゴリズムの利用を 無効化した影響か、RC4アルゴリズムを使えないサイトが20%ぐらいと徐々に 増えているが未だRC4を使えるサイトは80%もある。
• BEAST、BREACH、POODLE攻撃などに影響のあるCBCブロック暗号モードを 利用可能なサイトは一時現象傾向を見せたが、RC4停止と逆にCBCが増えており、 CBCの利用可能は80%近くまで戻している。レガシー環境では暗号スイートは 3DES-CBCかRC4の2択しかないが、Microsoftが利用停止した影響もあり、 BEAST攻撃対策をあきらめてRC4対策を取るという傾向にあるようだ。

SSL Pulse: サーバー証明書の署名アルゴリズム推移

Microsoft や Google のブラウザが、SHA1withRSA署名アルゴリズムの証明書のサポートを2017年1月には打ち切るとしており、サーバー管理者の方はSHA256withRSAなどの証明書の移行をそろそろ検討しなければならないかと思います。 サイバートラスト社のサイトでMicrosoft、Google、Firefox、CABForumのSHA1証明書対応をとてもわかりやすくまとめておられるのでご覧になると良いと思います。 では、署名アルゴリズムの移行についても見てみましょう。

• 2014年6月以降、90%→75%と急激にSHA1withRSA証明書が減っている。
• 逆にSHA256withRSA証明書は10%→25%と急激に増えている。
• SHA256withECDSA証明書はなかなか利用がすすまずほぼ0%で横ばい。

SSL Pulse: SSLの先進機能の利用推移

EV証明書が先進機能かどうかはさておき、HTTPS関係の先進機能の利用状況推移について見てみましょう。

• 先進機能はどれも10%に満たない。
• EV証明書も増えてはいるが2年で8%→10%と微増
• SPDYサポートも6%程度
• 通信をHTTPS強制化するHSTS(HTTP Strict Transport Security) もわずか2%で増えているという感じでもない

SANS SSL CRL Activity

セキュリティ教育機関であるSANS Instituteの SSL CRL Activity (https://isc.sans.edu/crls.html) というページで、サイトを閉鎖する時とか鍵が盗まれたなどでSSLサーバー証明書を失効させた場合の失効件数を、全ての認証局について毎日集計をして、公表しています。大きな攻撃があった時や、認証局に何らかの問題があった時に大量の失効が発生することがあります。2002年からと、かなり昔から情報収集をしています。

表示する期間を好きなように設定して表示させることができます。

まずは、2002年から現在までの失効数推移をみてみましょう。

2014年に突如70,000件もの大量失効があったのはHeartBleed脆弱性の問題の影響です。では、それまでの 推移をみてみましょう。HeartBleed脆弱性の前は、概ね単純に増加しているのみであり、SSLサーバー証明書の利用者も順調にのびており、1日千件程度の失効になってきていました。

大量失効の前後を中心にみてみると以下のようになっています。

GlobalSignが2014年4月16日、17日、証明書を大量失効させたのが一因のようです。HeartBleed後はCCSInjectionやPOODLEの影響と思われる失効のピークが見られます。

ChromeのHTTPS通信の比率の推移

おわりに

以上、Internet Weekのパネルで紹介しようかなぁと思ったけどボツになったネタを紹介させていただきました。こりゃ、話はじめると長い話になっちゃうので、パネルで触れなくて結局は正解だったんですかね。グラフにしてみると何がどんな風に変化しているのかわかって楽しいですよね。今日はこんなところでw

関連リンク

• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS
• Internet Week 2014パネルで話しそびれたネタ2: イントラ内でSSLサーバー設定を確認するツールsslaudit
• Internet Week 2014 S14 講演2「サーバの正しいSSL/TLS設定のツボ」補足情報ページ

POODLE攻撃は、運用泣かせというか、SSLv3のサポートを本当に切っちゃっていいのか、レガシークライアントについて対応するのがいいのか、悩む所ですよね。ShellShock騒ぎさえまだうちでは収束していないのに・・・

POODLE攻撃は、「SSLv3の問題であってTLSv1.0以上では(パディングの方法が違うので)影響が無い」とされていますが、nahiさんからコメントもらって「実装依存だけどTLSv1.0でも危険な実装があるんじゃないの？」ということで、その事を書いてみたいと思います。

今回のPOODLE攻撃については、何が問題でどのようにすれば攻撃できるのかという、詳しい図入りの素晴らしく判りやすい解説をモバゲーさんが 「SSL v3.0の脆弱性「POODLE」ってかわいい名前だけど何？？ - Padding Oracle On Downgraded Legacy Encryptionの仕組み -」でされているので、そちらをご覧になると良いと思います。

SSL/TLSでAESや3DESなどのブロック暗号を使った場合には、暗号化するデータはブロックの大きさの整数倍、つまり、AES-256なら32バイト、AES-128なら16バイト、3DESなら24バイトの倍数でないといけません。で、その大きさに揃うようにパディングと呼ばれる隙間の詰め物をして倍数になるように調整するわけです。

例えば、暗号スイートとして、AES-128(16バイト)、SHA1(20バイト)を使っているとして、8バイトのデータを暗号化するとしましょう。パディングした暗号化するための入力は

平文(8)＋HmacSHA1メッセージ認証コード(20)＋パディング(3)+パディング長(1)＝AESブロック長(16)×2

さて、SSLv3とTLSv1.0のパディング方法の違いですが、

• SSLv3の場合はパディングの値は任意の値を取れる
• TLSv1.0の場合はパディングはPKCS#5パディング方式を用い、 具体的にはパディング値の各バイトはパディング長と同じ値が設定される。

パディング(3)+パディング長
[a0][f3][62][03] - SSLv3の場合(先頭3バイトは任意)
[03][03][03][03] - TLSv1.0の場合(先頭3バイトはバイト長と同じ値)

今日の本題のTLSv1.0なら本当に安全なのか、という話なんですが、 とりあえず、TLSv1.1とTLSv1.0のパディングに関する規定を 見てみましょう。

まず、TLSv1.1についてですが、

RFC 4346 TLSv1.1 6.2.3.2 CBC Block Cipherより
padding
Padding that is added to force the length of the plaintext to be an integral multiple of the block cipher's block length. The padding MAY be any length up to 255 bytes, as long as it results in the TLSCiphertext.length being an integral multiple of the block length. Lengths longer than necessary might be desirable to frustrate attacks on a protocol that are based on analysis of the lengths of exchanged messages. Each uint8 in the padding data vector MUST be filled with the padding length value. The receiver MUST check this padding and SHOULD use the bad_record_mac alert to indicate padding errors.

一方、TLSv1.0です。

RFC 2246 TLSv1.0 6.2.3.2 CBC Block Cipher より
padding
Padding that is added to force the length of the plaintext to be an integral multiple of the block cipher's block length. The padding may be any length up to 255 bytes long, as long as it results in the TLSCiphertext.length being an integral multiple of the block length. Lengths longer than necessary might be desirable to frustrate attacks on a protocol based on analysis of the lengths of exchanged messages. Each uint8 in the padding data vector must be filled with the padding length value.

TLSv1.0では、「パディングデータはパディング長で埋められなければならない。」 と書いてありますが、 TLSv1.1では、「 パディングデータはパディング長で埋められなければならない(MUST)。 受信者はこのパディングをチェックしなければならず(MUST)、 パディングエラーを示すにはbad_record_macアラートを使う べきである(SHOULD)。」 となっています。 つまり、TLSv1.0ではパディングデータがちゃんとパディング長の値で うめられているかどうかのチェックはmustとは書いてあり、 多くの実装はちゃんとしてくれていると思いますが、 RFC上の必須要件(MUST)ではないので、チェックしない実装があっても おかしくなく、 チェックされない場合、これではSSLv3と同じで、一般的なSSL/TLSの実装では MUSTと書かれていない事は実装する必要もないので (実際、SHOULDと書いてあれば、これに対応しない実装も多い)、 実装によってはパディング値のチェックをしないために、 SSLv3と同じくPOODLE攻撃の影響を受けるTLSv1.0実装がある可能性がある かもしれないという事です。

時間がある時に、ちょっと主要なオープンソースの実装を覗いてみようと思います。

今日はこの辺で。nahiさん、情報ありがとうございました。

• 2014.10.26 OpenSSL 1.0.1jについてソースを見て問題ない事が確認できました。 「(続き1)POODLE攻撃について本当にTLSv1.0なら安全なのか？(OpenSSLは安全)」

いや〜、今年は脆弱性対策が当たり年ですね〜〜(トホホ)。 bash ShellShockの対策も継続して観察しているなか、 新しいPOODLEというSSLv3プロトコルに関する脆弱性が出てしまいました。 子犬のプードルだって！可愛くないっつ〜〜の！！ SSLv3プロトコルのパディングの問題点を突いて、効率的に暗号文を 復号できしまうので、例えばセッションクッキーを復号して通信を盗聴することが できるのだそうです。 POODLEはPadding Oracle On Downgraded Legacy Encryptionの略だそうで、 パディングオラクルとはパディングを含む暗号文を入力として送りつけると、 そのパティングが正しいかどうかを返してくれるブラックボックスのような 計算機のこと。 SSLv3みたいなできて15年にもなる弱い暗号通信プロトコルに、 強制的にダウングレードさせて、 オラクルに対して何回もいろいろ入力を変えて試行して、 エラーメッセージなどどう反応するかを見る事で、 暗号文の解読が効率良く行えるという攻撃です。

気がついたまでの経緯は当日どんな感じだったかというと、日本時間で10月14日の23:30頃、 The Registerの「NASTY SSL 3.0 vuln to be revealed soon」の記事を見つけていまい、こりゃ、やばげだなと。知り合いに明日ヤバイのがまた来そうと連絡しました。TLS 1.0とSSL 3.0とバージョン番号が違うだけだと言い張る人も多い中、Macとか、パディングとかそのちょっとの違いが仇になるんじゃないかと、ずっと気になってたんですが、とうとう来たかと。詳細情報は夜が明けないとわからないので、半分 wktk しながら寝て待ってたんですが、朝になって、Googleのブログ 「This POODLE bites: exploiting the SSL 3.0 fallback」が出てきたものの、わかったことはプードルという可愛らしい攻撃の名前と、GoogleサイトとChromeはとっくにTLS_FALLBACK_SCSVに対応しているぜ！みたいな。 自慢かっ？技術詳細なく自慢だけなのかっ！と憤りつつ、しばらく待ってると、 やっと安定のImperialVioletで 「POODLE attacks on SSLv3 (14 Oct 2014)」 技術解説が出たのを見て、こりゃマジやべ〜〜な、と・・・ その後、情報のとりまとめにいそしんでおりました。

この記事では、様々なHTTPSサーバーに対するPOODLE脆弱性対策の 方法について、まとめておきたいと思います。

古いガラケーや、一部のゲーム機や、古い環境でのAPI利用などを除いて、 一般のブラウザであればSSLv3でしか通信できないという事は無いので、 SSLv3を無効化するというのが、一番正当なPOODLE対策であると思います。 この章では、SSLv3を無効にするために、 サーバーのソフトウェア毎にどのように設定すればよいかをまとめます。

httpd.confやssl.confに

SSLProtocol All -SSLv2 -SSLv3

nss.confもしくはhttpd.confで

NSSProtocol TLSv1.0,TLSv1.1

ssl_protocols TLSv1 TLSv1.1 TLSv1.2

lighttpd 1.4.28 以降を使用。それ以前ではSSLv3を無効化できません。

ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"

コマンドラインで以下を実行することで、レジストリ設定により無効化します。 (参考 [1] [2] [3])

reg add "HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Tomcatの設定ファイル "server.xml"の"Connector"要素において、 Tomcatのバージョンに依存して、 sslEnabledProtocols属性もしくはprotocols属性に 使用するプロトコルをSSLv3を除いたTLSv1、TLSv1.1、TLSv1.2 を設定することにより、 SSLv3での接続を無効化することができます。 (参考 [4])

<Connector port="8443" protocol="HTTP/1.1"
  SSLEnabled="true" maxThreads="150" 
  scheme="https" secure="true"
  clientAuth="false"
  keystoreFile="/etc/tomcat/server.jks"
  keystorePass="password"
  sslProtocol="TLS"
  protocols="TLSv1,TLSv1.1,TLSv1.2"/>

<Connector port="8443" protocol="HTTP/1.1"
  SSLEnabled="true" maxThreads="150" 
  scheme="https" secure="true"
  clientAuth="false"
  keystoreFile="/etc/tomcat/server.jks"
  keystorePass="password"
  sslProtocol="TLS"
  sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"/>

Tomcat同様これもインターネット直出ししている事はないと思いますが 以下の実装例のようにsecureOptionsでSSLv2,SSLv3を使用しないよう設定が可能です。 (参考 [6])

var constants = require('constants')
  , https = require('https')
  , path = require('path')
  , tls = require('tls')
  , fs = require('fs');
https.createServer({
  secureProtocol: 'SSLv23_method',
  secureOptions: (constants.SSL_OP_NO_SSLv3 | constants.SSL_OP_NO_SSLv2),
  cert: fs.readFileSync(path.join(__dirname, 'ssl', 'server.crt')),
  key: fs.readFileSync(path.join(__dirname, 'ssl', 'server.key')),
}, function (req, res) {
  res.end('works');
}).listen(443);

アドバイザリ が公開されています。httpd.confで以下のように設定し、サーバーを再起動します。

<VirtualHost *:443>
SSLEnable
SSLProtocolDisable SSLv2 SSLv3
その他の設定
</VirtualHost>

AWSから セキュリティアドバイザリが公開されており何度もアップデートされています。 利用するサービスによってそれぞれ対策が必要です。

その他のサーバーについては、以下を参考にしてみてください。

• ask ubuntu: How do I patch/workaround SSLv3 POODLE vulnerability (CVE--2014--3566)? - とても参考になります。Postfix SMTP, Sendmail, Dovecot, Courier-imap, HAProxy Server, OpenVPN, Puppetなど、特にメール関連サーバーはこちらを参考にしてみて下さい。

現在サポートされているPCやスマートフォンのブラウザではTLSv1.0以降 がサポートされているので問題にならないと思いますが、 例えば、2007年秋以前のdocomoのガラケーやSONY PS3では、SSLv3しかサポート していないことを実機で確認しています。 古いガラケー、ゲーム機、組込み機器に対応するウェブサーバーを 運用する場合には、接続できずクレームになる可能性もありますので、 クライアント側の対応環境を確認すると良いと思います。

また、ウェブサーバーをAPIで利用する場合にも、どのような環境、 言語実装を使うかで問題があるケースがありますので、 確認しておくと良いと思います。TwitterやFacebookも API利用されているためにトラブルになったそうです。

• しばやん雑記: Twitter や Facebook が SSL 3.0 を無効にしたので死にかけた話 (2014.10.15)

OpenLDAPについてはslapd.confを以下のように設定します。 (参考 [?])

バージョン 2.4.36以降の場合
TLSProtocolMin 3.1
バージョン 2.4.14〜2.4.35の場合
TLSProtocolMin 769

一般的なブラウザに関してはSSLv3を無効化する方向で進んでおり、 ウェブサイトでもSSLv3を無効化するのが、正しい対応だと思いますが、 古い環境をサポートしなければならないために、SSLv3を有効に しておかなければならないケースもあると思います。 3章では、SSLv3をサポートしなければならないケースでの、 脆弱性の緩和策について説明したいと思います。

POODLE脆弱性はSSLv3とブロック暗号のCBCブロックモードを使用した 場合に影響があるので、暗号スイートとして以下を選択することで 問題を緩和することができます。

• 認証付暗号化方式(AEAD)であるGCMブロックモードの暗号スイートを使用する
• ストリーム暗号(RC4,ChaChaなど)を使用する

RC4ストリーム暗号は、現実的な時間内に部分的に解読することが 可能な危殆化した暗号で使用すべきでないとされていますが、 POODLE脆弱性は適用条件や解読にかかる手間が極端に少ないので、 Triple DESをCBCモードで使うよりもRC4の方が、まだ安全であると 言えます。

• TLS_RSA_WITH_3DES_EDE_CBC_SHA を含む全ての暗号スイートを無効化
• その上で、TLS_RSA_WITH_RC4_128_SHA のみを有効化
• 同時に新しめのクライアントも環境もサポートしたいならGCMの暗号スイートを有効にする

ただし、マイクロソフト製品では2014年8月のアップデート以降、RC4は無効になっていますので、 Windows系のサーバー機を使用する場合には、Apacheなど他のサーバーを使う必要があるでしょう。

SSL/TLSで通信を開始した直後はTLSv1.0以上で問題ない接続であったとしても、 ある種の攻撃により脆弱なSSLv3.0以下にダウングレードさせる攻撃があります。

これを、防ぐための新しく提案されている仕組みが TLS_FALLBACK_SCSV オプションを使う方法です。これをサーバーとクライアントの双方が サポートする場合、TLSからSSLv3.0以下に強制ダウングレードさせることは できなくなります。

ただ、これをサポートしている環境は現時点(2014.10.18)では非常に限定的です。

• クライアント
  • Google Chromeのみ
• サーバー
  • 最新の2014.10.15リリースのOpenSSL 1.0.1j/1.0.0o/0.9.8zcを利用するApache,Nginx,Lighttpdなどのサーバー
  • Google提供のサービス(2014年2月頃からサポートしていたらしい)

• CBCブロック暗号モードをどうしても使う必要があり、
• TLSで最初接続できた利用者にはSSLv3ダウングレードせず安全に使用して欲しい。
• SSLv3で接続してきた利用者にはリスクを承知でCBCモードで接続してもらってもよい。

自分なりにケース毎の対応策(案)を整理してみました。よかったら参考にしてください。

表について、少し補足したいと思います。対策としては、SSLv3を無効にするのが基本的な対策となりますが、SSLv3を残しておく必要がある場合に、幾つかのケースに分類してみました。

一番良いのは、やはり(ケース2-1)のようにTLSv1.xのサーバーと、SSLv3のサーバーとを分ける事であるように思います。最近のウェブアプリケーションではHTML5、JavaScript、CSSなどリッチコンテンツが増えて、そうしたモダンなブラウザ向けのサービスと、SSLv3しかサポートしないサービスとを分けることで、互いに安全に利用することができます。

どうしても1台のサーバーでモダンなブラウザのユーザと、SSLv3のみにしか対応しないユーザに 対応する必要がある場合には、(ケース2-2)のように、CBCモードを使うことをあきらめ、モダンなブラウザユーザは TLSv1.xをGCMモードで接続することになり、GCMモードに対応できないユーザは、弱い暗号であるRC4のリスクを 受容して利用してもらうことになります。例えば、以下の順序で暗号スイートを設定するのが良いでしょう。

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA
• TLS_RSA_WITH_RC4_128_SHA

以上、SSLサーバーでPOODLE脆弱性対応をする方法について、いろいろなサーバー 毎にまとめてみました。参考になればうれしいです。今日は、こんなとこで。

SSLv3のパディングについては、いろいろ勉強したので、近いうちに記事にできるといいなと思っています。

• 2014.10.19 IBM HTTP Server, AWS, 対応策(案)の整理について追記しました。
• 2014.10.22 OpenLDAP ついて追記しました。
• 2014.10.28 Apache Tomcatの設定についてコメント頂きましたので、 実際に調査をし、 記述を修正しました。コメント頂きましたuraさん、takeshiさん、Youngdong.lee さん、ありがとうございました。