Webサーバの SSL/TLS 設定 (2015/5)

安全と可用性

先日IPAから公開された「SSL/TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～」を一通り読んで、自社向けに SSL/TLS 設定に関してまとめてみました。

はじめに

新宿駅の線路立ち入り騒ぎに巻き込まれ、「線路立ち入りのアナウンス」＝「"痴漢"の隠語」という本当か嘘か判らない話を初めてしった今日この頃、皆様いかがおすごしですか？

先日 ( 2015/5/12 )、IPAから SSL/TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～ という資料が公開されました。

最近の脆弱性も含め、どういった設定や運用を行うべきかが書かれているITセキュリティやITインフラに関わる方なら必読といってよい資料かと思われます。

しっかり読んで理解すべき資料だと思いますが、分量もそれなりにあるため、当座自分が関わっている環境、適用する設定に絞ってポイントをまとめてみます ( 自分/自社向け備忘録目的 )。

※写真 : 写真素材ぱくたそ

環境

環境に関しては以下想定です。
IPA 資料には Apache 以外 ( lighttpd, nginx, IIS) の設定に関しても記載があります。

OSLinux
サーバApache 2.x 系

SSL/TLS暗号設定ガイドライン について

上記 SSL/TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～ は、SSL/TLSサーバの設定方法を示す資料になっています ( 2015/3 時点での設定方法に関して記述 )。

SSL/TLSの概要

SSL/TLS に関する概要が記されています。

  • 歴史
  • バージョン概要
  • プロトコル概要

暗号アルゴリズムの安全性

暗号アルゴリズムにおける安全性の取り扱い方針に関して記載されています。

  • 異なる暗号アルゴリズムを併用する場合の注意点
  • 各ビット安全性 ( 安全性を持つかどうかを判断する目安。異なる暗号アルゴリズムの安全性を比較する際に利用される ) における利用期間

サーバ構築における設定要求項目について

ドキュメントのメイン部分と言える箇所です。実際にサーバ構築を行うにあたって、どのような設定を行うべきかについて説明されています。

安全性と可溶性を考慮した3つの基準

SSL/TLSサーバを設定する上では、以下を考慮するべきです。
  • 安全性
  • 可用性 ( 相互接続性 )

上記二点に関してはトレードオフが発生します。

安全性を高く ( 古いバージョンのプロトコルや暗号スイートを拒否し、より新しい安全なもののみ許可する ) した場合、可用性が低くなる ( 古いタイプのクライアント ( フィーチャーフォン等) が接続できなくなる ) 可能性があります。

IPA資料では安全性、及び、可用性のバランスによって、以下3つの設定基準を提示しています。

  • 高セキュリティ型
  • 推奨セキュリティ型
  • セキュリティ例外型
型用途安全性可用性
高セキュリティ型とりわけ高い安全性を必要とする明確な理由があるケースを対象とした基準
一般的な利用形態で使う事は想定していない。
政府内利用等に限定		高い最新のOSやブラウザが搭載されたPC/スマホでなければ接続できない可能性が高い
推奨セキュリティ型現時点で最も推奨される基準
安全性と可用性のバランスに優れる		標準的な安全水準を実現バージョンが古いOSやブラウザ、古い機器(フィーチャーフォンやゲーム機等)では接続できない可能性がある
セキュリティ例外型SSL3.0を許可
システム等の制約上SSL3.0を全面禁止するとデメリットが大きい(採用せざるを得ない)場合にのみ採用すべき基準
※推奨セキュリティ型への移行を前提とした対応を策定すべき
※利用者に対する注意喚起を行う事が望ましい		許容可能な最低限の安全水準最新ではないフィーチャーフォンやゲーム機でも接続可

通常、推奨セキュリティ型 (以上) を適用するのが望ましいですが、システムによっては可用性のために例外型を適用する必要がある場合もあると思います。こういった場合の設定に関しても記されています。

設定すべき項目

SSL/TLSに関わる設定として以下のものがあります。各型における設定基準が示されています。

  • プロトコルバージョンの設定
  • サーバ証明書の設定
  • 暗号スイートの設定
  • SSL/TLSを安全に使うために考慮すべきこと

チェックリスト

各型に対応するチェックリストも提示されています。
設定を行う/見直すといった場合に、これらチェックリストを利用する事でより適切な設定を行えるようになると思います。

その他

Webサーバ設定以外にも以下に関しても記載されています。

  • ブラウザを利用する際に注意すべきポイント
  • リモートアクセス VPN over SSL ( いわゆる SSL-VPN )

推奨セキュリティ型の要求設定

IPA資料に説明されている通り、通常「推奨セキュリティ型」を適用するのが望ましいです。

要求設定を以下まとめます。

プロトコルバージョンの要求設定

推奨セキュリティ型における要求設定は以下のようになっています。

  • SSL3.0、及び、SSL2.0を無効にする
  • TLS1.1, TLS1.2 は実装されていれば有効にする
  • 優先順位が設定できる場合、新しい ( 最もセキュアな ) バージョンでの接続を最優先とする

※IPA資料にはプロトコルバージョンでの安全性の違い ( 表 ) も記載されています ( BEAST/POODLE攻撃に対する安全性なども記載 )。


サーバ証明書の要求設定

  • SHA-256が使えることが必須条件
  • 多くの認証局から入手可能なサーバ証明書のうち、安全性が高いものを利用する
  • ECDSAを採用する際にはパテントリスクの存在を考慮する

サーバ証明書発行・更新要求の際に生成する鍵のアルゴリズム/鍵長

以下の何れか

  • RSAで鍵長は2048ビット以上
  • 楕円曲線暗号で鍵長256ビット以上

認証局が発行するサーバ証明書の署名アルゴリズム/鍵長

以下の何れか

  • RSA署名とSHA-256の組合せで2048ビット以上
  • ECDSAとSHA-256の組合せで鍵長256ビット以上

証明書発行/更新時の鍵情報の生成

  • 既存の鍵情報は再利用せず、必ず新たに公開鍵と秘密鍵の鍵ペアを生成する
  • 上記指示を仕様書、運用手順書、ガイドライン等に明示する

クライアントでの警告表示の回避

以下何れかの手段にて、接続されるクライアント ( Webブラウザ等 ) には警告表示が出ないようにする。

  • パブリック認証局からサーバ証明書を入手
  • 警告表示が出るクライアントの利用禁止
  • 信頼できるプライベート認証局のルートCA証明書をインストール

※証明書の要求設定 ( CSRの作成方法 ) に関しては SSL/TLS証明書の作成手順 (2015) に書きました。

サーバ証明書で考慮すべきこと

オレオレ証明書等の利用は避ける

警告表示が出るにもかかわらず、その警告を無視して接続するよう指示しなければならないサーバ構築の仕方をすべきではない。

※開発環境等での利用はこの限りではない ( と思う )。

ルートCA証明書の安易な手動インストールは避ける

利用者に対して手動インストールを求めるような運用はすべきでない。

適切な鍵長

鍵長が長い程安全性が高いが、長くしすぎると処理時間がかかり実用的でなくなる可能性がある。

サーバ証明書を発行・更新する際に新しい鍵情報を生成

意図せず第三者と秘密鍵を共有してしまったり ( サーバ機器の出荷時に設定されているデフォルト鍵の利用等で発生 )、秘密鍵が漏洩した可能性がある。
毎回新しく生成した鍵ペアを使った CSR でサーバ証明書を取得・更新する。


暗号スイートの要求設定

以下の条件を満たす暗号スイート

  • CRYPTREC 暗号リストに掲載されているアルゴリズムのみで構成
    参考 : CRYPTREC 電子政府推奨暗号リスト
  • 暗号化として 128 ビット安全性以上
  • DSA を含む暗号スイートは選定しない ( サーバ証明書で DSA を利用しないことを前提としている )

暗号スイートの優先順位

  • 選定した暗号スイートを、安全性と実用性とのバランスの観点に立って、グルーピング
  • 以下の条件でグループごとの優先順位を付ける
    • 128ビット安全性を優先
    • DHE、次いで RSA の順番での優先順位
  • 上記以外の暗号スイートは利用除外
  • 鍵交換で DHE を利用する場合には鍵長 1024 ビット以上、ECDHE/ECDH を利用する場合には鍵長 256 ビット以上、RSA を利用する場合には鍵長 2048 ビット以上の設定を必須

鍵交換で考慮すべきこと

秘密鍵漏えい時の影響範囲を狭める手法の採用

“秘密鍵” に毎回異なる乱数を付加することにより、見かけ上、毎回異なる秘密鍵を使ってセッション鍵の共有を行うようにする方法がある ( Perfect Forward Secrecy (PFS)、または、 Forward secrecy )。

これによって、秘密鍵が漏洩した場合でも、乱数が判らなければ、セッション鍵自体が求められないため、過去にさかのぼって通信データを解読されるリスクを回避できる ( PFS特性が無い場合、漏洩/取得した秘密鍵と過去の通信データから過去の通信データの中身が読み出せてしまう )。

現在の暗号スイートの中で、PFS 特性をもつのは DHE, ECDHE

