自堕落な技術者の日記

2014年11月頃から、SSLに関する統計情報を公開しているサイトSSL Pulseのデータから推移情報をブログで公開してきました。隔月で更新するようなことを言ってて、2015年12月から更新が無い状態になっており、「コラ〜〜！サボってんじゃね〜〜」的なことを思われたかたもいらっしゃるかもしれません。すみません。すみません。すみません。

新しいサイト

サイトを移行した経緯など、、、

前は、エクセルなど駆使してグラフ描いてたんですが、そりゃもう、結構手間がかってたんですよ。自分も興味があって毎月すぐ知りたいんだけど、とても、毎月はできないなと、、、ざっくりとした流れはこんな感じ：

• 今月のデータファイル(JSON)をwgetでダウンロードする
• データの推移をTSV形式になるように変換するツールを実行する。グラフに必要なデータ列もこの時作る。
• TSVファイルをUTF-16にする(Mac Excel対策)
• Excelで読み込み
• データを細かい整形(日付フォーマットや表ヘッダなど)
• 必要なグラフを作る
• グラフをEMF(拡張メタファイル)でエクスポートする
• PowerPointに吹き出し等を貼り付け(位置調整)
• PowerPointの画面を画像キャプチャし、ブログへ

そして、一つ一つグラフを作っていくわけです。

で、Excelのグラフの凡例ではちょっと見づらいのでパワポで吹き出しをつけます。

どうです？結構面倒くさそうでしょう？

で、新しいサイトでは

とにかくExcelでグラフをつくるのはやめにしたく、JavaScriptベースでグラフを描けないもんかと、調べてみました。最初は、ccchartなんかがデザインも良いかなぁと考えていたんですが、思っていたデザインにするのは、至難の技であると知り、D3.jsという有名なライブラリも見たんですが、一つのフツーのグラフ書くのに多くのコードを書かねばならず断念。D3.jsを簡単に使うためのラッパーがあるそうで、それを幾つか見て、rickshawで何とか許せるグラフが描けたのでそれを使うことにしました。

本当は、SSL Pulseに置いてあるJSON形式のデータファイルをそのまま、表示の度に取り込んで加工してからグラフ表示しようとしたんですが、諸々CORSの壁に阻まれ断念。動的にダウンロードする必要もなくなり、スタティックな解析データをNodeで作って、SOURCEタグで普通にデータ取り込むことになりました。

ブログでたまたまSSL Pulseについて書くだけなら、特別な断りをいれなくてもいいかと思ったんですが、定常的に今後は英語でもページを公開するとなると、SSL Pulseの作者のIvan Ristićさんに仁義というか確認取っといたほうがいいかなと思いました。IvanさんはSSL/TLSの技術解説書の中では最高に良いと思うBulletproof SSL and TLSの著者であり、SSLの設定評価サイトであるssllabsの開発などもしています。

Bulletproof SSL and TLS [ペーパーバック]

Ivan Ristic

Lightning Source Inc

2014-08

Rickshawの使い方は概ねこんな感じです。

<div id="chart_container"><div id="grade_chart"></div></div>

<script>
var graph = new Rickshaw.Graph({
  element: グラフを描くキャンバスが挿入されるDIVのDOM,
  width: グラフ幅,
  height: グラフ高,
  renderer: グラフ形式(棒グラフとか折れ線グラフとか),
  series: [{"color": グラフデータ色,
            "name": データ名(TLS1.2とかSHA256withRSAとかデータ名),
            "data": [{x: 値, y: 値}, {x: 値, y: 値} ...]},
            : (複数のデータがあれば続く)
          ]
});
graph.render();
</script>

RickshawUtilGraph(グラフ描くDOM IDの共通ヘッド(グラフや凡例、XY軸など),
                  グラフの共通テンプレート,
                  データ(グラフデータ、データ名)
                  [,オプションでグラフ形式を変えたい場合のパラメータ]
                  [,オプションでグラフ色変えたい場合のパラメータ]);

というわけで、まだ素っ気ないページですが日本語ページ公開にこぎつけました。今までなかった評価グレード(A-F)の分布推移のグラフはNPNのHTTP/2サポートプロトコルの推移のグラフも付け加わっています。

しばらくしたら英語ページの作成にとりかかりたいと思います。

今後とも、よろしくお願いします。

• 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)

前回はTLSv1.1以降とTLSv1.0とでパディング処理に関するRFC上の規定が違うのでPOODLE攻撃の影響を受ける実装があるのではないか、という話をしました。

影響を受ける可能性が高いのはTLSv1.0と、TLSv1.1やTLSv1.2とで パディング処理の実装を区別しているケースでは影響をうける可能性があります。

OpenSSLの最新のもの1.0.1jについて、ソースを見てました。 結論から言うと、TLSv1.xではPOODLEへの影響が無い事が確認できました。

OpenSSLのソースコードでは、sslディレクトリの下に SSL/TLS関係のコードがまとめられており、大まかに、

• s3_*.c SSLv3(or TLSv1.x)のコード
• d1_*.c DTLSv1のコード
• t1_*.c TLSv1.xのコード

• ssl3_cbc_remove_padding
• tls1_cbc_remove_padding

# to_check：チェックが必要なパディングバイト数
# padding_length：パディング長の値バイト
# b：チェック対象の値バイト
for (i = 0; i < to_check; i++)
  {
  unsigned char mask = constant_time_ge_8(padding_length, i);
  unsigned char b = rec->data[rec->length-1-i];
  /* The final |padding_length+1| bytes should all have the value
   * |padding_length|. Therefore the XOR should be zero. */
   # XORを取ってゼロならばパディング長の値バイトと対象は一致
   good &= ~(mask&(padding_length ^ b));
  }

とりあえずOpenSSLについては、こんな所で。

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 さん、ありがとうございました。