自堕落な技術者の日記

2015年5月12日に、IPAのサイトでCRYPTRECのWGで作成した 「SSL/TLS暗号設定ガイドライン」が公開されました。

このSS/TLS設定ガイドラインが作成された背景や概要は菊池先生の CRYPTRECシンポジウム2015での 講演資料にわかりやすく書いてありますので、これをご覧頂くのが 一番よいかと思います。

このガイドラインはサーバー管理者向けに、 なるべく暗号のことは細かく触れずに、 (とはいえ細かい暗号の話も多いですが、、、) 昨年度、特に多かったSSL/TLS関連の様々な脆弱性に対して、 どのように設定すればいいのかを解説しています。 紹介されているコラムなど読み物としてもなかなかおもしろいので、 是非ご覧いただければと思います。

ガイドラインでは、用途に応じて3つのタイプに分けて設定を紹介しています。

• 政府・金融・医療など高いセキュリティが求められる場合の設定→高セキュリティ型
• 一般的な推奨設定→推奨セキュリティ型
• 古いブラウザ、ゲーム機、フィーチャーフォンなどへの対応も必要な場合→セキュリティ例外型

特に暗号スイートやプロトコルの設定を、昨今の脆弱性・暗号危殆化に照らして どのように設定するのかというのが、管理者のみなさん悩ましいところだと思うのですが、 これを巻末のAppendixにて、具体的にどのサーバーではどう設定すればよいのかを 記載しています。

ただ、あれを全部読んで動く設定ファイルを作るのってページ数も多いし結構骨が折れるかなと思います。 そこで、ガイドラインの公開を記念して、 ガイドラインのタイプやサーバーの種類を選んで、ボタンを押せば設定ファイルが 作れるようなツールを作ってみました。(ぱちぱちぱち)

HTTPS設定ファイル生成ツール0.2(ベータ版)
https://kjur.github.io/jsrsasign/tool/tool_httpscfg.html

今のところ、Apacheとnginxだけだったり、推奨設定の一部だけだったりするんですが、 プロトコルや暗号スイートなどは押さえているので、よかったら使ってみてください。

字は小さいですが、スマホブラウザでも設定ファイルが作れます。ぼちぼちアップデートして フル対応にしますので、乞うご期待ってことで。

あと、このツールの面白いのはCRYPTREC/IPAのガイドラインだけでなく、 MozillaやQualysなどの推奨設定や、Linux系OSのデフォルト設定も 試せるようになっている所です。暗号スイートの設定みてニヤニヤしていただければと、、、

今日はこの辺で、、、

(追記 2021.03.25) ツールのリンク切れを修正しました。

先日の記事のコメント欄に Apache TomcatでもSSL/TLSのプロトコルバージョンを指定できると 教えて頂き、どのバージョンはどの設定なの？みたいな話が、 Google先生に聞いてもよくわからなかったので、 幾つかのバージョンのTomcatを取り出してプロトコルバージョンの設定 方法を確認してみました。

具体的には、Oracle J2SE JDKの1.7.0_71で、 いろいろなバージョンのTomcatについて、 openssl s_clientコマンドでプロトコルバージョンを指定しながら 確認していきます。 それぞれの確認結果はこんな感じ。

6.0.37までのprotocols属性はマニュアルには書かれていない 隠し属性だったみたいですね。6.0.39からなんでパタッと変えたんですかねぇ。 普通なら後方互換性を持たせてprotocolsとsslEnabledProtocolsの両方を 使えるようにすればいいのに、ばっさり、protocolsを切っちゃうのはどうだったんですかねぇ。 せめて6.0.xでは一貫してprotocolsを使うようにした方がよかったんじゃないですかねぇ？

いや〜、今年は脆弱性対策が当たり年ですね〜〜(トホホ)。 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 さん、ありがとうございました。

JavaでSSL/TLS通信をしたい時に通常はJSSE(Java Secure Socket Extension)という仕組み使うんですが、これ使えば、実装色々切り替えたり、追加したりなんてことができます。Apache Tomcat(+Sun Java JSSE)だとCamellia系のCipherSuitesに対応してないそうで、何か対応してるもの、追加で対応できそうなものを調べてみました。