鍵交換で利用すべき鍵長

鍵交換においても、鍵長を長くすれば処理時間や消費リソース等が増える。

2030 年を超えて利用することを想定していないシステムやサービスであれば、2048 ビット以上の鍵長を使うメリットは乏しい。

DHE/ECDHE での鍵長の設定状況についての注意

鍵交換で RSA を使う場合と、DHE や ECDHE/ECDH を使う場合とでは、鍵長の扱いが全く異なる

SSL/TLS を安全に使うために考慮すべきこと

脆弱性が発見される事があるため、常にこれら自体に対応できるようにしておく事が望ましい。

サーバ証明書の作成・管理

  • 脆弱な鍵ペアの使用を回避する
    鍵ペアの生成時点で脆弱性が指摘されていない暗号モジュールを利用する
  • サーバ証明書の種類
    通常のWebサーバ用途の場合、運営組織の実在性の確認等が行われる点で EV 証明書が利用者にとって一番安心できるサーバ証明書。
  • サーバ証明書の有効期限
    サーバ証明書の更新漏れ等が発生しないように、有効期間を管理し更新作業を行う。
  • 鍵の適切な管理
    紛失、漏えい等が発生しないように適切に管理する。
  • 複数サーバに同一のサーバ証明書を利用する場合の注意
    もれなく証明書のインストール、及び、設定の適用をする。
  • ルート CA 証明書
    信頼に足るルート CA 証明書を発行しているルート CA を選ぶ。 ( DigiNotar 認証局事件 ( IPA資料内コラム ) も参照 )

さらに安全性を高めるために

  • HTTP Strict Transport Security ( HSTS ) の設定有効化
  • リネゴシエーション脆弱性への対策
  • 圧縮機能を利用した実装攻撃への対策
  • OCSP Stapling の設定有効化
  • Public Key Pinning の設定有効化

実際の設定 ( Apache )

要求設定に基づいた実際の Apache 設定は以下のようになります。

暗号スイート設定 ( IPA資料の推奨セキュリティ型の例 (基本) )

※EXPORT 設定を無効にすることで、今年話題になった FREAK対策 にもなります。

SSLCipherSuite DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:CAMELLIA128-SHA:AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SHA:AES256-SHA

楕円曲線暗号ありの場合の例は以下のようになっています。

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:CAMELLIA128-SHA:AES128-SHA:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SHA:AES256-SHA:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-GCM-SHA384

プロトコル設定では SSLv2、SSLv3 は禁止

※昨年話題になった POODLE 脆弱性の対策 にもなります。

SSLProtocol All -SSLv2 -SSLv3

暗号スイートの優先順位指定

SSLHonorCipherOrder On

※暗号スイートの設定は細かく設定するとなると結構大変かと思います。
FREAK 対策を行う でも書いた Mozilla SSL Configuration Generator 等を利用してみるのも良いでしょう。

弊社では上記 Mozilla SSL Configuration Generator も利用して、IPA 推奨とはまた違う設定になっていたりします。

※Apache 2.4 における設定に関しては こちら にも書きました。

設定の確認

サーバの SSL/TLS 設定に関しては以下サイトで確認する事ができます。

まとめ

最初に書いた通り、IPAのガイドラインは、ITセキュリティ/ITインフラに携わるのであれば、しっかり読んで理解すべき資料かと思います。

この手のソリューションに携わっている企業であれば、誰かがこの資料を基に自社用のガイドライン策定する等する事で、得るべき情報は多いのではないでしょうか。

余談

こんな資料書いておいて、弊社WebサイトのSSL/TLS設定に関しては微妙に上記ガイドライン満たしてなかったりもするんですが。

サーバ証明書の作り方に問題が... 作業者が多分どっか適当なWebの記事 (古い) を基に作ったんじゃないかと (-_-;

※弊社Webサイトでは個人情報等の機密情報を扱っていない=現在の設定でも問題はない として放置

「証明書の取得作業なら、以前もやったことあるから大丈夫」

とか言ってたので任せたのですが、

  • 「作成できる」＝「アルゴリズムや鍵長等を適切に設定できる」ではない可能性が高い
  • どっかのWeb記事等を参考に作っている可能性があったりするが、記載が古かったり、適切でなかったりして、そのまま行った場合セキュリティ面で問題がある可能性もありうる。

という事は他でも「あるある」って話なんじゃないかと思われます。

「きちんと判る人間が作成基準を作成/メンテするってのも大事」って事でしょうか。

※こういう対応するやつの言う事 ( 「できる」 ) は疑ってかかる事が大事って事かも :-p

関連記事