安全な SSL/TLS 設定にするための10のポイント（Apache httpd 2.4）

Apache httpd をパッケージやソースからインストールしたときに配置される初期状態の SSL/TLS 設定ファイルでは、古いブラウザも含め幅広いクライアントに対応できるように SSL/TLS の設定をしてくれています。しかし、ここ近年 SSL/TLS に対する攻撃手法が多く見つかっているため、ある程度セキュリティに配慮した SSL/TLS の設定が求められています。そこで今回は、Apache httpd バージョン2.4 を安全かつパフォーマンスにも配慮した SSL/TLS の設定にするためのポイントをまとめてみました。

適切な鍵長の秘密鍵を利用する
適切な認証局(CA)の選択
DNS CAA レコードを登録する
（重要）安全な SSL/TLS プロトコルの設定
適切な暗号スイートの設定
サーバーが暗号スイートを選択する
HSTS の設定
SSL/TLSセッションキャッシュの適切な設定
OCSPステープリングの設定
SSL Server Test（SSL Labs）でチェックする
おわりに

適切な鍵長の秘密鍵を利用する

SSL/TLS の一番の目的は通信を暗号化して、サーバーとクライアント間のやりとりを安全にすることです。そして安全の尺度となる暗号化強度は「鍵のアルゴリズム」と「鍵の長さ」によって決まります。鍵の長さはビット数で表します。

現在 SSL/TLS で安全に使える鍵のアルゴリズムは RSA と ECDSA（ECC、楕円曲線暗号とも呼ばれます）の２つです。2017年9月時点では、RSA鍵の場合は 2048 ビット、ECDSA鍵なら 256 ビットの鍵を使えば十分な暗号化強度を得られます。

暗号強度	共通鍵暗号方式	RSA	ECDSA
組織的なごく短時間の攻撃に対する保護	80	1024	160
中期間（20年）の攻撃に対する保護	112	2048	224
長期間（30年）の攻撃に対する保護	128	3072	256
長期間の攻撃に対する保護と量子コンピュータに対する防御	256	15360	512

（参考資料）
ECRYPT II Report on Key Sizes (2012)
NIST Special Publication 800-57 Part 1（P63）

現在普及している RSA鍵よりも、ECDSA鍵の方が暗号化強度が強くパフォーマンスも良いのですが、ECDSAに対応していない認証局(CA)もありますので、現時点では 2048ビットのRSA鍵を使うのが手頃でしょう。

適切な認証局(CA)の選択

認証局WoSign/StartComが発行した証明書の信頼取り消しやシマンテックの証明書誤発行など、ここ最近認証局(CA)関連のトラブルが続いています。

適切な認証局(CA)を選択するのはなかなか難しいのですが、次のような「新しい技術を積極的に採用していること」を基準とするのが認証局(CA)を選ぶひとつのポイントです。

SHA256証明書を発行（これは必須です）
ECDSA（ECC）証明書に対応
DNS CAA に対応

（2017年9月17日追記）
Google は認証局の最大手シマンテックが業界標準の監査プロセスに従わなかったとして、シマンテックが発行した証明書の信頼を段階的に削除し Google Chrome 70（2018年10月リリース予定）で完全に削除すると発表しました。既にシマンテックは証明書の発行や運用業務をDigiCert社に売却し、2017年12月1日までにDigiCertのインフラに移行するとしています。
Chrome’s Plan to Distrust Symantec Certificates | Google Security Blog

これまで「シマンテックのSSL/TLS証明書なら大手なので安心ですよ！」とよく提案していた私は、肩身のせまい思いをしています(^^;) 大手だからといって安心せずに認証局(CA)は慎重に選びましょう。

DNS CAA レコードを登録する

「DNS CAA」は、認証局が証明書を誤発行してしまうことを防ぐための仕組みです。すべての認証局が DNS CAA に対応すれば、ドメイン所有者がSSL/TLS証明書を発行できる認証局を完全にコントロールすることができます。

現在 DNS CAA レコードはほとんど普及していませんが、CA/ブラウザフォーラム（CAB Forum）は、認証局に対して2017年9月8日以降は証明書を発行する際に CAAレコードを確認することを義務付けています。大手DNSサービスも DNS CAA レコードの登録への対応を始めていますので、おそらく今後は普及していくでしょう。

（重要）安全な SSL/TLS プロトコルの設定

安全でない SSL2.0 と SSL3.0 プロトコルを無効にします。初期設定では SSL3.0 が有効になっていることが多いので必ず設定しましょう。

SSLProtocol all -SSLv2
　↓
SSLProtocol all -SSLv2 -SSLv3

上の設定では TLS1.2、TLS1.1、TLS1.0 プロトコルが有効になりますが、クレジットカード業界のセキュリティ基準「PCI DSS v3.1」では TLS1.0 の安全性が不十分として、新しいサービスでは TLS1.1以上を使い、既存のサービスでも2018年6月30日までに TLS1.0 を無効にするように求めています。

WEBサイトの重要性やブラウザなどクライアントの対応状況を見て TLS1.0 を無効にすることも今後検討が必要になりそうですね。