Sun Javaで使えるJSSEってあんまり選択肢がないのね

下の例のようにJSSEプロバイダ名を指定することによりJSSEを切り替えればいろんなSSLエンジンを試せるわけですが、

SSLContext ctx = SSLContext.getInstance(アルゴリズム名, プロバイダ名);
SSLContext ctx = SSLContext.getInstance("SSL", "SunJSSE");
SSLContext ctx = SSLContext.getInstance("TLS", "HarmonyJSSE");

• Sun(Oracle) - SunJSSE
• RSA - RSA BSAFE SSL-J Toolkit
• IAIK - IAIK iSaSiLk Toolkit

なんか調べてみるとJSSEはJava VMに依存している方が多いんじゃないかって 感じがします。

• IBM Java - IBM JSSE
• GNU classpath - JESSIE (オープンソース)
• Apache Harmony - HarmonyJSSE (BouncyCastle JCEベース)

Apache HarmonyとTomcatを試してみる

Apahce HarmonyのSSL/TLSの機能というか、JSSEの機能は暗号ライブラリとしてBouncyCastle JCE Libraryを使用しており、SunJCEは使えません。 従ってHTTPSのためのSSLサーバー証明書と鍵はJKS形式はSun独自の形式なので使えなくてBouncyCastle JCEがサポートしている PKCS#12かBKS(BouncyCastle Key Store)形式を使う必要があります。 ただ、OpenSSLで生成したPKCS#12でやってみたところMacエラーだったりで読み込めず BKSを使うのがよいのかもしれません。 JKSからBKSへの変換ツールは「ここ」に置いてみたので使ってみてください。

conf/server.xmlファイルにはこんな感じでkeystoreFile、keystorePass 、keystoreTypeを設定します。

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
 maxThreads="150" scheme="https" secure="true"
 clientAuth="false" sslProtocol="TLS"
 keystoreFile="conf/zzz.bks"
 keystorePass="changeit"
 keystoreType="BKS" />

set CATALINA_HOME=C:\Java\apache-tomcat-6.0.30-wharmony
set JAVA_HOME=C:\harmony-6.0-jdk-991881
set JRE_HOME=C:\harmony-6.0-jdk-991881\jre

で、OpenSSLで繋いでみる

openssl s_client機能を使ってApache Tomcat + Harmonyのサーバーに接続してみましょう。

% openssl s_client -host zzz.com -port 8443
CONNECTED(00000003)
depth=1 /C=JP/O=HOGE
verify error:num=19:self signed certificate in certificate chain
verify return:0
14052:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:209:
14052:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:s3_clnt.c:1447:

% openssl s_client -host zzz.com -port 8443 -cipher 'ALL:!kEDH'
CONNECTED(00000003)
中略
depth=1 /C=JP/O=HOGE
verify error:num=19:self signed certificate in certificate chain
verify return:0
read R BLOCK
DONE

Apache HarmonyのJSSEのコード

Apache HarmonyのJSSEはjre/lib/boot/x-net{.jar,-src.jar}にある org.apache.harmony.xnet.provider.jsse パッケージがそれに当たります。 x-net.jar自体はコード署名されてないようなので、 CipherSuiteを追加し放題で x-net.jarに入れ替えても動きそうな雰囲気です。

JSSEプロバイダの定義はJSSEProvider.javaにあります。 コメントのところに割と詳しい説明があって以下のようなものが書かれています。

• サポートしているCipherSuites：別表
• 使用する共通鍵暗号アルゴリズム：IDEA,RC2,RC4,DES,3DES
• 使用するMacアルゴリズム:MD5, SHA-1
• 使用する鍵交換アルゴリズム: RSA, DH, DHE

SSLContext = TLS(=TLSv1)
KeyManagementFactory = X509
TrustManagementFactory = X509

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_WITH_DES_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA