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

安全な SSL/TLS 設定にするための10のポイント(Apache httpd 2.4)
あぱーブログ
2017年9月6日  カテゴリー:Linux  タグ: , ,
Pocket
LINEで送る

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

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

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

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

暗号強度共通鍵暗号方式RSAECDSA
組織的なごく短時間の攻撃に対する保護801024160
中期間(20年)の攻撃に対する保護1122048224
長期間(30年)の攻撃に対する保護1283072256
長期間の攻撃に対する保護と量子コンピュータに対する防御25615360512

(参考資料)
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 レコードの登録への対応を始めていますので、おそらく今後は普及していくでしょう。

(関連記事)
DNS CAAレコードに Let's Encrypt 認証局を設定する
Amazon Route 53 に 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
SSLStaplingCache shmcb:/run/httpd/stapling_cache(128000)

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

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

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

SSL Server Test(SSL Labs)でチェックする

設定にミスはつきものです。Apache httpd の設定が終わったら、必ず SSL Server Test(SSL Labs)で SSL/TLS が正しく安全に設定されていることをチェックしましょう。

SSL Server Test のチェック結果

おわりに

SSL/TLS の設定方法について簡単にまとめてみましたが、かなりの部分の説明をはしょっています(^^;) SSL/TLS についてしっかり理解したい方には書籍「プロフェッショナルSSL/TLS(ラムダノート)」をぜひオススメします。この一冊があれば SSL/TLS の設定に困ることはないでしょう。

記事中でも紹介した SSL Server Test を運営している「SSL Labs」は、この書籍の著者 Ivan Ristic氏が立ち上げたプロジェクトです。現在も SSL Labs の活動に参加しているそうです。

スポンサーリンク
Pocket
LINEで送る

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です