シャノンでは、通信の秘密を守るために日夜SSL関連のチューニングを怠らなようにしてます。
チューニングの結果を外部診断して確認する手段としてQualys SSL LABSの「SSL Server Test」を活用しています。SSLサイトチェックの定番です（よね？）。ここでA評価をもらう事が一つの安全の指標といえるのではないでしょうか。
シャノンのサービスではもちろんA評価です。皆様に安心にご利用して頂くため、日々セキュリティアップデートがあれば対応を続け、A評価を保ち続けます。（ただし利便性を損なう設定がA評価に必要な場合は要検討となります）
今回はApacheをインストールしてから、Qualys SSL LABSでA評価を貰えるまでの道のりを説明していきたいと思います。
■コピペでOK？ コンフィグのジェネレーターを活用してみる
Aランクを取る方法はとっても簡単。3ステップでOkです。
https://mozilla.github.io/server-side-tls/ssl-config-generator/
１：上記サイトにアクセスして
２：生成されたコンフィグをサーバにコピペして
３：Apacheを再起動
A+評価！
このサイトはmozillaが公開している、良い感じのSSLコンフィグの生成するサイトです。これを利用すると簡単にA評価を取ることができます。が、それでは何がどうなって、どうして安全かという説明が出来ません。
また、このサイトのIntermediateやModern の設定は非常にセキュリティ的には強固な設定になりますが、ブラウザサポートを考慮していません。基本的には最新物、アップデートされているものだけ、パッチがあったって居ない人からのアクセスは考慮していない、レガシー何それ？というような優しい世界の産物になります。
Qualys SSL LABSのチェックでは、様々なクライアントの初期設定からのSSLハンドシェイクのシミュレーションを行い、対応しているブラウザや対応していないブラウザについて一覧で表記されるようになっています。
先ほどのジェネレーターで生成したコンフィグの場合、Android4.3以下、Win7/IE10以下、java6/java7/openssl0.9.8系からの接続ができない事がシミュレーション結果として表示されています。
これでは、セキュリティはA+だとしてもサイトのサポート状況としてはあまり良いものとは言えないでしょう。
[Protocolo or ciper suite mismatch]と表記されている箇所は接続できないクライアント
■Apache + mod_sslの初期設定からAランクを目指してみる
今回はCentOS6系で試してみましょう。まずはapacheとmod_sslをインストールします。
- 検証環境
CentOS release 6.7 (Final)
httpd-2.2.15-47.el6.centos.1.x86_64
mod_ssl-2.2.15-47.el6.centos.1.x86_64
今回チューニングするディレクティブは二つあります。
SSLProtocol と SSLCipherSuite です。
この二つの設定を変更することで、対応するプロトコル（SSLv3/TLSv1等）と暗号スイート（鍵交換＿署名＿暗号化＿ハッシュ関数 の組み合せと対応表）が変わってきます。
初期設定は以下の通りでした
SSLProtocol all -SSLv2 SSLCipherSuite DEFAULT:!EXP:!SSLv2:!DES:!IDEA:!SEED:+3DES
まずはこの状態でQualys SSL LABSにかけるとどうなるでしょうか。
そうですね。Cランクになりました。では、解消していきましょう。解消していくポイントについてもQualys SSL LABSは表示してくれているので1個ずつ見ていきましょう。
■POODLEは可愛くない
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.
はい。POODLE（CVE-2014-3566）さんです。ちょうど昨年の年末頃に騒いでいた問題ですね。
参考
http://jvndb.jvn.jp/ja/contents/2014/JVNDB-2014-004670.html
https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack
この問題に対応するためにはSSLv3を無効化にする事がまずはじめにやるべきことです。SSLProtocolを以下のように変えてみましょう
SSLProtocol all -SSLv2 -SSLv3
これにより、SSLv3が無効化されました。（デフォルト設定でSSLv2については無効化済み）SSLv3が無効化された場合は、openssl1.0.1以降のサーバであれば、TLSv.1.0/TLSv.1.1/TLSv.1.2が対応プロトコルとなり、openssl1.0.0未満であれば（0.9.8系も同様）TLSv.1.0のみが対応となります。
■no more RC4
This server accepts RC4 cipher, but only with older protocol versions.
かつて、BEAST攻撃が発見された時にAESを含むブロック暗号をCBCモードで行った場合に脆弱であると発表され、その際に対策の一つとしてRC4を使うことが推奨されました。色々と議論は有りましたが現在ではRC4は危険とハッキリ報告されていますのでこの考えは止めたほうが良いです。
http://www.rc4nomore.com/
RC4がいま問題視されている理由としては上記サイトに書いてあります。
・RC4に対する攻撃は、TLS通信の場合で2000時間以上もかかっていたが機器を使った研究者の実証では52時間で攻撃に成功した（cookieの解読）
・cookie以外の暗号化された情報も解読できるほか、「WPA-TKIP」による無線LANの暗号化通信も影響を受ける
・この問題を解決する唯一の方法はRC4を使わないこと
とあります。
つまりRC4を利用することは現実的な脅威にさらされる事になります。RC4は使わないようにしましょう。
SSLCipherSuite DEFAULT:!EXP:!SSLv2:!DES:!IDEA:!SEED:+3DES:!RC4
!をつけて設定することで、対象の暗号が無効化されます。ここでは!RC4と書いたので、RC4が無効化されます。
■PFS 対応を考えた Logjam 対策
The server does not support Forward Secrecy with the reference browsers.
Diffie-Hellman（DH）鍵交換の脆弱性で、TLS接続の強度を意図的にダウングレード出来てしまう問題があります。（通称Logjam(CVE-2015-4000)）この問題を対応するためには大きく二つの対応方法があります。
１：512bitの暗号サポートを解除し、1024bit以上を強制する
２：Diffie-Hellman（DH）鍵交換を止める
１の対策には問題点があり、私はあまり推奨していません。理由としては大学研究機関規模の計算リソースがあれば 768bit、国家規模の計算リソースがあれば 1024bitまでは現実的に計算可能な範囲に含められる可能性があると指摘されています（参考：https://weakdh.org/）
では、2048bit以上を強制すれば良いのか？ということなのですが、これはこれでまた問題が出てきます。まずは、Apacheのバージョンは2.2.30以降でなければ2048bit以上にする事ができない事。次に仮に最新バージョンのApacheを利用し、DH 2048bitを優先できた場合でも、java6からのアクセスができなくなってしまう事です。
APIを開放していサービスを運用していると色々なクライアントからの接続を受け付ける必要があります。その中のユーザエージェントでも意外と多いのがjava6を利用したレガシーシステムからのリクエストがあります。これらのリクエスト遮断してしまうと、お客様のビジネスに対して価値が届かなくなってしまうので良くない対策と考えています。
Apacheの2.2.26以降であればECDHE（楕円曲線ディフィー・
SSLCipherSuite DEFAULT:!EXP:!SSLv2:!DES:!IDEA:!SEED:+3DES:!RC4:!DH SSLHonorCipherOrder On
RC4の時と同様にDHを無効化設定を追加します。合わせてSSLHonorCipherOrder を有効にします。通常設定ではクライアント側からの暗号スイート提案が優先されますが、SLHonorCipherOrder をOnにする事でSSLネゴシエーションの際に暗号の選択をサーバ側で決定するようになります。この設定を有効にすることで、SSLダウングレード攻撃を防ぐことができます。
ここまで設定を変えてみて現状のQualys SSL LABSの評価はどうなったか見てみましょう。
来ましたA評価！
今回、Apacheのインストールから最短でA評価もらうまでの設定変更を紹介していきましたが、本当は暗号スイートとプロトコルは環境に合わせて最適なものを設定する方が良いです。例えば、接続するクライアントが決まっているようであれば、そのクライアントにあわせて暗号スイートの強度を最大にしてみたり、httpを開放していて常にhttpsへリダイレクトするようなサイトであれば、HSTSヘッダをレスポンスしたり、色々な対策やチューニング方法が考えられます。
今回はあくまで初期設定からA評価をもらうまでの最短経路を紹介しただけですので、これが最適とは言えません。
例えば明示的にMD5を無効化設定にした方が良いですし、（MD5はSSLv3とセットになっているため、一緒に無効化される）スイートのDEFAULTに何が含まれているのか等知っておく必要があると思います。自分で設定している暗号スイートがどういうものか把握していないと、新しい脆弱性が報告された際にすぐに対策することができない可能性もあるかもしれません。
シャノンでも常にセキュリティを担保しつつ、お客様の利便性を損なわないような設定を常日頃から模索しながらチューニングしていっています。セキュリティを高めすぎてしまい、本当は使えるはずの人が使えなくなるようでは意味がありません。
- セキュリティは人の為にある
- セキュリティは１日してならず
という事を心がけ日々サイトの安全性を保ち続けたいと思います。こんなセキュリティチューニングに興味がある方はぜひ
http://www.green-japan.com/job/37651
にアクセスして、ボクと握手！（採用目的）
■番外編その１：SSLチューニングする時の便利なツール
私がSSL周りのチューニングする際によく使うツールがあります。https://github.com/jvehent/cipherscan
opensslコマンドのクライアントモードで対象に接続し、対象のサイトのcipherをチェックする事ができるツールです。これにより俯瞰して現在の設定を見ることが出来ます。また、設定変更した後にキチンと意図した変更になっているかを確認する事ができます。
実行結果のサンプル
$ ./cipherscan <対象のサイト> ................. Target: <対象のサイト>:443 prio ciphersuite protocols pfs curves 1 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1 2 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1 3 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1 4 AES256-GCM-SHA384 TLSv1.2 None None 5 AES256-SHA256 TLSv1.2 None None 6 AES256-SHA TLSv1,TLSv1.1,TLSv1.2 None None 7 CAMELLIA256-SHA TLSv1,TLSv1.1,TLSv1.2 None None 8 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1 9 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1 10 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1 11 AES128-GCM-SHA256 TLSv1.2 None None 12 AES128-SHA256 TLSv1.2 None None 13 AES128-SHA TLSv1,TLSv1.1,TLSv1.2 None None 14 CAMELLIA128-SHA TLSv1,TLSv1.1,TLSv1.2 None None 15 ECDHE-RSA-DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1 16 DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 None None Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature TLS ticket lifetime hint: 300 OCSP stapling: not supported Cipher ordering: server Fallbacks required: big-SSLv3 config not supported, connection failed big-TLSv1.0 no fallback req, connected: TLSv1 ECDHE-RSA-AES256-SHA big-TLSv1.1 no fallback req, connected: TLSv1.1 ECDHE-RSA-AES256-SHA big-TLSv1.2 no fallback req, connected: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
対応している暗号スイート一覧の情報が表示される。この結果を見ながらチューニングを行うと見通しが非常に良いです。
■番外編その２：TLS1.0は死んでしまうのか？
ジェネレーターで生成したコンフィグで設定したサイトの場合はA+評価になっていました。では、この + が付くか付かないかの差はどこで付くかという所ですが、一つあるのがTLS1.0の有効、無効で差がついてきます。（＋HSTSヘッダの有無）
TLSv1.0が有効な場合、BEAST攻撃やLucky13攻撃に対して特定の条件下で脆弱であることが分かっています。この状況をうけてPCI-DSSの最新バージョン（3.1）では、TLS1.0を非推奨としました。
（参考：https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf）
・SSL 3.0およびTLS 1.0の使用を非推奨（新規の場合は禁止）
・2016年6月30日までに移行計画を策定及び実行し、
また、Quakys SSL LABSのサイトでもTLS1.2が無効の場合はペナルティが設けられるなどTLS 1.0オワコン風潮が高まってきているようです。TLS 1.1以降に対応していないクライアントは多々あるため、これからPCI準拠のクレジットカード決済システム周りで接続できない等、2016年はまた色々とセキュリティのスタンダートってなんだ？というような議論が続いてくようです。
俺達の戦いはこれからだ！
という感じで、皆様セキュリティ対策にお疲れになり過ぎないよう良いお年をお過ごしください。