（2017年9月17日追記）おしゃれな店舗と美味しいコヒーで有名なスターバックスは、公式ホームページの TLS1.0 と TLS1.1 を2017年9月11日以降無効にし「TLS1.2」のみ対応すると発表しました。現時点では思い切った判断ですが、「顧客の情報保護を第一」に考えれば当然のことかもしれませんね。
重要なお知らせ(2017/09/05) | スターバックスコーヒージャパン株式会社

適切な暗号スイートの設定

SSL/TLS の設定一番のややこしいのが、この暗号スイート（SSLCipherSuite）の選択です。暗号スイートを選ぶポイントは以下の通りです。

128ビット以上の強度のある暗号を使う
ECDHE鍵交換を使う
RSA鍵交換は使わない（認証でのRSAの利用はOK）
AEAD暗号スイート（GCM）は安全かつ高速

これらをふまえた暗号スイートの設定は次ようになります。上にある暗号スイートほど優先度が高くなります。

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA
　↓
SSLCipherSuite "ECDHE-ECDSA-AES128-GCM-SHA256 \
ECDHE-ECDSA-AES256-GCM-SHA384 \
ECDHE-ECDSA-AES128-SHA \
ECDHE-ECDSA-AES256-SHA \
ECDHE-ECDSA-AES128-SHA256 \
ECDHE-ECDSA-AES256-SHA384 \
ECDHE-RSA-AES128-GCM-SHA256 \
ECDHE-RSA-AES256-GCM-SHA384 \
ECDHE-RSA-AES128-SHA \
ECDHE-RSA-AES256-SHA \
ECDHE-RSA-AES128-SHA256 \
ECDHE-RSA-AES256-SHA384 \
DHE-RSA-AES128-GCM-SHA256 \
DHE-RSA-AES256-GCM-SHA384 \
DHE-RSA-AES128-SHA \
DHE-RSA-AES256-SHA \
DHE-RSA-AES128-SHA256 \
DHE-RSA-AES256-SHA256 \
EDH-RSA-DES-CBC3-SHA"

プロフェッショナルSSL/TLS（ラムダノート）　P336、P372 より引用

上の設定では 256ビットの暗号スイートよりも 128ビットの暗号スイートの優先度を高くしています。これはパフォーマンスに配慮しているためです。特に重要な情報を扱うWEBサイトの場合は、256ビットの暗号スイートの優先度を高くしてもよいでしょう。

サーバーが暗号スイートを選択する

初期設定ではクライアントが暗号スイートを選ぶように設定されていますが、せっかく適切な暗号スイートの設定しましたので Apache httpd サーバーが暗号スイートを選ぶように変更します。

#SSLHonorCipherOrder on
　↓
SSLHonorCipherOrder on

HSTS の設定

HSTS (HTTP Strict Transport Security) は、HSTSが設定されているWEBサイトに対して常にブラウザが SSL/TLS 通信を使うようにするための仕組みです。

HSTS は Header ディレクティブを使って設定します。max-age（秒）で設定された期間ブラウザで HSTS が有効になります。（下の場合は 31536000秒=1年が有効期間です）

Header always set Strict-Transport-Security "max-age=31536000"

SSL/TLSセッションキャッシュの適切な設定

初期設定では SSL/TLSセッションキャッシュの持続時間が300秒とかなり短く設定されています。SSL/TLSセッションキャッシュは短いほど安全なのですが、ここまで短いとパフォーマンスにも影響しますので、セッションキャッシュの持続時間を1時間（3,600秒）に変更します。（一般的なWEBサイトであれば24時間以内が許容範囲と言われています）

SSLSessionCacheTimeout 300
　↓
SSLSessionCacheTimeout 3600

アクセスの多いWEBサイトの場合は、キャッシュサイズも大きめに設定しておきましょう。（単位はバイトです）

SSLSessionCache shmcb:/run/httpd/sslcache(512000)
　↓
SSLSessionCache shmcb:/run/httpd/sslcache(1024000)

OCSPステープリングの設定

クライアントが SSL/TLS 通信を使うWEBサイトにアクセスすると、証明書の失効情報を確認するため、クライアントが直接 OCSPレスポンダ（一般的に認証局が運営しています）に問い合わせを行います。WEBサイトとの通信とは別に OCSPレスポンダとの通信も発生するため、この仕組みはパフォーマンス的によくありません。

対策として Apache httpd に OCSPステープリングを設定すれば、Apache httpd が OCSPレスポンダに問い合わせた結果をキャッシュして、証明書と一緒にクライアントに送信することができますので、クライアントが OCSPレスポンダに問い合わせる必要がなくなりパフォーマンスの改善が期待できます。

SSLUseStapling On
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/run/httpd/stapling_cache(128000)

SSLUseStapling On
　OCSPステープリングを有効にします。デフォルト値は「off」です。

SSLStaplingReturnResponderErrors off
OCSPレスポンダのエラーをクライアントに返さないようにします。デフォルト値は「on」です。

SSLStaplingCache shmcb:/run/httpd/stapling_cache(128000)
　OCSPレスポンス用のキャッシュを設定します。末尾の数値はキャッシュ容量で単位はバイトです。

※「SSLStaplingCache」ディレクティブは、必ずバーチャルホストブロックの外に書いてください。