000045645

SSL/TLS
暗 号 設 定
ガイドライン
~ 安 全 なウェブサイトのために( 暗 号 設 定 対 策 編 )~
作 成
発 行

本 書 は、 以 下 の URL からもダウンロードできます。
「SSL/TLS 暗 号 設 定 ガイドライン」
https://www.ipa.go.jp/security/vuln/ssl_crypt_config.html
SSL/TLS 暗 号 設 定 ガイドライン - 1

目 次
1. はじめに ...................................................................................................................... 5
1.1 本 書 の 内 容 及 び 位 置 付 け .............................................................................................. 5
1.2 本 書 が 対 象 とする 読 者 ................................................................................................. 5
1.3 ガイドラインの 検 討 体 制 .............................................................................................. 6
2. 本 ガイドラインの 理 解 を 助 ける 技 術 的 な 基 礎 知 識 ........................................................ 7
2.1 SSL/TLS の 概 要 ........................................................................................................... 7
2.1.1 SSL/TLS の 歴 史 ........................................................................................................... 7
2.1.2 プロトコル 概 要 ............................................................................................................ 9
2.2 暗 号 アルゴリズムの 安 全 性 .......................................................................................... 10
2.2.1 CRYPTREC 暗 号 リスト .............................................................................................. 10
2.2.2 異 なる 暗 号 アルゴリズムにおける 安 全 性 の 見 方 ........................................................... 10
PART I: サーバ 構 築 における 設 定 要 求 項 目 について ........................................................... 13
3. 設 定 基 準 の 概 要 ........................................................................................................... 14
3.1 実 現 すべき 設 定 基 準 の 考 え 方 ...................................................................................... 14
3.2 要 求 設 定 の 概 要 ........................................................................................................... 16
3.3 チェックリスト ........................................................................................................... 17
4. プロトコルバージョンの 設 定 ...................................................................................... 19
4.1 プロトコルバージョンについての 要 求 設 定 .................................................................. 19
4.2 プロトコルバージョンごとの 安 全 性 の 違 い .................................................................. 20
5. サーバ 証 明 書 の 設 定 .................................................................................................... 22
5.1 サーバ 証 明 書 についての 要 求 設 定 ............................................................................... 22
5.2 サーバ 証 明 書 に 記 載 されている 情 報 ............................................................................ 26
5.3 サーバ 証 明 書 で 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム ............................................. 26
5.4 サーバ 証 明 書 で 考 慮 すべきこと ................................................................................... 27
5.4.1 信 頼 できないサーバ 証 明 書 の 利 用 は 止 める .................................................................. 27
5.4.2 ルート CA 証 明 書 の 安 易 な 手 動 インストールは 避 ける ................................................. 28
5.4.3 サーバ 証 明 書 で 利 用 すべき 鍵 長 ................................................................................... 28
5.4.4 サーバ 証 明 書 を 発 行 ・ 更 新 する 際 に 新 しい 鍵 情 報 を 生 成 する 重 要 性 ............................ 29
6. 暗 号 スイートの 設 定 .................................................................................................... 31
6.1 暗 号 スイートについての 要 求 設 定 ............................................................................... 31
6.2 暗 号 スイートで 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム ............................................. 33
6.3 鍵 交 換 で 考 慮 すべきこと ............................................................................................. 34
6.3.1 秘 密 鍵 漏 えい 時 の 影 響 範 囲 を 狭 める 手 法 の 採 用 (Perfect Forward Secrecy の 重 要 性 ) . 35
6.3.2 鍵 交 換 で 利 用 すべき 鍵 長 ............................................................................................. 35
6.3.3 DHE/ECDHE での 鍵 長 の 設 定 状 況 についての 注 意 ....................................................... 36
6.4 暗 号 スイートについての 実 装 状 況 ............................................................................... 38
SSL/TLS 暗 号 設 定 ガイドライン - 2

6.5 暗 号 スイートについての 詳 細 な 要 求 設 定 ..................................................................... 38
6.5.1 高 セキュリティ 型 での 暗 号 スイートの 詳 細 要 求 設 定 .................................................... 38
6.5.2 推 奨 セキュリティ 型 での 暗 号 スイートの 詳 細 要 求 設 定 ................................................. 39
6.5.3 セキュリティ 例 外 型 での 暗 号 スイートの 詳 細 要 求 設 定 ................................................. 42
7. SSL/TLS を 安 全 に 使 うために 考 慮 すべきこと .............................................................. 44
7.1 サーバ 証 明 書 の 作 成 ・ 管 理 について 注 意 すべきこと .................................................... 44
7.1.1 サーバ 証 明 書 での 脆 弱 な 鍵 ペアの 使 用 の 回 避 .............................................................. 44
7.1.2 推 奨 されるサーバ 証 明 書 の 種 類 ................................................................................... 44
7.1.3 サーバ 証 明 書 の 有 効 期 限 ............................................................................................. 45
7.1.4 サーバ 鍵 の 適 切 な 管 理 ................................................................................................ 46
7.1.5 複 数 サーバに 同 一 のサーバ 証 明 書 を 利 用 する 場 合 の 注 意 ............................................. 46
7.1.6 ルート CA 証 明 書 ....................................................................................................... 47
7.2 さらに 安 全 性 を 高 めるために ...................................................................................... 48
7.2.1 HTTP Strict Transport Security(HSTS)の 設 定 有 効 化 ................................................ 48
7.2.2 リネゴシエーションの 脆 弱 性 への 対 策 ......................................................................... 49
7.2.3 圧 縮 機 能 を 利 用 した 実 装 攻 撃 への 対 策 ......................................................................... 50
7.2.4 OCSP Stapling の 設 定 有 効 化 ....................................................................................... 50
7.2.5 Public Key Pinning の 設 定 有 効 化 ................................................................................. 51
PART II: ブラウザ&リモートアクセスの 利 用 について ...................................................... 53
8. ブラウザを 利 用 する 際 に 注 意 すべきポイント .............................................................. 54
8.1 本 ガイドラインが 対 象 とするブラウザ......................................................................... 54
8.1.1 対 象 とするプラットフォーム ...................................................................................... 54
8.1.2 対 象 とするブラウザのバージョン ............................................................................... 54
8.2 設 定 に 関 する 確 認 項 目 ................................................................................................ 55
8.2.1 基 本 原 則 ..................................................................................................................... 55
8.2.2 設 定 項 目 ..................................................................................................................... 55
8.3 ブラウザ 利 用 時 の 注 意 点 ............................................................................................. 57
8.3.1 鍵 長 1024 ビット、SHA-1 を 利 用 するサーバ 証 明 書 の 警 告 表 示 .................................... 57
8.3.2 SSL3.0 の 取 り 扱 い ...................................................................................................... 59
9. その 他 のトピック ....................................................................................................... 60
9.1 リモートアクセス VPN over SSL (いわゆる SSL-VPN) ............................................ 60
Appendix: 付 録 .................................................................................................................. 62
Appendix A:チェックリスト ............................................................................................... 63
A.1. チェックリストの 利 用 方 法 .......................................................................................... 63
A.2. 高 セキュリティ 型 のチェックリスト ............................................................................ 64
A.3. 推 奨 セキュリティ 型 のチェックリスト......................................................................... 65
A.4. セキュリティ 例 外 型 のチェックリスト......................................................................... 68
Appendix B:サーバ 設 定 編 ................................................................................................... 71
B.1. サーバ 設 定 方 法 例 のまとめ .......................................................................................... 71
SSL/TLS 暗 号 設 定 ガイドライン - 3

B.1.1. Apache の 場 合 ............................................................................................................ 71
B.1.2. lighttpd の 場 合 ............................................................................................................ 72
B.1.3. nginx の 場 合 ............................................................................................................... 72
B.2. プロトコルバージョンの 設 定 方 法 例 ............................................................................ 73
B.2.1. Apache の 場 合 ............................................................................................................ 73
B.2.2. lighttpd の 場 合 ............................................................................................................ 73
B.2.3. nginx の 場 合 ............................................................................................................... 74
B.2.4. Microsoft IIS の 場 合 .................................................................................................... 74
B.3. 鍵 パラメータファイルの 設 定 方 法 例 ............................................................................ 75
B.3.1. OpenSSL による DHE、ECDH、ECDHE 鍵 パラメータファイルの 生 成 ........................ 75
B.3.2. Apache における DHE、ECDH、ECDHE 鍵 パラメータ 設 定 ......................................... 76
B.3.3. lighttpd における DHE、ECDH、ECDHE 鍵 パラメータ 設 定 ........................................ 76
B.3.4. nginx における DHE、ECDH、ECDHE 鍵 パラメータ 設 定 ........................................... 76
B.4. HTTP Strict Transport Security(HSTS)の 設 定 方 法 例 ................................................ 77
B.4.1. Apache の 場 合 ............................................................................................................ 77
B.4.2. lighttpd の 場 合 ............................................................................................................ 77
B.4.3. nginx の 場 合 ............................................................................................................... 78
B.4.4. Microsoft IIS の 場 合 .................................................................................................... 78
B.5. OCSP Stapling の 設 定 方 法 例 ....................................................................................... 79
B.5.1. Apache の 場 合 ............................................................................................................ 79
B.5.2. nginx の 場 合 ............................................................................................................... 80
B.5.3. Microsoft IIS の 場 合 .................................................................................................... 80
B.6. Public Key Pinning の 設 定 方 法 例 ................................................................................. 80
B.6.1. Apache の 場 合 ............................................................................................................ 81
B.6.2. lighttpd での 設 定 例 ..................................................................................................... 82
B.6.3. nginx の 場 合 ............................................................................................................... 82
B.6.4. Microsoft IIS の 場 合 .................................................................................................... 82
Appendix C: 暗 号 スイートの 設 定 例 ..................................................................................... 84
C.1. Windows での 設 定 例 ................................................................................................... 84
C.2. OpenSSL 系 での 設 定 例 ............................................................................................... 85
C.2.1. Apache, lighttpd, nginx の 場 合 ..................................................................................... 85
C.2.2. OpenSSL 系 での 暗 号 スイートの 設 定 例 ....................................................................... 86
Appendix D:ルート CA 証 明 書 の 取 り 扱 い ........................................................................... 89
D.1. ルート CA 証 明 書 の 暗 号 アルゴリズムおよび 鍵 長 の 確 認 方 法 ....................................... 89
D.2. Active Directory を 利 用 したプライベートルート CA 証 明 書 の 自 動 更 新 ........................ 91
SSL/TLS 暗 号 設 定 ガイドライン - 4

1. はじめに
1.1 本 書 の 内 容 及 び 位 置 付 け
本 ガイドラインは、2015 年 3 月 時 点 における、SSL/TLS 通 信 での 安 全 性 と 可 用 性 ( 相 互 接 続 性 )
のバランスを 踏 まえた SSL/TLS サーバの 設 定 方 法 を 示 すものである。
本 ガイドラインは 9 章 で 構 成 されており、 章 立 ては 以 下 のとおりである。
2 章 では、 本 ガイドラインを 理 解 するうえで 助 けとなる 技 術 的 な 基 礎 知 識 をまとめている。 特
に 高 度 な 内 容 は 含 んでおらず、SSL/TLS 及 び 暗 号 についての 技 術 的 な 基 礎 知 識 を 有 している 読 者
は 本 章 を 飛 ばしてもらって 構 わない。
3 章 では、SSL/TLS サーバに 要 求 される 設 定 基 準 の 概 要 について 説 明 しており、4 章 から 6 章
で 実 現 すべき 要 求 設 定 の 考 え 方 を 示 す。
4 章 から 6 章 では、3 章 で 定 めた 設 定 基 準 に 基 づき、 具 体 的 な SSL/TLS サーバの 要 求 設 定 につ
いて 示 す。 本 章 の 内 容 は、 安 全 性 と 可 用 性 を 踏 まえたうえで 設 定 すべき「 要 求 事 項 」である。
第 7 章 では、チェックリストの 対 象 には 含 めていないが、SSL/TLS を 安 全 に 使 うために 考 慮 す
べきことをまとめている。 本 章 の 内 容 は、「 情 報 提 供 」の 位 置 づけとして 記 載 している。
第 8 章 は、クライアントの 一 つであるブラウザの 設 定 に 関 する 事 項 を 説 明 しており、ブラウザ
の 利 用 者 に 対 して 啓 発 するべき 事 項 を 取 り 上 げている。 本 章 の 内 容 は、 第 7 章 と 同 様 、「 情 報 提 供 」
の 位 置 づけのものである。
第 9 章 は、そのほかのトピックとして、SSL/TLS を 用 いたリモートアクセス 技 術 (“SSL-VPN”
とも 言 われる)について 記 載 している。 本 章 の 内 容 も「 情 報 提 供 」の 位 置 づけのものである。
3 章 から 6 章 が 本 ガイドラインの 最 大 の 特 長 ともいえ、「 暗 号 技 術 以 外 の 様 々な 利 用 上 の 判 断 材
料 も 加 味 した 合 理 的 な 根 拠 」を 重 視 して 現 実 的 な 利 用 方 法 を 目 指 している。 具 体 的 には、 実 現 す
べき 安 全 性 と 必 要 となる 相 互 接 続 性 とのトレードオフを 考 慮 する 観 点 から、 安 全 性 と 可 用 性 を 踏
まえたうえで 設 定 すべき「 要 求 設 定 項 目 」として 3 つの 設 定 基 準 (「 高 セキュリティ 型 」「 推 奨 セ
キュリティ 型 」「セキュリティ 例 外 型 」)を 提 示 している。
Appendix には、4 章 から 6 章 までの 設 定 状 況 を 確 認 するためのチェックリストや、 個 別 製 品 で
の 具 体 的 な 設 定 方 法 例 も 記 載 している。
チェックリストの 目 的 は、「 選 択 した 設 定 基 準 に 対 応 した 要 求 設 定 項 目 の 設 定 忘 れの 防 止 」と「サ
ーバ 構 築 の 作 業 受 託 先 が 適 切 に 要 求 設 定 項 目 を 設 定 したことの 確 認 」を 行 うための 手 段 となるも
のである。
1.2 本 書 が 対 象 とする 読 者
対 象 読 者 は、 主 に SSL/TLS サーバを 実 際 に 構 築 するにあたって 具 体 的 な 設 定 を 行 うサーバ 構 築
者 、 実 際 のサーバ 管 理 やサービス 提 供 に 責 任 を 持 つことになるサーバ 管 理 者 、 並 びに SSL/TLS サ
SSL/TLS 暗 号 設 定 ガイドライン - 5

ーバの 構 築 を 発 注 するシステム 担 当 者 としている。
一 部 の 内 容 については、ブラウザを 使 う 一 般 利 用 者 への 注 意 喚 起 も 対 象 とする。
1.3 ガイドラインの 検 討 体 制
本 ガイドラインは、CRYPTREC 暗 号 技 術 活 用 委 員 会 の 配 下 に 設 置 された 運 用 ガイドラインワー
キンググループに 参 加 する 委 員 の 知 見 を 集 約 したベストプラクティスとして 作 成 されたものであ
り、 暗 号 技 術 活 用 委 員 会 及 び 暗 号 技 術 検 討 会 の 承 認 を 得 て 発 行 されたものである。
運 用 ガイドラインワーキンググループは 表 1のメンバーにより 構 成 されている。
表 1 運 用 ガイドラインワーキンググループの 構 成
主 査 菊 池 浩 明 明 治 大 学 総 合 数 理 学 部 先 端 メディアサイエンス 学 科
教 授
委 員 阿 部 貴 株 式 会 社 シマンテック SSL 製 品 本 部
SSL プロダクトマーケティング 部 マネージャー
委 員 漆 嶌 賢 二 富 士 ゼロックス 株 式 会 社 CS 品 質 本 部
品 質 保 証 部 マネージャー
委 員 及 川 卓 也 グーグル 株 式 会 社 エンジニアリング
シニアエンジニアリングマネージャー
委 員 加 藤 誠 一 般 社 団 法 人 Mozilla Japan 技 術 部
テクニカルアドバイザ
委 員 佐 藤 直 之 株 式 会 社 イノベーションプラス
Director
委 員 島 岡 政 基 セコム 株 式 会 社 IS 研 究 所
コミュニケーションプラットフォームディビジョン
暗 号 ・ 認 証 基 盤 グループ 主 任 研 究 員
委 員 須 賀 祐 治 株 式 会 社 インターネットイニシアティブ
サービスオペレーション 本 部 セキュリティ 情 報 統 括 室
シニアエンジニア
委 員 高 木 浩 光 独 立 行 政 法 人 産 業 技 術 総 合 研 究 所
セキュアシステム 研 究 部 門
主 任 研 究 員
委 員 村 木 由 梨 香 日 本 マイクロソフト 株 式 会 社
セキュリティレスポンスチーム
セキュリティプログラムマネージャ
委 員 山 口 利 恵 東 京 大 学 大 学 院 情 報 理 工 学 系 研 究 科
ソーシャル ICT 研 究 センター 特 任 准 教 授
執 筆 神 田 雅 透 情 報 処 理 推 進 機 構 技 術 本 部 セキュリティセンター
とりまとめ
SSL/TLS 暗 号 設 定 ガイドライン - 6

2. 本 ガイドラインの 理 解 を 助 ける 技 術 的 な 基 礎 知 識
2.1 SSL/TLS の 概 要
2.1.1 SSL/TLS の 歴 史
Secure Sockets Layer (SSL)はブラウザベンダであった Netscape 社 により 開 発 されたクライアン
ト-サーバモデルにおけるセキュアプロトコルである。SSL には 3 つのバージョンが 存 在 するが
バージョン 1.0 は 非 公 開 である。SSL2.0 が 1995 年 にリリースされたが、その 後 すぐに 脆 弱 性 が 発
見 され、 翌 1996 年 に SSL3.0 [RFC6101] が 公 開 されている。
標 準 化 団 体 Internet Engineering Task Force (IETF)は 非 互 換 性 の 問 題 を 解 決 するために、Transport
Layer Security Protocol Version 1.0 (TLS1.0) [RFC2246] を 策 定 した。TLS1.0 は SSL3.0 をベースに
している。TLS1.0 で 定 められているプロトコルバージョンからも 分 かるように TLS1.0 は SSL3.1
とも 呼 ばれる。
TLS1.1 [RFC4346] は、TLS1.0 における 暗 号 利 用 モードの 一 つである CBC 1 モードで 利 用 される
初 期 ベクトルの 選 択 とパディングエラー 処 理 に 関 連 する 脆 弱 性 に 対 処 するために 仕 様 策 定 が 行 わ
れた。 具 体 的 には BEAST 2 攻 撃 を 回 避 することができる。
さらに TLS1.2 [RFC5246] は 特 にハッシュ 関 数 SHA-2 family (SHA-256 や SHA-384)の 利 用 など、
より 強 い 暗 号 アルゴリズムの 利 用 が 可 能 になった。 例 えばメッセージ 認 証 コード(MAC 3 )や 擬
似 乱 数 関 数 にて SHA-2 family が 利 用 可 能 になっている。また 認 証 付 暗 号 利 用 モードが 利 用 可 能 な
暗 号 スイートのサポートがなされており、 具 体 的 には GCM 4 や CCM 5 モードの 利 用 が 可 能 になっ
た。
表 2に SSL/TLS のバージョンの 概 要 をまとめる。 最 近 では、IETF において、TLS1.3 の 規 格 化
の 議 論 が 進 んでいる。
なお、SSL/TLS に 対 する 攻 撃 方 法 の 技 術 的 な 詳 細 については、「CRYPTREC 暗 号 技 術 ガイドラ
イン(SSL/TLS における 近 年 の 攻 撃 への 対 応 状 況 ) 6 」を 参 照 されたい。
1 CBC: Ciphertext Block Chaining
2 BEAST: Browser Exploit Against SSL/TLS
3 MAC: Message Authentication Code
4 GCM: Galois/Counter Mode
5 CCM: Counter with CBC-MAC
6 http://www.cryptrec.go.jp/report/c13_kentou_giji02_r2.pdf
SSL/TLS 暗 号 設 定 ガイドライン - 7

表 2 SSL/TLS のバージョン 概 要
バージョン 概 要
SSL2.0 • いくつかの 脆 弱 性 が 発 見 されており、なかでも「ダウングレード 攻 撃 ( 最 弱 の
(1994) アルゴリズムを 強 制 的 に 使 わせることができる)」と「バージョンロールバック
攻 撃 (SSL2.0 を 強 制 的 に 使 わせることができる)」は 致 命 的 な 脆 弱 性 といえる
• SSL2.0 は 利 用 すべきではなく、 実 際 に 2005 年 頃 以 降 に 出 荷 されているサーバや
ブラウザでは SSL2.0 は 初 期 状 態 で 利 用 不 可 となっている
SSL3.0 • SSL2.0 での 脆 弱 性 に 対 処 したバージョン
(RFC6101) • 2014 年 10 月 に POODLE 7 攻 撃 が 発 表 されたことにより 特 定 の 環 境 下 での CBC モ
(1995) ードの 利 用 は 危 険 であることが 認 識 されている。POODLE 攻 撃 は、SSL3.0 にお
けるパディングチェックの 仕 方 の 脆 弱 性 に 起 因 しているため、この 攻 撃 に 対 す
る 回 避 策 は 現 在 のところ 存 在 していない
• POODLE 攻 撃 の 発 表 を 受 け、 必 要 に 応 じてサーバやブラウザの 設 定 を 変 更 し、
SSL3.0 を 無 効 化 にするよう 注 意 喚 起 されている 8
TLS1.0 • 2015 年 3 月 時 点 では、もっとも 広 く 実 装 されているバージョンであり、 実 装 率
(RFC2246) はほぼ 100%
(1999) • ブロック 暗 号 を CBC モードで 利 用 した 時 の 脆 弱 性 を 利 用 した 攻 撃 (BEAST 攻 撃
など)が 広 く 知 られているが、 容 易 な 攻 撃 回 避 策 が 存 在 し、すでにセキュリテ
ィパッチも 提 供 されている。また、SSL3.0 で 問 題 となった POODLE 攻 撃 は、プ
ロトコルの 仕 様 上 、TLS1.0 には 適 用 できない
• 暗 号 スイートとして、より 安 全 なブロック 暗 号 の AES と Camellia、 並 びに 公 開
鍵 暗 号 ・ 署 名 に 楕 円 曲 線 暗 号 が 利 用 できるようになった
• 秘 密 鍵 の 生 成 などに 擬 似 乱 数 関 数 を 採 用
• MAC の 計 算 方 法 を HMAC に 変 更
TLS1.1 • ブロック 暗 号 を CBC モードで 利 用 した 時 の 脆 弱 性 を 利 用 した 攻 撃 (BEAST 攻 撃
(RFC4346) 等 )への 対 策 を 予 め 仕 様 に 組 み 入 れるなど、TLS1.0 の 安 全 性 強 化 を 図 っている
(2006) • 実 装 に 関 しては、 規 格 化 された 年 が TLS1.2 とあまり 変 わらなかったため、TLS1.1
と TLS1.2 は 同 時 に 実 装 されるケースも 多 く、2015 年 3 月 時 点 でのサーバやブラ
ウザ 全 体 における 実 装 率 は 約 50%
TLS1.2 • 暗 号 スイートとして、より 安 全 なハッシュ 関 数 SHA-256 と SHA-384、CBC モー
(RFC5246) ドより 安 全 な 認 証 付 暗 号 利 用 モード(GCM、CCM)が 利 用 できるようになった。
(2008) 特 に、 認 証 付 暗 号 利 用 モードでは、 利 用 するブロック 暗 号 が 同 じであっても、
CBC モードの 脆 弱 性 を 利 用 した 攻 撃 (BEAST 攻 撃 等 )がそもそも 適 用 できない
• 必 須 の 暗 号 スイートを TLS_RSA_WITH_AES_128_CBC_SHA に 変 更
• IDEA と DES を 使 う 暗 号 スイートを 削 除
• 擬 似 乱 数 関 数 の 構 成 を MD5/SHA-1 ベースから SHA-256 ベースに 変 更
• 本 格 的 に 実 装 が 始 まったのは 最 近 であり、2015 年 3 月 時 点 でのサーバやブラウ
ザ 全 体 における 実 装 率 は 約 55%
7 POODLE: Padding Oracle On Downgraded Legacy Encryption
8 SSL3.0 の 脆 弱 性 対 策 について、http://www.ipa.go.jp/security/announce/20141017-ssl.html
SSL/TLS 暗 号 設 定 ガイドライン - 8

2.1.2 プロトコル 概 要
SSL/TLSS はセッション 層 に 位 置 するセキュアプロトコルで、 通 信 の 暗 号 化 、データ 完 全 性 の 確
保 、サーバ( 場 合 によりクライアント)の認 証 を 行 うことができる。セッション 層 に 位 置 するこ
とで、アプリケーション 層 ごとにセキュリティ 確 保 のための 仕 組 みを 実 装 する 必 要 がなく、HTTP、
SMTP、POP など 様 々なプロトコルの 下 位 に 位 置 して、 上 記 のような 機 能 を 提 供 することができ
る。
SSL/TLSS では、 暗 号 通 信 を 始 めるに 先 立 って、ハンドシェイクが 実 行 される( 図 1参 照 )。
ハンドシェイクでは、1ブラウザ(クライアント)
とサーバが
暗 号 通 信 するために 利 用 する 暗
号 アルゴリズムとプロトコルバー
ージョンを決 定 し、2サ サーバ 証 明 書 によってサーバの 認 証 を 行 い、
3そのセッションで 利 用 するセッション 鍵 を 共 有 する、までの 一 連 の 動 作 を 行 う。
その 際 、 SSL/TLS では 相 互 接 続 性 の 確 保 を 優 先 してきたため、
一 般 には 複 数 の 暗 号 アルゴリズ
ムとプロトコルバージョンが 実 装 されている。 結 果 として、 暗 号 通 信 における 安 全 性 強 度 は、ハ
ンドシェイクの1の 処 理 でどの 暗 号 アルゴリズムとプロトコルバージョンをを 選 択 したかに 大 きく
依 存 する。
サイトの
身 分 証 明 ともいえるサーバ 証 明 書 は、Trusted Third Party である 認 証 局 (CAA 9 )によっ
て 発 行 されるのが 一 般 的 であり、
特 に Webb Trust for CA などの 一 定 の 基 準 を 満 たしている 代 表 的
な 認 証 局 の 証 明 書 はルート CA として 予 めブラウザに
登 録 されている。(4)のの 検 証 では、ブラウザ
に 登 録 された 認 証 局 の 証 明 書 を 信 頼 の 起 点 として、 当 該 サーバ 証 明 書 の 正 当 性 を 確 認 する。
図 1 SSL/TLS プロトコル 概 要
9
Certificate Authority
SSL/TLS 暗 号 設 定 ガイドライン -
9

2.2 暗 号 アルゴリズムの 安 全 性
2.2.1 CRYPTREC 暗 号 リスト
総 務 省 と 経 済 産 業 省 は、 暗 号 技 術 に 関 する 有 識 者 で 構 成 される CRYPTREC 活 動 を 通 して、 電
子 政 府 で 利 用 される 暗 号 技 術 の 評 価 を 行 っており、2013 年 3 月 に「 電 子 政 府 における 調 達 のため
に 参 照 すべき 暗 号 のリスト(CRYPTREC 暗 号 リスト)」 を 策 定 した 10 。CRYPTREC 暗 号 リストは、
「 電 子 政 府 推 奨 暗 号 リスト」、「 推 奨 候 補 暗 号 リスト」 及 び「 運 用 監 視 暗 号 リスト」で 構 成 される。
「 政 府 機 関 の 情 報 セキュリティ 対 策 のための 統 一 基 準 ( 平 成 26 年 度 版 )」( 平 成 26 年 5 月 19
日 、 情 報 セキュリティ 政 策 会 議 ) では 以 下 のように 記 載 されており、 政 府 機 関 における 情 報 シ
ステムの 調 達 及 び 利 用 において、CRYPTREC 暗 号 リストのうち「 電 子 政 府 推 奨 暗 号 リスト」が 原
則 的 に 利 用 される。
政 府 機 関 の 情 報 セキュリティ 対 策 のための 統 一 基 準 ( 抄 )
6.1.5 暗 号 ・ 電 子 署 名 - 遵 守 事 項 (1)(b)
情 報 システムセキュリティ 責 任 者 は、 暗 号 技 術 検 討 会 及 び 関 連 委 員 会 (CRYPTREC)に
より 安 全 性 及 び 実 装 性 能 が 確 認 された「 電 子 政 府 推 奨 暗 号 リスト」を 参 照 した 上 で、 情 報
システムで 使 用 する 暗 号 及 び 電 子 署 名 のアルゴリズム 及 び 運 用 方 法 について、 以 下 の 事 項
を 含 めて 定 めること。
(ア) 行 政 事 務 従 事 者 が 暗 号 化 及 び 電 子 署 名 に 対 して 使 用 するアルゴリズムについて、
「 電 子 政 府 推 奨 暗 号 リスト」に 記 載 された 暗 号 化 及 び 電 子 署 名 のアルゴリズムが
使 用 可 能 な 場 合 には、それを 使 用 させること。
(イ) 情 報 システムの 新 規 構 築 又 は 更 新 に 伴 い、 暗 号 化 又 は 電 子 署 名 を 導 入 する 場 合 に
は、やむを 得 ない 場 合 を 除 き、「 電 子 政 府 推 奨 暗 号 リスト」に 記 載 されたアルゴ
リズムを 採 用 すること。
( 以 下 、 略 )
2.2.2 異 なる 暗 号 アルゴリズムにおける 安 全 性 の 見 方
異 なる 技 術 分 類 の 暗 号 アルゴリズムを 組 合 せて 利 用 する 際 、ある 技 術 分 類 の 暗 号 アルゴリズム
の 安 全 性 が 極 めて 高 いものであっても、 別 の 技 術 分 類 の 暗 号 アルゴリズムの 安 全 性 が 低 ければ、
結 果 として、 低 い 安 全 性 の 暗 号 アルゴリズムに 引 きずられる 形 で 全 体 の 安 全 性 が 決 まる。 逆 に 言
えば、 異 なる 技 術 分 類 の 暗 号 アルゴリズムであっても、 同 程 度 の 安 全 性 とみなされている 暗 号 ア
ルゴリズムを 組 合 せれば、 全 体 としても 同 程 度 の 安 全 性 が 実 現 できることになる。
異 なる 技 術 分 類 の 暗 号 アルゴリズムについて 同 程 度 の 安 全 性 を 持 つかどうかを 判 断 する 目 安 と
して、“ビット 安 全 性 ( 等 価 安 全 性 ということもある)”という 指 標 がある。 具 体 的 には、 評 価 対
象 とする 暗 号 アルゴリズムに 対 してもっとも 効 率 的 な 攻 撃 手 法 を 用 いたときに、どの 程 度 の 計 算
量 があれば 解 読 できるか( 解 読 計 算 量 11 )で 表 現 され、 鍵 長 12 とは 別 に 求 められる。 表 記 上 、 解 読
10 http://www.cryptrec.go.jp/images/cryptrec_ciphers_list_2013.pdf
11
直 感 的 には、 基 本 となる 暗 号 化 処 理 の 繰 り 返 し 回 数 のことである。 例 えば、 解 読 計 算 量 2 20 と
いえば、 暗 号 化 処 理 2 20 回 相 当 の 演 算 を 繰 り 返 し 行 えば 解 読 できることを 意 味 する
SSL/TLS 暗 号 設 定 ガイドライン - 10

計 算 量 が 2 x である 場 合 に“x ビット 安 全 性 ”という。 例 えば、 共 通 鍵 暗 号 においては、 全 数 探 索
する 際 の 鍵 空 間 の 大 きさで 2 x (x は 共 通 鍵 のビット 長 )、ハッシュ 関 数 の 例 としては、 一 方 向 性 で
2 x 、 衝 突 困 難 性 で 2 (x/2) (x は 出 力 ビット 長 )が 解 読 計 算 量 の( 最 大 ) 理 論 値 である。
“ビット 安 全 性 ”による 評 価 では、 技 術 分 類 に 関 わらず、どの 暗 号 アルゴリズムであっても、
解 読 計 算 量 が 大 きければ 安 全 性 が 高 く、 逆 に 小 さければ 安 全 性 が 低 い。また、 解 読 計 算 量 が 実 現
可 能 と 考 えられる 計 算 量 を 大 幅 に 上 回 っていれば、 少 なくとも 現 在 知 られているような 攻 撃 手 法
ではその 暗 号 アルゴリズムを 破 ることは 現 実 的 に 不 可 能 であると 予 測 される。
そこで、 暗 号 アルゴリズムの 選 択 においては、“x ビット 安 全 性 ”の“x ビット”に 着 目 して、
長 期 的 な 利 用 期 間 の 目 安 とする 使 い 方 ができる。 例 えば、NIST SP800-57 Part 1 revision 3 13 では、
表 3のように 規 定 している。
なお、 表 記 の 便 宜 上 、 本 ガイドラインでは 以 下 の 表 記 を 用 いる。
• AES-xxx: 鍵 長 が xxx ビットの AES のこと
• Camellia-xxx: 鍵 長 が xxx ビットの Camellia のこと
• RSA-xxx: 鍵 長 が xxx ビットの RSA のこと
• DH-xxx: 鍵 長 が xxx ビットの DH のこと
• ECDH-xxx: 鍵 長 が xxx ビット( 例 えば NIST 曲 線 パラメータ P-xxx を 利 用 )の ECDH
のこと
• ECDSA-xxx: 鍵 長 が xxx ビット( 例 えば NIST 曲 線 パラメータ P-xxx を 利 用 )の ECDSA
のこと
• HMAC-SHA-xxx:メッセージ 認 証 子 を 作 る HMAC において 利 用 するハッシュ 関 数
SHA-xxx のこと。SSL/TLS では、 暗 号 スイートで 決 めるハッシュ 関 数 は HMAC として
利 用 される。
• SHA-xxx:デジタル 署 名 を 作 成 する 際 に 利 用 するハッシュ 関 数 SHA-xxx のこと。
12 ハッシュ 関 数 の 場 合 はダイジェスト 長 に 相 当 する
13 NIST SP800-57, Recommendation for Key Management – Part 1: General (Revision 3)
SSL/TLS 暗 号 設 定 ガイドライン - 11

表 3 NIST SP800-57 でのビット 安 全 性 の 取 り 扱 い 方 針 (WG で 加 工 )
ビット 安 全 性 SSL で 利 用 する 利 用 上 の 条 件 長 期 的 な 利 用 期 間
代 表 的 な 暗 号
2030 年 まで 2031 年 以 降
アルゴリズム
80 ビット RSA-1024 新 規 に 処 理 をする 利 用 不 可 利 用 不 可
DH-1024
場 合
ECDH-160
ECDSA-160
過 去 に 処 理 したも
のを 利 用 する 場 合
過 去 のシステムとの 互 換 性 維 持 の
利 用 だけを 容 認
SHA-1
112 ビット 3-key Triple DES 新 規 に 処 理 をする 利 用 可
利 用 不 可
RSA-2048
DH-2048
ECDH-224
ECDSA-224
場 合
過 去 に 処 理 したも
のを 利 用 する 場 合
利 用 可
過 去 のシステム
との 互 換 性 維 持
の 利 用 だけを 容
認
128 ビット AES-128
特 になし 利 用 可 利 用 可
Camellia-128
ECDH-256
ECDSA-256
SHA-256
128 ビットから RSA-4096 特 になし 利 用 可 利 用 可
192 ビットの 間 DH-4096
HMAC-SHA-1
192 ビット ECDH-384 特 になし 利 用 可 利 用 可
ECDSA-384
SHA-384
256 ビット AES-256
特 になし 利 用 可 利 用 可
Camellia-256
ECDH-521
ECDSA-521
HMAC-SHA256
256 ビット 以 上 HMAC-SHA384 特 になし 利 用 可 利 用 可
SSL/TLS 暗 号 設 定 ガイドライン - 12

PART I:
サーバ 構 築 における 設 定 要 求 項 目 について
SSL/TLS 暗 号 設 定 ガイドライン - 13

3. 設 定 基 準 の 概 要
本 章 では、SSL/TLS サーバの 構 築 時 に、 主 に 暗 号 通 信 に 関 わる 設 定 に 関 しての 要 求 事 項 を 決 め
るために 考 慮 すべきポイントについて 取 りまとめる。
3.1 実 現 すべき 設 定 基 準 の 考 え 方
SSL/TLS は、1994 年 に SSL2.0 が 実 装 されて 以 来 、その 利 便 性 から 多 くの 製 品 に 実 装 され、 利
用 されている。 一 方 、プロトコルの 脆 弱 性 に 対 応 するため、 何 度 かプロトコルとしてのバージョ
ンアップが 行 われている 影 響 で、 製 品 の 違 いによってサポートしているプロトコルバージョンや
暗 号 スイート 等 が 異 なり、 相 互 接 続 性 上 の 問 題 が 生 じる 可 能 性 がある。
本 ガイドラインでは、 安 全 性 の 確 保 と 相 互 接 続 の 必 要 性 のトレードオフにより、「 高 セキュリテ
ィ 型 」「 推 奨 セキュリティ 型 」「セキュリティ 例 外 型 」の 3 段 階 の 設 定 基 準 に 分 けて 各 々の 要 求 設
定 を 定 める。それぞれの 設 定 基 準 における、 安 全 性 と 相 互 接 続 性 についての 関 係 は 表 4のとおり
である。
実 際 にどの 設 定 基 準 を 採 用 するかは、 安 全 性 の 確 保 と 相 互 接 続 の 必 要 性 の 両 面 を 鑑 みて、サー
バ 管 理 やサービス 提 供 に 責 任 を 持 つ 管 理 者 が 最 終 的 に 決 定 すべきことではあるが、 本 ガイドライ
ンでは、 安 全 性 もしくは 相 互 接 続 性 についての 特 段 の 要 求 がなければ「 推 奨 セキュリティ 型 」の
採 用 を 強 く 勧 める。 本 ガイドラインの 発 行 時 点 では、「 推 奨 セキュリティ 型 」がもっとも 安 全 性 と
可 用 性 ( 相 互 接 続 性 )のバランスが 取 れている 要 求 設 定 であると 考 えている。
「セキュリティ 例 外 型 」は、システム 等 の 制 約 上 、 脆 弱 なプロトコルバージョンである SSL3.0
の 利 用 を 全 面 禁 止 することのほうが 現 時 点 ではデメリットが 大 きく、 安 全 性 上 のリスクを 受 容 し
てでも SSL3.0 を 継 続 利 用 せざるを 得 ないと 判 断 される 場 合 にのみ 採 用 すべきである。なお、セキ
ュリティ 例 外 型 であっても、SSL3.0 の 無 期 限 の 継 続 利 用 を 認 めているわけではなく、 近 いうちに
SSL3.0 を 利 用 不 可 に 設 定 するように 変 更 される 可 能 性 がある。
また、SSL3.0 を 利 用 する 関 係 から、 利 用 可 能 な 暗 号 スイートの 設 定 においても、 脆 弱 な 暗 号 ア
ルゴリズムである RC4 の 利 用 を 認 めている。ただし、 本 来 的 には RC4 は SSL3.0 に 限 定 して 利 用
すべきであるが、TLS1.0 以 上 のプロトコルバージョンで RC4 の 利 用 を 不 可 にする 設 定 を 行 うこ
とが 難 しいため、TLS1.0 以 上 であっても RC4 が 使 われる 可 能 性 が 排 除 できないことにも 注 意 さ
れたい。
したがって、セキュリティ 例 外 型 を 採 用 する 際 は、 推 奨 セキュリティ 型 への 早 期 移 行 を 前 提 と
して、 移 行 計 画 や 利 用 終 了 期 限 を 定 めたりするなど、 今 後 への 具 体 的 な 対 処 方 針 の 策 定 をすべき
である。また、 金 融 サービスや 電 子 商 取 引 サービスなど、 不 特 定 多 数 に 公 開 されるサービス 等 に
おいて 使 用 される SSL/TLS サーバであって、やむなくセキュリティ 例 外 型 を 採 用 している 場 合 で
は、 利 用 者 に 対 して「SSL3.0 の 利 用 を 許 可 しており、 脆 弱 な 暗 号 方 式 が 使 われる 場 合 がある」 等
の 注 意 喚 起 を 行 うことが 望 ましい。
SSL/TLS 暗 号 設 定 ガイドライン - 14

表 4 安 全 性 と 相 互 接 続 性 についての 比 較
設 定 基 準 概 要 安 全 性 相 互 接 続 性 の 確 保
高 セキュリティ
扱 う 情 報 が 漏 えいした 際 、 組 織 の 運 営 や 資
本 ガイドライン
最 近 提 供 され 始 め
型
産 、 個 人 の 資 産 やプライバシー 等 に 致 命 的 ま
の 公 開 時 点
たバージョンの OS
たは 壊 滅 的 な 悪 影 響 を 及 ぼすと 予 想 される
(2015 年 5 月 )
やブラウザが 搭 載
情 報 を、 極 めて 高 い 安 全 性 を 確 保 して
において、 標 準
されている PC、スマ
SSL/TLS で 通 信 するような 場 合 に 採 用 する 設
的 な 水 準 を 大 き
ートフォンでなけ
定 基 準
く 上 回 る 高 い 安
れば 接 続 できない
全 性 水 準 を 達 成
可 能 性 が 高 い
※とりわけ 高 い 安 全 性 を 必 要 とする 明 確 な
理 由 があるケースを 対 象 としており、 非 常 に
また、PC、スマート
高 度 で 限 定 的 な 使 い 方 をする 場 合 の 設 定 基
フォン 以 外 では、 最
準 である。 一 般 的 な 利 用 形 態 で 使 うことは 想
新 の 機 器 であって
定 していない
も 一 部 の 機 器 につ
いて 接 続 できない
< 利 用 例 >
可 能 性 がある
政 府 内 利 用 (G2G 型 )のなかでも、 限 定 され
た 接 続 先 に 対 して、とりわけ 高 い 安 全 性 が 要
求 される 通 信 を 行 う 場 合
推 奨
扱 う 情 報 が 漏 えいした 際 、 組 織 の 運 営 や 資
本 ガイドライン
本 ガイドラインで
セキュリティ 型
産 、 個 人 の 資 産 やプライバシー 等 に 何 らかの
の 公 開 時 点
対 象 とするブラウ
悪 影 響 を 及 ぼすと 予 想 される 情 報 を、 安 全 性
(2015 年 5 月 )
ザ(8.1.2 節 )が 搭 載
確 保 と 利 便 性 実 現 をバランスさせて SSL/TLS
における 標 準 的
されている PC、スマ
での 通 信 を 行 うための 標 準 的 な 設 定 基 準
な 安 全 性 水 準 を
ートフォンなどで
実 現
は 問 題 なく 相 互 接
※ほぼすべての 一 般 的 な 利 用 形 態 で 使 うこ
続 性 を 確 保 できる
とを 想 定 している
本 ガイドラインが
< 利 用 例 >
対 象 としない、バー
• 政 府 内 利 用 (G2G 型 )や 社 内 システムへの
ジョンが 古 い OS や
リモートアクセスなど、 特 定 された 通 信 相
ブラウザの 場 合 や
手 との 安 全 な 通 信 が 要 求 される 場 合
発 売 開 始 からある
• 電 子 申 請 など、 企 業 ・ 国 民 と 役 所 等 との 電
程 度 の 年 月 が 経 過
子 行 政 サービスを 提 供 する 場 合
している 一 部 の 古
• 金 融 サービスや 電 子 商 取 引 サービス、 多 様
い 機 器 (フィーチャ
な 個 人 情 報 の 入 力 を 必 須 とするサービス 等
ーフォンやゲーム
を 提 供 する 場 合
機 など)については
• 既 存 システムとの 相 互 接 続 を 考 慮 すること
接 続 できない 可 能
なく、 新 規 に 社 内 システムを 構 築 する 場 合
性 がある
SSL/TLS 暗 号 設 定 ガイドライン - 15

安 全 性 と 相 互 接 続 性 についての 比 較 ( 続 )
設 定 基 準 概 要 安 全 性 相 互 接 続 性 の 確 保
セキュリティ
脆 弱 なプロトコルバージョンや 暗 号 が 使 わ
推 奨 セキュリテ
最 新 ではないフィ
例 外 型
れるリスクを 受 容 したうえで、 安 全 性 よりも
ィ 型 への 移 行 完
ーチャーフォンや
相 互 接 続 性 に 対 する 要 求 をやむなく 優 先 さ
了 までの 短 期 的
ゲーム 機 などを 含
せて SSL/TLS での 通 信 を 行 う 場 合 に 許 容 し
な 利 用 を 前 提
めた、ほとんどのす
うる 最 低 限 度 の 設 定 基 準
に、 本 ガイドラ
べての 機 器 につい
インの 公 開 時 点
て 相 互 接 続 性 を 確
※ 推 奨 セキュリティ 型 への 早 期 移 行 を 前 提
(2015 年 5 月 )
保 できる
として、 暫 定 的 に 利 用 継 続 するケースを 想 定
において 許 容 可
している
能 な 最 低 限 の 安
全 性 水 準 を 満 た
< 利 用 例 >
す
• 利 用 するサーバやクライアントの 実 装 上 の
制 約 、もしくは 既 存 システムとの 相 互 接 続
上 の 制 約 により、 推 奨 セキュリティ 型 ( 以
上 )の 設 定 が 事 実 上 できない 場 合
3.2 要 求 設 定 の 概 要
SSL/TLS における 暗 号 通 信 に 関 わる 設 定 には 以 下 のものがある。
• プロトコルバージョンの 設 定 ( 第 4 章 )
• サーバ 証 明 書 の 設 定 ( 第 5 章 )
• 暗 号 スイートの 設 定 ( 第 6 章 )
• SSL/TLS を 安 全 に 使 うために 考 慮 すべきこと( 第 7 章 )
本 ガイドラインでは、 上 記 の 設 定 項 目 のうち、プロトコルバージョン、サーバ 証 明 書 、 暗 号 ス
イートの 3 つの 項 目 について、3.1 節 に 記 載 した 設 定 基 準 に 対 応 した 詳 細 な 要 求 設 定 を 該 当 章 に
各 々まとめている。 表 5に 要 求 設 定 の 概 要 を 記 す。
SSL/TLS 暗 号 設 定 ガイドライン - 16

表 5 要 求 設 定 の 概 要
要 件 高 セキュリティ 型 推 奨 セキュリティ 型 セキュリティ 例 外 型
想 定 対 象 G2G 一 般 レガシー 携 帯 電 話 含 む
暗 号 スイートの
1256 bit
1128 bit
1 128 bit
( 暗 号 化 の)セキュリティ
2128 bit
2256 bit
2 256 bit
レベル
3 RC4, Triple DES
暗 号 ア
鍵 交 換
鍵 長 2048 ビット 以 上 の
鍵 長 1024 ビット 以 上 の DHE または 鍵 長 256 ビッ
ルゴリ
DHE または 鍵 長 256
ト 以 上 の ECDHE
ズム
ビット 以 上 の ECDHE
鍵 長 2048 ビット 以 上 の RSA
鍵 長 256 ビット 以 上 の ECDH
暗 号 化
鍵 長 128 ビット 及 び 256 ビットの AES または Camellia
RC4
Triple DES
モード GCM GCM, CBC
ハッシュ 関 数 SHA-384, SHA-256 SHA-384, SHA-256, SHA-1
プロトコルバージョン TLS1.2 のみ TLS1.2 ~ TLS1.0 TLS1.2~1.0, SSL3.0
証 明 書 鍵 長
鍵 長 2048 ビット 以 上 の RSA または 鍵 長 256 ビット 以 上 の ECDSA
証 明 書 でのハッシュ 関 数 SHA-256 SHA-256, SHA-1
3.3 チェックリスト
図 2に 高 セキュリティ 型 のチェックリストのイメージを 示 す。
チェックリストの 目 的 は、
• 選 択 した 設 定 基 準 に 対 応 した 要 求 設 定 項 目 をもれなく 実 施 したことを 確 認 し、 設 定 忘 れを
防 止 すること
• サーバ 構 築 の 作 業 受 託 先 が 適 切 に 要 求 設 定 項 目 を 設 定 したことを、 発 注 者 が 文 書 として 確
認 する 手 段 を 与 えること
である。したがって、 選 択 した 設 定 基 準 に 応 じたチェックリストを 用 い、すべてのチェック 項 目
について、 該 当 章 に 記 載 の 要 求 設 定 に 合 致 していることを 確 認 して「 済 」にチェックが 入 ること
が 求 められる。
Appendix A には、 各 々の 設 定 基 準 に 対 応 したチェックリストを 載 せる。
SSL/TLS 暗 号 設 定 ガイドライン - 17

図 2 チェックリス
スト( 高 セキュリティ型 の 例 )
SSL/TLS 暗 号 設 定 ガイドライン -
18

4. プロトコルバージョンの 設 定
SSL/TLS は、1994 年 に SSL2.0 が 実 装 され 始 めた 後 、2014 年 3 月 現 在 の 最 新 版 となる TLS1.2
まで 5 つのプロトコルバージョンが 実 装 されている。4.1 節 にプロトコルバージョンについての
要 求 設 定 をまとめる。4.2 節 にプロトコルバージョンごとの 安 全 性 の 違 いを 記 す。
4.1 プロトコルバージョンについての 要 求 設 定
基 本 的 に、プロトコルのバージョンが 後 になるほど、 以 前 の 攻 撃 に 対 する 対 策 が 盛 り 込 まれる
ため、より 安 全 性 が 高 くなる。しかし、 相 互 接 続 性 も 確 保 する 観 点 から、 多 くの 場 合 、 複 数 のプ
ロトコルバージョンが 利 用 できるように 実 装 されているので、プロトコルバージョンの 選 択 順 位
を 正 しく 設 定 しておかなければ、 予 想 外 のプロトコルバージョンで SSL/TLS 通 信 を 始 めることに
なりかねない。
そこで、SSL2.0 から TLS1.2 までの 安 全 性 の 違 い(4.2 節 表 6 参 照 )を 踏 まえ、SSL/TLS サー
バがサポートするプロトコルバージョンについての 要 求 設 定 を 以 下 のように 定 める。なお、 高 セ
キュリティ 型 の 要 求 設 定 ではサーバとクライアントの 両 方 が TLS1.2 をサポートしていることが
必 須 となることに 注 意 されたい。
【 高 セキュリティ 型 の 要 求 設 定 】
• TLS1.2 を 設 定 有 効 にする
• TLS1.1 以 前 を 設 定 無 効 ( 利 用 不 可 )にする
TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0
◎ × × × ×
◎: 設 定 有 効 ×: 設 定 無 効 化 -: 実 装 なし
【 推 奨 セキュリティ 型 の 要 求 設 定 】
• SSL3.0 及 び SSL2.0 を 設 定 無 効 ( 利 用 不 可 )にする
• TLS1.1、TLS1.2 については、 実 装 されているのであれば、 設 定 有 効 にする
• プロトコルバージョンの 優 先 順 位 が 設 定 できる 場 合 には、 設 定 有 効 になっているプロトコ
ルバージョンのうち、 最 も 新 しいバージョンによる 接 続 を 最 優 先 とし、 接 続 できない 場 合
に 順 番 に 一 つずつ 前 のプロトコルバージョンでの 接 続 するように 設 定 することが 望 ましい
TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0
◎ ○ ○ × ×
- ◎ ○ × ×
- - ◎ × ×
○: 設 定 有 効 (◎: 優 先 するのが 望 ましい) ×: 設 定 無 効 化 -: 実 装 なし
SSL/TLS 暗 号 設 定 ガイドライン - 19

【セキュリティ 例 外 型 の 要 求 設 定 】
• SSL2.0 を 設 定 無 効 ( 利 用 不 可 )にする
• TLS1.1、TLS1.2 については、 実 装 されているのであれば、 設 定 有 効 にする
• プロトコルバージョンの 優 先 順 位 が 設 定 できる 場 合 には、 設 定 有 効 になっているプロトコ
ルバージョンのうち、 最 も 新 しいバージョンによる 接 続 を 最 優 先 とし、 接 続 できない 場 合
に 順 番 に 一 つずつ 前 のプロトコルバージョンでの 接 続 するように 設 定 することが 望 ましい
TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0
◎ ○ ○ ○ ×
3 つのうち
- ◎ ○ ○ ×
のいずれか
- - ◎ ○ ×
○: 設 定 有 効 (◎: 優 先 するのが 望 ましい) ×: 設 定 無 効 化 -: 実 装 なし
4.2 プロトコルバージョンごとの 安 全 性 の 違 い
SSL2.0 から TLS1.2 までの 各 プロトコルバージョンにおける 安 全 性 の 違 いを 表 6にまとめる。
表 6 プロトコルバージョンでの 安 全 性 の 違 い
SSL/TLS への 攻 撃 方 法 に 対 する 耐 性 TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0
ダウングレード 攻 撃 ( 最 弱 の 暗 号 アルゴリズム
を 強 制 的 に 使 わせることができる)
バージョンロールバック 攻 撃 (SSL2.0 を 強 制
的 に 使 わせることができる)
安 全 安 全 安 全 安 全 脆 弱
安 全 安 全 安 全 安 全 脆 弱
ブロック 暗 号 の CBC モード 利 用 時 の 脆 弱 性
を 利 用 した 攻 撃 (BEAST/POODLE 攻 撃 など)
安 全
安 全
パッチ
適 用 要
脆 弱
脆 弱
利 用 可 能 な 暗 号 アルゴリズム TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0
128 ビットブロック 暗 号 (AES, Camellia) 可 可 可 不 可 不 可
認 証 付 暗 号 利 用 モード(GCM, CCM) 可 不 可 不 可 不 可 不 可
楕 円 曲 線 暗 号 可 可 可 不 可 不 可
SHA-2 ハッシュ 関 数 (SHA-256, SHA-384) 可 不 可 不 可 不 可 不 可
SSL/TLS 暗 号 設 定 ガイドライン - 20

【コラム1】 SSL3.0 への 大 打 撃 となっ った POODLE 攻 撃
POODLE 攻 撃 は BEAST 攻 撃 に 似 た 攻 撃 方 法 であり、SSL3.00 にてブロック 暗 号 を CBC モ
ードで 利 用 する 場 合 の 脆 弱 性 を 利 用 した
攻 撃 方 法 である。BEA
AST 攻 撃 同 様 、 例 えば、 中 間
者 攻 撃 や 攻 撃 対 象 に 大 量 の 通 信 を 発 生 させるなど、
攻 撃 には 複 数 の 条 件 が 必 要 であり、ただ
ちに 悪 用 可 能 な 脆 弱 性 ではない。
ただ、 BEAST 攻 撃 に 対 しては 脆 弱 性 を 回 避 するためのセキュリティパッチが 公 開 されて
おり、 技 術 的 にもプロトコルそのものを 変 更 しなくても 平 文 を 1 対 (N-1)のの 分 割 を 行 うことで
回 避 できる 可 能 性 が 示 されている。これに 対 して、 POODLE 攻 撃 は SSL3.0 のパディングチ
ェックの
仕 組 み 自 体 の 脆 弱 性 に 起 因 している。 具 体 的 には、SSL3.0 はパディングの
最 終 1
バイト 分 だけをチェックして正 しければメッセージ
全 体 が 正 しいと 判 断 する 仕 様 であるた
め、 攻 撃 者 が 作 った
偽 のメッセージであっても 1/256 の 確 率 で 正 しいものとしてサー
ーバが 受
理 してしまうことを
利 用 した 攻 撃 方 法 である。
つまり、POODLEE 攻 撃 は SSL3.0 の 仕 様 上 の 脆 弱 性 に 起 因 することから
ら、 脆 弱 性 を 回 避 す
るためのセキュリティパッチが
公 開 されていない。
このため、 SSL3.0 自 体 が 古 いプロトコル
バージョンであることもあり、
、ブラウザベンダは 順 次 SSL3.0 をデフォルトで 利 用 不 可 とす
る 対 策 を 取 っている( 詳 細 は 8.3.2 節 参 照 )。ま た 、SSL/TLS サー ーバ 構 築 者 に 対 しては、SSL3.0
を 無 効 化 するための
手 順 を IPA
が 公 表 している。
その 後 、POODLEE again ということで「TLS1.x でも POODLEE 攻 撃 が 可 能 」との 情 報 14 が 公
開 された。ただし、
これは、SSL3.0 とは
違 い、TLS1.x の 仕 様 でも POODLE 攻 撃 が 可 能 とい
うことではない。 実 際 の TLS1.x の 仕 様 では、パディングの 全 データをチェックしなければ
ならないことになっ
っており、 仕 様 通 りに実 装 されていれば、 攻 撃 者 が 作 っ った 偽 のメッセージ
をサーバが 受 理 する
確 率 は 極 めて 小 さい( 具 体 的 には 2^(パディング 長 ) 分 の 1)。
ところが、 実 際 の 製 品 においては、TLS1.x の 仕 様 に 反 して、 パディングチェックを
SSL3.0
と 同 じ 最 終 1 バイト 分 しか 行 っていないものが 数 多 く 見 つかり 15 、TLS1.x を 使 っていても
POODLE
攻 撃 と 同 じ 手 法 が 使 えてしまっ った 実 装 上 の 問 題 が 発 覚 した。これ れが、POODLE again
の 正 体 であり、すぐに 該 当 する 製 品 についてはセキュリティパッチが 提 供 された。
14 https://www.imperialviolet.org/2014/12/08/poodleagain.html
15 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8730
SSL/TLS 暗 号 設 定 ガイドライン -
21

5. サーバ 証 明 書 の 設 定
サーバ 証 明 書 は、1クライアントに 対 して、 情 報 を 送 受 信 するサーバが 意 図 する 相 手 (サーバ
の 運 営 組 織 等 )によって 管 理 されるサーバであることを 確 認 する 手 段 を 提 供 することと、2
SSL/TLS による 暗 号 通 信 を 行 うために 必 要 なサーバの 公 開 鍵 情 報 をクライアントに 正 しく 伝 える
こと、の 2 つの 役 割 を 持 っている。
これらの 役 割 を 正 しく 実 行 するために、5.1 節 にサーバ 証 明 書 についての 要 求 設 定 をまとめる。
5.2 節 以 降 にはサーバ 証 明 書 の 設 定 を 決 める 際 の 検 討 項 目 の 概 要 を 記 す。
5.1 サーバ 証 明 書 についての 要 求 設 定
後 述 する 5.2 節 以 降 の 内 容 を 踏 まえ、サーバ 証 明 書 についての 要 求 設 定 を 以 下 のように 定 める。
なお、 本 ガイドライン 公 開 時 点 (2015 年 5 月 )においては、 推 奨 セキュリティ 型 の 要 求 設 定 は 高
セキュリティ 型 と 同 様 とする。
高 セキュリティ 型 ( 推 奨 セキュリティ 型 )の 要 求 設 定 では、 少 なくともハッシュ 関 数 として
SHA-256 が 使 えることが 必 須 条 件 となることに 注 意 されたい。 例 えば、SHA-256 が 使 えないブラ
ウザ(クライアント)では、サーバ 証 明 書 の 検 証 ができず、 警 告 表 示 が 出 るか、 当 該 サーバとの
接 続 は 不 能 となる。このことは、DSA や ECDSA を 使 う 場 合 についても 同 様 である。
一 方 、セキュリティ 例 外 型 の 要 求 設 定 では、ハッシュ 関 数 として SHA-1 の 利 用 も 許 容 しており、
過 去 のシステムとの 相 互 接 続 性 は 高 い。ただし、 最 新 のブラウザでは SHA-1 を 使 うサーバ 証 明 書
に 対 して 警 告 表 示 を 出 すようになってきていることに 注 意 すること。
この 他 、 非 技 術 的 要 因 として、ECDSA を 採 用 する 際 にはパテントリスクの 存 在 16 が 広 く 指 摘 さ
れているので、 十 分 な 検 討 のうえで 採 用 の 可 否 を 決 めることが 望 ましい。
DSA については、5.3 節 で 示 すように 電 子 政 府 推 奨 暗 号 リストに 選 定 されており、 安 全 性 上 の
問 題 はない。しかし、サーバ 証 明 書 としては 現 時 点 でほとんど 利 用 されておらず、 技 術 的 にも RSA
や ECDSA と 比 較 して 大 きなメリットがあるとは 言 えないことから、 本 ガイドラインでは 積 極 的
には DSA の 利 用 を 勧 めない 17 。
16
楕 円 曲 線 暗 号 の 標 準 化 ・ 規 格 化 を 推 進 するコンソーシアム SECG に 対 して、Certicom 社 から 特
許 レター(RAND 条 件 でのライセンス 許 諾 )が 通 知 されている。 詳 細 は 以 下 を 参 照 のこと
http://www.secg.org/certicom_patent_letter_SECG.pdf
17
本 ガイドラインでは、DSA は 利 用 しないことを 要 求 設 定 の 前 提 としているため、6 章 の 暗 号 ス
イートの 設 定 からも DSA を 利 用 する 暗 号 スイートが 除 外 されていることに 留 意 されたい
SSL/TLS 暗 号 設 定 ガイドライン - 22

【 高 セキュリティ 型 の 要 求 設 定 】
• 本 ガイドライン 公 開 時 点 (2015 年 5 月 )で、 多 くの 認 証 局 から 入 手 可 能 なサーバ 証 明 書 の
うち、 安 全 性 が 高 いものを 利 用 する。
サーバ 証 明 書 の
アルゴリズムと
鍵 長
サーバ 証 明 書 の 発 行 ・ 更 新 を 要 求 する 際 に 生 成 する 鍵 情 報 (Subject Public
Key Info)でのアルゴリズム(Subject Public Key Algorithm)と 鍵 長 として
は、 以 下 のいずれかを 必 須 とする。
• RSA(OID = 1.2.840.113549.1.1.1)で 鍵 長 は 2048 ビット 以 上
• 楕 円 曲 線 暗 号 で 鍵 長 256 ビット 以 上 (NIST P-256 の 場 合 の OID =
1.2.840.10045.3.1.7)
サーバ 証 明 書 の
発 行 ・ 更 新 時 の
鍵 情 報 の 生 成
クライアントでの
警 告 表 示 の 回 避
また、 認 証 局 が 発 行 するサーバ 証 明 書 での 署 名 アルゴリズム(Certificate
Signature Algorithm)と 鍵 長 については、 以 下 のいずれかを 必 須 とする。
• RSA 署 名 と SHA-256 の 組 合 せ(sha256WithRSAEncryption; OID =
1.2.840.113549.1.1.11)で 鍵 長 2048 ビット 以 上
• ECDSA と SHA-256 の 組 合 せ ( ecdsa-with-SHA256; OID =
1.2.840.10045.4.3.2)で 鍵 長 256 ビット(NIST P-256) 以 上
• サーバ 証 明 書 の 発 行 ・ 更 新 を 要 求 する 際 には、 既 存 の 鍵 情 報 は 再 利 用
せず、 必 ず 新 たに 公 開 鍵 と 秘 密 鍵 の 鍵 ペアを 生 成 しなければならない
• 上 記 の 指 示 をサーバ 管 理 者 への 仕 様 書 、 運 用 手 順 書 、ガイドライン 等
に 明 示 しなければならない
• 当 該 サーバに 接 続 することが 想 定 されている 全 てのクライアントに
対 して、 以 下 のいずれかの 手 段 を 用 いて 警 告 表 示 が 出 ないようにしな
ければならない
‣ パブリック 認 証 局 からサーバ 証 明 書 を 入 手 する
‣ 警 告 表 示 が 出 るクライアントの 利 用 を 禁 ずる 措 置 を 取 る
‣ 5.4.2 節 の 例 外 規 定 に 従 って、 信 頼 できるプライベート 認 証 局 のル
ート CA 証 明 書 をインストールする
SSL/TLS 暗 号 設 定 ガイドライン - 23

【 推 奨 セキュリティ 型 の 要 求 設 定 ( 高 セキュリティ 型 の 要 求 設 定 と 同 じ)】
• 本 ガイドライン 公 開 時 点 (2015 年 5 月 )で、 多 くの 認 証 局 から 入 手 可 能 なサーバ 証 明 書 の
うち、 安 全 性 が 高 いものを 利 用 する。
サーバ 証 明 書 の
暗 号 アルゴリズム
と 鍵 長
サーバ 証 明 書 の 発 行 ・ 更 新 を 要 求 する 際 に 生 成 する 鍵 情 報 (Subject Public
Key Info)でのアルゴリズム(Subject Public Key Algorithm)と 鍵 長 として
は、 以 下 のいずれかを 必 須 とする。
• RSA(OID = 1.2.840.113549.1.1.1)で 鍵 長 は 2048 ビット 以 上
• 楕 円 曲 線 暗 号 で 鍵 長 256 ビット 以 上 (NIST P-256 の 場 合 の OID =
1.2.840.10045.3.1.7)
サーバ 証 明 書 の
発 行 ・ 更 新 時 の
鍵 情 報 の 生 成
クライアントでの
警 告 表 示 の 回 避
また、 認 証 局 が 発 行 するサーバ 証 明 書 での 署 名 アルゴリズム(Certificate
Signature Algorithm)と 鍵 長 については、 以 下 のいずれかを 必 須 とする。
• RSA 署 名 と SHA-256 の 組 合 せ(sha256WithRSAEncryption; OID =
1.2.840.113549.1.1.11)で 鍵 長 2048 ビット 以 上
• ECDSA と SHA-256 の 組 合 せ ( ecdsa-with-SHA256; OID =
1.2.840.10045.4.3.2)で 鍵 長 256 ビット(NIST P-256) 以 上
• サーバ 証 明 書 の 発 行 ・ 更 新 を 要 求 する 際 には、 既 存 の 鍵 情 報 は 再 利 用
せず、 必 ず 新 たに 公 開 鍵 と 秘 密 鍵 の 鍵 ペアを 生 成 しなければならない
• 上 記 の 指 示 をサーバ 管 理 者 への 仕 様 書 、 運 用 手 順 書 、ガイドライン 等
に 明 示 しなければならない
• 当 該 サーバに 接 続 することが 想 定 されている 全 てのクライアントに
対 して、 以 下 のいずれかの 手 段 を 用 いて 警 告 表 示 が 出 ないようにする
か、 警 告 表 示 が 出 るブラウザはサポート 対 象 外 であることを 明 示 しな
ければならない
‣ パブリック 認 証 局 からサーバ 証 明 書 を 入 手 する
‣ 警 告 表 示 が 出 るクライアントの 利 用 を 禁 ずる 措 置 を 取 る
‣ 5.4.2 節 の 例 外 規 定 に 従 って、 信 頼 できるプライベート 認 証 局 のル
ート CA 証 明 書 をインストールする
SSL/TLS 暗 号 設 定 ガイドライン - 24

【セキュリティ 例 外 型 の 要 求 設 定 】
• 本 ガイドライン 公 開 時 点 (2015 年 5 月 )で、 多 くの 認 証 局 から 入 手 可 能 なサーバ 証 明 書 の
うち、 許 容 可 能 な 水 準 以 上 の 安 全 性 を 確 保 しているサーバ 証 明 書 で、 最 も 相 互 接 続 性 が 高
いものを 利 用 する。 具 体 的 には、ハッシュ 関 数 について、1SHA-256 では 相 互 接 続 できな
いブラウザが 一 定 程 度 存 在 する 可 能 性 が 否 定 できないこと、2MD5 のような 証 明 書 偽 造 に
つながる 可 能 性 がある 致 命 的 な 脆 弱 性 が 発 見 されていないこと、から SHA-1 の 利 用 を 許 容
する。
• セキュリティ 例 外 型 においては、 楕 円 曲 線 暗 号 を 利 用 したサーバ 証 明 書 の 場 合 、 十 分 な 相
互 接 続 性 が 確 保 できるとは 必 ずしも 言 えないため、RSA の 利 用 を 勧 める。
サーバ 証 明 書 の
暗 号 アルゴリズム
と 鍵 長
サーバ 証 明 書 の 発 行 ・ 更 新 を 要 求 する 際 に 生 成 する 鍵 情 報 (Subject Public
Key Info)でのアルゴリズム(Subject Public Key Algorithm)と 鍵 長 として
は、 以 下 のいずれかを 必 須 とする。
• RSA(OID = 1.2.840.113549.1.1.1)で 鍵 長 は 2048 ビット 以 上
サーバ 証 明 書 の
発 行 ・ 更 新 時 の
鍵 情 報 の 生 成
クライアントでの
警 告 表 示 の 回 避
また、 認 証 局 が 発 行 するサーバ 証 明 書 での 署 名 アルゴリズム(Certificate
Signature Algorithm)と 鍵 長 については、 以 下 のいずれかを 必 須 とする。
なお、SHA-256 との 組 合 せのほうが 望 ましいが、 状 況 によっては SHA-1
との 組 合 せを 選 んでもよい。
• RSA 署 名 と SHA-256 の 組 合 せ(sha256WithRSAEncryption; OID =
1.2.840.113549.1.1.11)で 鍵 長 2048 ビット 以 上
• RSA 署 名 と SHA-1 の 組 合 せ(sha1WithRSAEncryption; OID =
1.2.840.113549.1.1.5)で 鍵 長 2048 ビット 以 上
※ 過 去 のシステム・ブラウザ 等 との 相 互 接 続 性 の 確 保 を 優 先 するなら
SHA-1 を 利 用 したサーバ 証 明 書 のほうがよいが、 最 新 のブラウザでは
SHA-1 を 使 うサーバ 証 明 書 に 対 して 警 告 表 示 を 出 すようになってきて
いることに 注 意 すること。 詳 細 については 8.3.1 節 を 参 照 のこと
• サーバ 証 明 書 の 発 行 ・ 更 新 を 要 求 する 際 には、 既 存 の 鍵 情 報 は 再 利 用
せず、 必 ず 新 たに 公 開 鍵 と 秘 密 鍵 の 鍵 ペアを 生 成 しなければならない
• 上 記 の 指 示 をサーバ 管 理 者 への 仕 様 書 、 運 用 手 順 書 、ガイドライン 等
に 明 示 しなければならない
• 当 該 サーバに 接 続 することが 想 定 されている 全 てのクライアントに
対 して、 以 下 のいずれかの 手 段 を 用 いて 警 告 表 示 が 出 ないようにする
か、 警 告 表 示 が 出 るブラウザはサポート 対 象 外 であることを 明 示 しな
ければならない
‣ パブリック 認 証 局 からサーバ 証 明 書 を 入 手 する
‣ 警 告 表 示 が 出 るクライアントの 利 用 を 禁 ずる 措 置 を 取 る
‣ 5.4.2 節 の 例 外 規 定 に 従 って、 信 頼 できるプライベート 認 証 局 のル
ート CA 証 明 書 をインストールする
SSL/TLS 暗 号 設 定 ガイドライン - 25

5.2 サーバ 証 明 書 に 記 載 されている 情 報
サーバ 証 明 書 には、 表 7に 示 す 情 報 が 記 載 されている。これらの 情 報 は、 証 明 書 プロパティの
「 詳 細 」で 見 ることができる。
これらのうち、 当 該 サーバ 証 明 書 を 発 行 した 認 証 局 が「Issuer( 発 行 者 )」となり、 当 該 認 証 局
がサーバ 証 明 書 に 施 すアルゴリズムが「Certificate Signature Algorithm( 署 名 アルゴリズム)」、 実
際 の 署 名 値 が「Certificate Signature Value」として 記 載 される。
SSL/TLS サーバを 運 用 するものは「Subject(サブジェクト- 発 行 対 象 )」となり、 当 該 サーバ
自 身 が 利 用 する 公 開 鍵 の 情 報 が「Subject Public Key Info( 公 開 鍵 情 報 )」として 記 載 される。 公 開
鍵 情 報 には「Subject Public Key Algorithm( 公 開 鍵 を 使 う 時 の 暗 号 アルゴリズム)」と「Subject’s
Public Key( 実 際 の 公 開 鍵 の 値 )」が 含 まれており、その 公 開 鍵 をどのように 使 うかは「Certificate
Key Usage(キー 使 用 法 )」に 記 載 される。
例 えば、Subject Public Key Algorithm に「RSA」、Certificate Key Usage に「Signing, Key Encipherment」
とある 場 合 には、Subject’s Public Key に 書 かれた 公 開 鍵 は、 対 応 する 秘 密 鍵 で 作 られた RSA 署 名
(Signing)の 検 証 用 途 にも、セッション 鍵 を 送 付 する RSA 暗 号 化 (Key Encipherment) 用 途 にも
使 えることを 意 味 する。
表 7 サーバ 証 明 書 に 記 載 される 情 報
証 明 書 のバージョン
シリアル 番 号
署 名 アルゴリズム
発 行 者
有 効 期 間 ( 開 始 ~ 終 了 )
サブジェクト( 発 行 対 象 )
18
(サブジェクトが 使 う) 公 開 鍵 情 報
拡 張 情 報
Version
Serial Number
Certificate Signature Algorithm
Issuer
Validity (Not Before ~ Not After)
Subject
Subject Public Key Info (Algorithm, Public Key Value)
Extensions
キー 使 用 法 Certificate Key Usage
署 名
Certificate Signature Value
5.3 サーバ 証 明 書 で 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム
本 ガイドラインにおいて「サーバ 証 明 書 で 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム」とは、サ
18 Windows の 証 明 書 プロパティでは『 公 開 キー』と 表 記 されているが、 本 文 中 では『 公 開 鍵 』
で 表 記 を 統 一 する。
SSL/TLS 暗 号 設 定 ガイドライン - 26

ーバ 証 明 書 の 仕 様 に 合 致 するものに 採 用 されている「 署 名 」と「ハッシュ 関 数 」のうち、CRYPTREC
暗 号 リスト(2.2.1 節 参 照 )にも 掲 載 されているものとする。 具 体 的 には、 表 8に 示 した「 署 名 」
と「ハッシュ 関 数 」である。
現 在 発 行 されているサーバ 証 明 書 は、 大 多 数 が RSA と SHA-256 との 組 合 せによるものか、RSA
と SHA-1 との 組 み 合 わせによるものである。 特 に 最 近 では、 安 全 性 向 上 が 必 要 との 観 点 から SHA-1
から SHA-256 への 移 行 も 急 速 に 進 みだしている。また、RSA でも 鍵 長 が 1024 ビットから 2048
ビットへ 移 行 している 一 方 、 処 理 性 能 の 低 下 を 避 けるために 鍵 長 256 ビットの ECDSA を 採 用 す
るケースも 増 えてきている。
実 際 に、 従 来 RSA と SHA-1 の 組 合 せでしかサーバ 証 明 書 を 発 行 しなかった 認 証 局 でも、
SHA-256 や ECDSA に 対 応 したサーバ 証 明 書 を 発 行 するようになってきている。このような 動 き
に 対 応 し、 比 較 的 新 しいブラウザやクライアント 機 器 では SHA-256 や ECDSA を 使 ったサーバ 証
明 書 でも 問 題 なく 検 証 できるようになっている。
ただし、 本 ガイドライン 公 開 時 点 (2015 年 5 月 )では、 古 い 機 器 などを 中 心 に、SHA-256 や ECDSA
を 使 ったサーバ 証 明 書 の 検 証 ができないクライアントも 相 当 数 存 在 していると 考 えられるため、
古 い 機 器 との 相 互 接 続 性 の 確 保 を 考 慮 するのであれば、 一 定 の 配 慮 が 必 要 となる。
表 8 サーバ 証 明 書 で 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム
技 術 分 類 リストの 種 類 アルゴリズム 名
署 名 電 子 政 府 推 奨 暗 号 リスト RSASSA PKCS#1 v1.5(RSA)
DSA
ECDSA
ハッシュ 関 数 電 子 政 府 推 奨 暗 号 リスト SHA-256
運 用 監 視 暗 号 リスト SHA-1
5.4 サーバ 証 明 書 で 考 慮 すべきこと
5.4.1 信 頼 できないサーバ 証 明 書 の 利 用 は 止 める
ブラウザなどをはじめとするサーバ 証 明 書 を 検 証 するアプリケーションには、 一 定 の 基 準 に 準
拠 した 認 証 局 の 証 明 書 (ルート CA 証 明 書 )があらかじめ 登 録 されており、これらの 認 証 局 (と
その 下 位 認 証 局 )はパブリック 認 証 局 と 呼 ばれている。 一 般 に、パブリック 認 証 局 が、 第 三 者 の
立 場 から 確 認 したサーバの 運 営 組 織 等 の 情 報 を 記 載 したサーバ 証 明 書 を 発 行 し、ブラウザに 予 め
搭 載 されたルート CA 証 明 書 と 組 合 せて 検 証 を 行 うことで、サーバ 証 明 書 の 信 頼 性 を 確 保 する。
これにより、 当 該 サーバ 証 明 書 の 正 当 性 が 確 認 できれば、ブラウザは 警 告 表 示 することなく、 当
該 サーバへの 接 続 を 行 う。
一 方 、 証 明 書 の 発 行 プログラムさえあれば 誰 もがサーバ 証 明 書 を 作 ることができるが、これで
はサーバ 構 築 者 が“ 自 分 は 正 当 なサーバ”であると 自 己 主 張 しているに 過 ぎない。このようなサ
ーバ 証 明 書 は“オレオレ 証 明 書 ”ともいわれ、ブラウザでは 当 該 サーバ 証 明 書 の 正 当 性 が 確 認 で
SSL/TLS 暗 号 設 定 ガイドライン - 27

きない“ 危 険 なサーバ”として 警 告 が 表 示 される。
本 来 、SSL/TLS における 重 要 な 役 割 の 一 つが 接 続 するサーバの 認 証 であり、その 認 証 をサーバ
証 明 書 で 行 う 仕 組 みである 以 上 、“ 危 険 なサーバ”との 警 告 表 示 が 出 るにもかかわらず、その 警 告
を 無 視 して 接 続 するよう 指 示 しなければならないサーバ 構 築 の 仕 方 をすべきではない。
5.4.2 ルート CA 証 明 書 の 安 易 な 手 動 インストールは 避 ける
5.4.1 節 のようにして 発 行 されたサーバ 証 明 書 を 利 用 した SSL/TLS サーバを“ 危 険 なサーバ”
として 認 識 させない 手 段 として、 当 該 サーバ 証 明 書 の 正 当 性 を 確 認 するためのルート CA 証 明 書
を、ブラウザ(クライアント)の「 信 頼 できるルート CA」に 手 動 でインストールする 方 法 があ
る。
しかし、 安 易 に「 信 頼 できるルート CA」として 手 動 インストールをすることは、“ 危 険 なサー
バ”との 警 告 を 意 図 的 に 無 視 することにつながる。また、5.4.1 節 に 記 載 したパブリック 認 証 局 の
ルート CA 証 明 書 とは 異 なり、これら 手 動 インストールしたルート CA 証 明 書 はブラウザベンダ
によって 管 理 されていない。このため、 万 が 一 、 当 該 ルート CA 証 明 書 の 安 全 性 に 問 題 が 生 じた
場 合 でも、ブラウザベンダによって 自 動 的 に 無 効 化 されることはなく、インストールした 当 該 ル
ート CA 証 明 書 を 利 用 者 自 身 が 手 動 で 削 除 する 必 要 がある。もし、 削 除 を 怠 ると 不 正 なサーバ 証
明 書 を 誤 信 するリスクが 増 大 する。
したがって、ルート CA 証 明 書 の 手 動 インストールは 原 則 として 避 けるべきであり、ましてや
利 用 者 に 対 して 手 動 インストールを 求 めるような 運 用 をすべきではない。
例 外 的 にルート CA 証 明 書 の 手 動 インストールを 行 う 必 要 がある 場 合 には、ルート CA 証 明 書
の 安 全 性 に 問 題 が 生 じた 場 合 にインストールを 勧 めた 主 体 によって、 利 用 者 のブラウザから 当 該
ルート CA 証 明 書 の 無 効 化 や 削 除 ができるようにする 等 、インストールした 利 用 者 に 対 して 具 体
的 に 責 任 を 負 うことができる 体 制 を 整 えるべきである。
例 えば、 企 業 ・ 団 体 等 が 自 身 の 管 理 する 端 末 に 対 して、 当 該 組 織 が 自 前 で 構 築 した、 言 わばプ
ライベートなルート CA 証 明 書 をシステム 管 理 部 門 等 の 管 理 下 でインストールし、また 当 該 ルー
ト CA 証 明 書 の 安 全 性 に 問 題 が 生 じた 場 合 には、 速 やかに 当 該 部 門 が 各 端 末 に 対 して 当 該 ルート
CA 証 明 書 を 無 効 化 する 措 置 を 講 ずることができるような 体 制 である。 具 体 的 には、 組 織 等 にお
いて 一 定 のポリシーに 基 づいて 端 末 管 理 を 行 っている 場 合 、 管 理 システムなどから 各 端 末 にルー
ト CA 証 明 書 を 自 動 更 新 (インストールおよび 削 除 )する 仕 組 みを 提 供 するなどである。 一 例 と
して Windows クライアントに 対 して Active Directory から 自 動 更 新 する 場 合 の 構 成 例 を Appendix
D.2 に 示 す。
このような 仕 組 みを 用 いて 各 端 末 にインストールされたルート CA 証 明 書 の 安 全 性 に 問 題 が 生
じた 場 合 には、 当 該 組 織 の 責 任 において、 当 該 ルート CA 証 明 書 を 速 やかに 自 動 削 除 するなどの
無 効 化 する 措 置 を 講 じなければならない。
5.4.3 サーバ 証 明 書 で 利 用 すべき 鍵 長
署 名 の 安 全 性 は 鍵 長 にも 大 きく 影 響 される。 通 常 、 同 じアルゴリズムであれば、 鍵 長 が 長 いほ
SSL/TLS 暗 号 設 定 ガイドライン - 28

ど 安 全 性 を 高 くすることができる。ただし、あまりにも 長 くしすぎると 処 理 時 間 が 過 大 にかかる
ようになり、 実 用 性 を 損 なうことにもつながる。
CRYPTREC では、 素 因 数 分 解 問 題 の 困 難 性 に 関 する 調 査 研 究 に 基 づいて RSA の 安 全 性 に 関 す
る 見 積 りを 作 成 している。これによれば、RSA 2048 ビットを 素 因 数 分 解 するのにおおむね 10 25
~10 27 FLOPS 程 度 の 計 算 量 が 必 要 との 見 積 もりを 出 しており、 劇 的 な 素 因 数 分 解 手 法 の 発 見 がな
い 限 り、 計 算 機 性 能 の 向 上 を 考 慮 しても 世 界 最 速 の 計 算 機 が 1 年 かけて 解 読 可 能 となるのは 2035
年 以 降 と 予 想 している。また、 楕 円 曲 線 上 の 離 散 対 数 問 題 の 困 難 性 に 関 する 調 査 研 究 も 行 われて
おり、ECDSA 192 ビットを 解 くのにおおむね 10 24 ~10 25 FLOPS 程 度 の 計 算 量 が 必 要 と 見 積 もって
いる。 詳 細 については、CRYPTREC Report 2013 19 図 3.1、 図 3.2 を 参 照 されたい。
以 上 の 報 告 と、 内 閣 官 房 情 報 セキュリティセンター( 現 : 内 閣 サイバーセキュリティセンター)
が 公 表 している「 政 府 機 関 の 情 報 システムにおいて 使 用 されている 暗 号 アルゴリズム SHA-1 及 び
RSA1024 に 係 る 移 行 指 針 20 」を 踏 まえれば、 本 ガイドライン 公 開 時 点 (2015 年 5 月 )でサーバ 証
明 書 が 利 用 すべき 鍵 長 は、RSA は 2048 ビット 以 上 、ECDSA は 256 ビット 以 上 が 妥 当 である。
5.4.4 サーバ 証 明 書 を 発 行 ・ 更 新 する 際 に 新 しい 鍵 情 報 を 生 成 する 重 要 性
サーバ 証 明 書 を 取 得 する 際 に、 公 開 鍵 と 秘 密 鍵 の 鍵 ペアの 生 成 ・ 運 用 ・ 管 理 が 正 しく 行 われな
いと、 暗 号 化 された 通 信 データが 第 三 者 に 復 号 されてしまうなどの 問 題 が 発 生 するリスクがある。
例 えば、とりわけ 危 険 なのは、サーバ 機 器 の 出 荷 時 に 設 定 されているデフォルト 鍵 や、デフォル
ト 設 定 のまま 生 成 した 鍵 ペアを 利 用 した 場 合 、 意 図 せず 第 三 者 と 同 じ 秘 密 鍵 を 共 有 してしまう 恐
れがある。
また、 何 らかの 理 由 により 秘 密 鍵 が 漏 えいした 恐 れがあり、サーバ 証 明 書 を 再 発 行 する 必 要 性
に 迫 られた 時 に、 前 回 使 用 した CSR(Certificate Signing Request:サーバ 証 明 書 を 発 行 するための
署 名 要 求 )を 使 い 回 すと、 同 じ 公 開 鍵 と 秘 密 鍵 の 鍵 ペアのまま 新 しいサーバ 証 明 書 が 作 られるの
で、 古 いサーバ 証 明 書 を 失 効 させ、 新 しいサーバ 証 明 書 を 再 発 行 することの 意 味 がなくなる。
こうしたリスクを 防 ぐためには、サーバ 管 理 者 は、サーバ 証 明 書 を 取 得 ・ 更 新 する 際 に 既 存 の
鍵 ペアを 使 い 回 すことを 厳 に 慎 み、 毎 回 新 しく 生 成 した 鍵 ペアを 使 った CSR でサーバ 証 明 書 を 取
得 ・ 更 新 しなければならない。
19 http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf
20 http://www.nisc.go.jp/active/general/pdf/angou_ikoushishin.pdf
SSL/TLS 暗 号 設 定 ガイドライン - 29

【コラム2】 実 際 にあった! 漏 えいしたかもしれない 鍵 ペアを
再 利 用 したた 証 明 書 の 再 発 行
2014 年 4 月 、OpenSSL Heartbleed と 呼 ばれる 脆 弱 性 が 大 きく
報 道 された。これは、
、サーバ
の 動 静 を 簡 易 に 確 認 するための
TLS1.2 の 拡 張 機 能 Heartbeat を実 装 した OpenSSL の 脆 弱 性 を
利 用 した
攻 撃 である。 具 体 的 には、Open
nSSL の Heartbeat 実 装 においてメモリサイズのチェ
ックをしなかったため、 当 該 OpenSSL で 構 築 した SSL/TLS サーバでは、
返 信 すべきデータ
に 隣 接 するメモリ 領 域 のデー タまでも 返 信 してしまうという 脆 弱 性 を 利 用 している。
この 脆 弱 性 が 大 きな 問 題 となったのは、 仮 に 攻 撃 が 行 われたとしてもサーバ 側 に 攻 撃 の 痕
跡 が 残 っていないため、いつ攻 撃 されたかを 特 定 すること 自 体 ができなかったことに 加 え、
漏 えいしたデータは
攻 撃 時 にメモリ 上 に展 開 されていたデータの 一 部 であったことから、ど
のデータが 漏 えいしたのかを 特 定 することが 事 実 上 できなかっ ったことである。
このため、SSL/TLS サーバ 運 用 上 の 最 悪 ケースとして「サー
ーバの 秘 密 鍵 自 体 が 漏 えいした
可 能 性 が 否 定 できない」とし、
対 策 として OpenSSL
のバージョンアップを 行 うとともに、
対 策 1. 運 用 中 のサーバ 証 明 書 を 失 効 させ、
対 策 2. 新 しい 秘 密 鍵 を 用 いて、
対 策 3. 新 しいサーバ 証 明 書 を 再 取 得 ・ 再 設 定 する、
ようにとのアナウンスが 出 された。ところが、 実 際 には、このアナウンスの 趣 旨 がサーバ 運
用 者 には
正 しく 伝 わらなかった
可 能 性 が大 きい。
例 えば、 英 Netcraft 社 の 調 査 結 果 21 によれば、Heartbleed の 公 表 後 1 か 月 間 で 43%のサーバ
証 明 書 が 再 設 定 ( 対 策 3)されたが、3 つの 対 策 全 てを 実 施 した( 図 3 中 の A の 部 分 )のは
14%にすぎなかった。 一 方 、 運 用 中 のサー ーバ 証 明 書 を 失 効 ( 対 策 1)させたにも 関 わらず、
漏 えいした 可 能 性 がある 同 じ 秘 密 鍵 のまま( 対 策 2 を 実 施 しなかった)でサーバ 証 明 書 を 再
設 定 ( 対 策 3)したケース( 図 3 中 の B の 部 分 )が
全 体 の 5% %もあったという。
図 3 英 Netcraft 社 の 調 査 結 果 より
21
http://news.netcraft.com/archives/2014/05/09/keys-left-unchanged-in-many-heartbleed-replacement-certif
icates.html
SSL/TLS 暗 号 設 定 ガイドライン - 30

6. 暗 号 スイートの 設 定
暗 号 スイートは「 鍵 交 換 _ 署 名 _ 暗 号 化 _ハッシュ 関 数 」の 組 によって 構 成 される。
例 えば、「TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384」であれば、 鍵 交 換 には「DHE」、
署 名 には「RSA」、 暗 号 化 には「 鍵 長 256 ビット GCM モードの Camellia(CAMELLIA_256_GCM)」、
ハッシュ 関 数 には「SHA-384」が 使 われることを 意 味 する。「TLS_RSA_WITH_AES_128_CBC_SHA」
であれば、 鍵 交 換 と 署 名 には「RSA」、 暗 号 化 には「 鍵 長 128 ビット CBC モードの AES
(AES_128_CBC)」、ハッシュ 関 数 には「SHA-1」が 使 われることを 意 味 する。
実 際 の SSL/TLS 通 信 においては、サーバとクライアント 間 での 暗 号 化 通 信 前 の 事 前 通 信 (ハン
ドシェイク) 時 に、 両 者 の 合 意 により 一 つの 暗 号 スイートを 選 択 する。 暗 号 スイートが 選 択 され
た 後 は、 選 択 された 暗 号 スイートに 記 載 の 鍵 交 換 、 署 名 、 暗 号 化 、ハッシュ 関 数 の 方 式 により
SSL/TLS における 各 種 処 理 が 行 われる。つまり、SSL/TLS における 安 全 性 にとって、 暗 号 スイー
トをどのように 設 定 するかが 最 も 重 要 なファクタであることを 意 味 する。
6.1 節 に 暗 号 スイートについての 要 求 設 定 をまとめる。6.2 節 から 6.4 節 では 暗 号 スイートの 設
定 を 決 めるうえでの 重 要 な 検 討 項 目 の 概 要 を 記 す。
6.1 暗 号 スイートについての 要 求 設 定
一 般 に、 暗 号 スイートの 優 先 順 位 の 上 位 から 順 にサーバとクライアントの 両 者 が 合 意 できる 暗
号 スイートを 見 つけていく。このため、 暗 号 スイートの 選 択 のみならず、 優 先 順 位 の 設 定 が 重 要
となる。
その 際 、 多 くのブラウザ(クライアント)との 相 互 接 続 性 を 確 保 するためには、 多 くの 製 品 に
共 通 して 実 装 されている 暗 号 スイートを 設 定 することが 不 可 欠 である 点 に 注 意 する 必 要 がある。
一 方 、 高 い 安 全 性 を 実 現 するためには、 比 較 的 新 しい 製 品 でしか 実 装 されていないが、 高 い 安 全
性 を 持 つ 暗 号 アルゴリズムで 構 成 される 暗 号 スイートを 設 定 する 必 要 がある。
上 記 の 点 と 6.2 節 ~6.4 節 での 内 容 を 踏 まえ、 本 ガイドラインでは、 暗 号 スイートについての 要
求 設 定 を 以 下 のように 定 める。なお、 本 節 では、 要 求 設 定 の 概 要 についてのみ 記 載 する。 詳 細 な
要 求 設 定 については、 各 々の 該 当 節 を 参 照 すること。
【 高 セキュリティ 型 の 要 求 設 定 】
高 セキュリティ 型 の 要 求 設 定 の 概 要 は 以 下 の 通 り。 詳 細 な 要 求 設 定 は 6.5.1 節 を 参 照 のこと。
• 以 下 の 条 件 を 満 たす 暗 号 スイートを 選 定 する。
‣ CRYPTREC 暗 号 リストに 掲 載 されているアルゴリズムのみで 構 成 される。
‣ 暗 号 化 として 128 ビット 安 全 性 以 上 を 有 する。
‣ 安 全 性 向 上 への 寄 与 が 高 いと 期 待 されることから、 認 証 付 暗 号 利 用 モードを 採 用 する。
‣ Perfect Forward Secrecy( 後 述 )の 特 性 を 満 たす。
SSL/TLS 暗 号 設 定 ガイドライン - 31

‣ ただし、 本 ガイドラインではサーバ 証 明 書 で DSA を 利 用 しないことを 要 求 設 定 の 前 提
としている(5.1 節 参 照 )ため、DSA を 含 む 暗 号 スイートは 選 定 しない。
• 暗 号 スイートの 優 先 順 位 は 以 下 の 通 りとする。
‣ 選 定 した 暗 号 スイートをグループαとグループβに 分 類 し、 安 全 性 の 高 いグループを 優
先 する。グループ 分 けの 基 準 はブロック 暗 号 の 鍵 長 によるものとする。
• 上 記 以 外 の 暗 号 スイートは 利 用 除 外 とする。
• 鍵 交 換 で DHE を 利 用 する 場 合 には 鍵 長 2048 ビット 以 上 、ECDHE を 利 用 する 場 合 には 鍵 長
256 ビット 以 上 の 設 定 を 必 須 とする。
【 推 奨 セキュリティ 型 の 要 求 設 定 】
推 奨 セキュリティ 型 の 要 求 設 定 の 概 要 は 以 下 の 通 り。 詳 細 な 要 求 設 定 は 6.5.2 節 を 参 照 のこと。
• 以 下 の 条 件 を 満 たす 暗 号 スイートを 選 定 する。
‣ CRYPTREC 暗 号 リストに 掲 載 されているアルゴリズムのみで 構 成 される。
‣ 暗 号 化 として 128 ビット 安 全 性 以 上 を 有 する。
‣ ただし、 本 ガイドラインではサーバ 証 明 書 で DSA を 利 用 しないことを 要 求 設 定 の 前 提
としている(5.1 節 参 照 )ため、DSA を 含 む 暗 号 スイートは 選 定 しない。
• 暗 号 スイートの 優 先 順 位 は 以 下 の 通 りとする。
‣ 選 定 した 暗 号 スイートを、 安 全 性 と 実 用 性 とのバランスの 観 点 に 立 って、グループ A、
グループ B、・・・、グループ F とグループ 分 けをする。
‣ 以 下 の 条 件 でグループごとの 優 先 順 位 を 付 ける。
本 ガイドライン 公 開 時 点 (2015 年 5 月 )では、 通 常 の 利 用 形 態 において、128 ビッ
ト 安 全 性 があれば 十 分 な 安 全 性 を 確 保 できることから 128 ビット 安 全 性 を 優 先 す
る。
鍵 交 換 に 関 しては、Perfect Forward Secrecy の 特 性 の 有 無 と 実 装 状 況 に 鑑 み、DHE、
次 いで RSA の 順 番 での 優 先 順 位 とする。
• 上 記 以 外 の 暗 号 スイートは 利 用 除 外 とする。
• 鍵 交 換 で DHE を 利 用 する 場 合 には 鍵 長 1024 ビット 以 上 22 、ECDHE/ECDH を 利 用 する 場 合
には 鍵 長 256 ビット 以 上 、RSA を 利 用 する 場 合 には 鍵 長 2048 ビット 以 上 の 設 定 を 必 須 と
する。
【セキュリティ 例 外 型 の 要 求 設 定 】
セキュリティ 例 外 型 の 要 求 設 定 の 概 要 は 以 下 の 通 り。 詳 細 な 要 求 設 定 は 6.5.3 節 を 参 照 のこと。
• 以 下 の 条 件 を 満 たす 暗 号 スイートを 選 定 する。
22 1 暗 号 解 読 以 外 の 様 々な 秘 密 鍵 の 漏 えいリスクを 考 えれば PFS の 特 性 を 優 先 させるほうが 望
ましい、26.3.3 節 に 示 すように DHE を 利 用 する 場 合 、 多 くの 場 合 で 1024 ビットが 選 択 される 環
境 である、2DHE であれば 秘 密 鍵 漏 えいの 影 響 が 当 該 セッション 通 信 のみに 限 定 される、ことを
踏 まえ、 本 ガイドラインの 発 行 時 点 での DHE の 推 奨 鍵 長 は 1024 ビット 以 上 とする
SSL/TLS 暗 号 設 定 ガイドライン - 32

‣ CRYPTREC 暗 号 リストに 掲 載 されているアルゴリズムのみで 構 成 される。
‣ ただし、 今 までほとんど 使 われていない 楕 円 曲 線 暗 号 と Triple DES や RC4 の 組 合 せを
今 後 使 っていく 積 極 的 な 理 由 は 見 いだせないことから、 楕 円 曲 線 暗 号 と Triple DES、RC4
の 組 み 合 わせは 選 定 しない。
‣ また、 本 ガイドラインではサーバ 証 明 書 で DSA を 利 用 しないことを 要 求 設 定 の 前 提 と
している(5.1 節 参 照 )ため、DSA を 含 む 暗 号 スイートも 選 定 しない。
• 暗 号 スイートの 優 先 順 位 は 以 下 の 通 りとする。
‣ 選 定 した 暗 号 スイートを、 安 全 性 と 実 用 性 とのバランスの 観 点 に 立 って、グループ A、
グループ B、・・・とグループ 分 けをする。なお、グループ A からグループ F までは 推
奨 セキュリティ 型 と 同 様 であり、 推 奨 セキュリティ 型 での 優 先 順 位 のつけ 方 を 適 用 する。
• 上 記 以 外 の 暗 号 スイートは 利 用 除 外 とする。
• 鍵 交 換 で DHE を 利 用 する 場 合 には 鍵 長 1024 ビット 以 上 、ECDHE/ECDH を 利 用 する 場 合 に
は 鍵 長 256 ビット 以 上 、RSA を 利 用 する 場 合 には 鍵 長 2048 ビット 以 上 の 設 定 を 必 須 とす
る。
6.2 暗 号 スイートで 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム
本 ガイドラインにおいて「 暗 号 スイートで 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム」とは、
SSL/TLS 用 の 暗 号 スイートとして IETF で 規 格 化 されたものに 採 用 されている 暗 号 アルゴリズム
のうち、CRYPTREC 暗 号 リスト(2.2.1 節 参 照 )にも 掲 載 されているものとする。 具 体 的 には、
表 9に 示 した 暗 号 アルゴリズムである。
表 9 暗 号 スイートで 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム
暗 号 スイー
CRYPTREC 暗 号 リストでの 標 記
トでの 標 記 技 術 分 類 リストの 種 類 アルゴリズム 名
鍵 交 換 鍵 共 有 ・ 守 秘 電 子 政 府 推 奨 暗 号
リスト
DH(Ephemeral DH を 含 む)
ECDH(Ephemeral DH を 含 む)
運 用 監 視 暗 号 リスト RSAES PKCS#1 v1.5(RSA)
署 名 署 名 電 子 政 府 推 奨 暗 号
リスト
RSASSA PKCS#1 v1.5(RSA)
DSA
ECDSA
暗 号 化 128 ビット
ブロック 暗 号
電 子 政 府 推 奨 暗 号
リスト
AES( 鍵 長 128 ビット、256 ビット)
Camellia( 鍵 長 128 ビット、256 ビット)
暗 号 利 用 モード 電 子 政 府 推 奨 暗 号
リスト
CBC
GCM
ハッシュ
関 数
ハッシュ 関 数 電 子 政 府 推 奨 暗 号
リスト
SHA-256
SHA-384
運 用 監 視 暗 号 リスト SHA-1
SSL/TLS 暗 号 設 定 ガイドライン - 33

暗 号 スイートで 利 用 可 能 な 候 補 となる 暗 号 アルゴリズム( 続 )
以 下 は SSL3.0 でのみ 利 用 可
暗 号 化 64 ビット 電 子 政 府 推 奨 暗 号 3-key Triple DES
ブロック 暗 号 リスト
ストリーム 暗 号 運 用 監 視 暗 号 リスト 128-bit RC4
なお、Triple DES は 電 子 政 府 推 奨 暗 号 リストに、RC4 は 運 用 監 視 暗 号 リストに 掲 載 されている
が、 以 下 の 理 由 を 総 合 的 に 検 討 した 結 果 、 本 ガイドラインでは TLS1.0 以 上 の 場 合 には Triple DES
と RC4 を 採 用 しないことに 決 定 した。
【TLS1.0 以 上 の 場 合 での Triple DES の 除 外 理 由 】
• TLS1.0 以 上 の 場 合 には、Triple DES よりも 安 全 でかつ 高 速 な 共 通 鍵 暗 号 として AES や
Camellia が 利 用 可 能 である。
【TLS1.0 以 上 の 場 合 での RC4 の 除 外 理 由 】
• TLS1.0 以 上 の 場 合 には、RC4 よりもはるかに 安 全 な 共 通 鍵 暗 号 として AES や Camellia が
利 用 可 能 である。
• ネットワーク 環 境 等 の 利 用 状 況 も 踏 まえて 総 合 的 に 判 断 すれば、RC4 の 安 全 性 の 脆 弱 性 を
大 きく 優 越 するほどの 実 利 用 における 速 度 優 位 性 が 認 められない。このことは、RC4 の 処
理 速 度 が 速 いという 理 由 が、 他 の 安 全 な 暗 号 アルゴリズムを 使 わない 理 由 にはならないこ
とを 意 味 する。
• NIST 23 や ENISA 24 などが 最 近 発 行 している SSL/TLS での 設 定 ガイドラインにおいても、RC4
は 除 外 されている。
6.3 鍵 交 換 で 考 慮 すべきこと
SSL/TLS の 仕 様 では、 実 際 のデータを 暗 号 化 する 際 に 利 用 する“セッション 鍵 ”はセッション
ごとに(あるいは 任 意 の 要 求 時 点 で) 更 新 される。したがって、 何 らかの 理 由 により、ある 時 点
でのセッション 鍵 が 漏 えいした 場 合 でも、 当 該 セッション 以 外 のデータは 依 然 として 保 護 された
状 態 にある。
一 方 、セッション 鍵 は 暗 号 通 信 を 始 める 前 にサーバとクライアントとで 共 有 しておく 必 要 があ
るため、 事 前 通 信 (ハンドシェイク)の 段 階 でセッション 鍵 を 共 有 するための 処 理 が 行 われる。
この 処 理 のために 使 われるのが、 表 9での「 鍵 共 有 ・ 守 秘 」に 掲 載 されている 暗 号 アルゴリズム
である。
23 NIST SP800-52 revision 1 (draft), Guidelines for the Selection, Configuration, and Use of Transport
Layer Security (TLS) Implementations
24 ENISA, “Algorithms, Key Sizes and Parameters Report - 2013 recommendations,”
SSL/TLS 暗 号 設 定 ガイドライン - 34

6.3.1 秘 密 鍵 漏 えい 時 の 影 響 範 囲 を 狭 める 手 法 の 採 用 (Perfect Forward Secrecy の 重
要 性 )
秘 密 鍵 が 漏 えいする 原 因 は 暗 号 アルゴリズムの 解 読 によるものばかりではない。むしろ、プロ
グラムなどの 実 装 ミスや 秘 密 鍵 の 運 用 ・ 管 理 ミス、あるいはサイバー 攻 撃 やウイルス 感 染 による
ものなど、 暗 号 アルゴリズムの 解 読 以 外 が 原 因 となって 秘 密 鍵 が 漏 えいする 場 合 のほうが 圧 倒 的
に 多 い。
最 近 でも、OpenSSL Heartbleed Bug や Dual_EC_DRGB の 脆 弱 性 などが 原 因 による 秘 密 鍵 の 漏 え
いが 懸 念 されており、“ 秘 密 鍵 が 漏 えいする”リスクそのものは 決 して 無 視 できるものではない。
スノーデン 事 件 でも 話 題 になったように、 秘 密 鍵 の 運 用 ・ 管 理 そのものに 問 題 がある 場 合 も 想 定
される。
上 述 した 通 り、SSL/TLS では、 毎 回 変 わるセッション 鍵 をサーバとクライアントが 共 有 するこ
とでセッションごとに 違 った 秘 密 鍵 を 使 って 暗 号 通 信 をしており、 仮 にある 時 点 でのセッション
鍵 が 漏 えいした 場 合 でも 当 該 セッション 以 外 のデータは 依 然 として 保 護 されている。
しかし、 多 くの 場 合 、セッション 鍵 の 交 換 には 固 定 の 鍵 情 報 を 使 って 行 っている。このため、
どんな 理 由 であれ、もし 仮 に 鍵 交 換 で 使 う 暗 号 アルゴリズムの“ 秘 密 鍵 ”が 漏 えいした 場 合 、 当
該 秘 密 鍵 で 復 号 できるセッション 鍵 はすべて 漏 えいしたことと 同 義 となる。つまり、SSL/TLS で
の 通 信 データをためておき、 年 月 が 経 って、 当 時 の 鍵 交 換 で 使 った 暗 号 アルゴリズムの“ 秘 密 鍵 ”
が 入 手 できたならば、 過 去 にさかのぼって、ためておいた 通 信 データの 中 身 が 読 み 出 せることを
意 味 している。
そこで、 過 去 の SSL/TLS での 通 信 データの 秘 匿 を 確 保 する 観 点 から、 鍵 交 換 で 使 った 暗 号 アル
ゴリズムの“ 秘 密 鍵 ”に 毎 回 異 なる 乱 数 を 付 加 することにより、 見 かけ 上 、 毎 回 異 なる 秘 密 鍵 を
使 ってセッション 鍵 の 共 有 を 行 うようにする 方 法 がある。これによって、 仮 に 鍵 交 換 で 使 う 暗 号
アルゴリズムの“ 秘 密 鍵 ”が 何 らかの 理 由 で 漏 えいしたとしても、 当 該 セッション 鍵 の 共 有 のた
めに 利 用 した 乱 数 がわからなければ、 当 該 セッション 鍵 そのものは 求 められず、 過 去 に 遡 及 して
通 信 データの 中 身 が 読 まれる 危 険 性 を 回 避 することができる。
このような 性 質 のことを、Perfect Forward Secrecy、または 単 に Forward secrecy と 呼 んでいる。
なお、 本 ガイドラインでは Perfect Forward Secrecy(あるいは PFS)に 統 一 して 呼 ぶこととする。
現 在 の SSL/TLS で 使 う 暗 号 スイートの 中 で、Perfect Forward Secrecy の 特 性 を 持 つのは
Ephemeral DH と Ephemeral ECDH と 呼 ばれる 方 式 であり、それぞれ DHE、ECDHE と 表 記 される。
6.3.2 鍵 交 換 で 利 用 すべき 鍵 長
5.4.3 節 で 述 べたことと 同 様 、 鍵 交 換 においても、 鍵 長 を 長 くすれば 処 理 時 間 や 消 費 リソースな
ども 増 えるため、 安 全 性 と 処 理 性 能 、 消 費 リソースなどのトレードオフを 考 えて 適 切 な 鍵 長 を 選
択 する 必 要 がある。
例 えば、 処 理 性 能 や 消 費 リソースの 制 約 が 厳 しい 組 込 み 機 器 などの 場 合 、 鍵 長 4096 ビットの
RSA 暗 号 を 利 用 して 得 られるメリットよりもデメリットの 方 が 大 きくなる 可 能 性 がある。
CRYPTREC の 見 積 もりでは、 劇 的 な 素 因 数 分 解 手 法 の 発 見 がない 限 り、 計 算 機 性 能 の 向 上 を 考 慮
しても 世 界 最 速 の 計 算 機 が 1 年 かけて 鍵 長 2048 ビットの RSA を 解 読 可 能 となるのは 2035 年 以 降
SSL/TLS 暗 号 設 定 ガイドライン - 35

と 予 想 している。また、NIST SP800-57 では 鍵 長 2048 ビットは 2030 年 までは 利 用 可 とされてい
る(2.2.2 節 表 3 参 照 )。したがって、2030 年 を 超 えて 利 用 することを 想 定 していないシステム
やサービスであれば、2048 ビット 以 上 の 鍵 長 を 使 うメリットは 乏 しいといえる。
内 閣 官 房 情 報 セキュリティセンター( 現 : 内 閣 サイバーセキュリティセンター)が 公 表 してい
る「 政 府 機 関 の 情 報 システムにおいて 使 用 されている 暗 号 アルゴリズム SHA-1 及 び RSA1024 に
係 る 移 行 指 針 」、 並 びに CRYPTREC が 公 開 している 公 開 鍵 暗 号 についての 安 全 性 予 測 を 踏 まえれ
ば、 本 ガイドライン 公 開 時 点 (2015 年 5 月 )での 鍵 交 換 で 利 用 すべき 鍵 長 は、RSA は 2048 ビッ
ト 以 上 、ECDH/ECDHE は 256 ビット 以 上 が 妥 当 である。なお、RSA に 関 しては、サーバ 証 明 書
の 申 請 段 階 で 鍵 長 2048 ビット 以 上 を 設 定 することで 実 現 する。
6.3.3 DHE/ECDHE での 鍵 長 の 設 定 状 況 についての 注 意
鍵 交 換 について、 暗 号 スイート 上 は 鍵 長 の 規 定 がない。このため、 同 じ 暗 号 スイートを 使 って
いても、 利 用 可 能 な 鍵 長 は 製 品 依 存 になっていることに 注 意 する 必 要 がある。 特 に、 鍵 交 換 で RSA
を 使 う 場 合 と、DHE や ECDHE/ECDH を 使 う 場 合 とでは、 鍵 長 の 扱 いが 全 く 異 なるので、それぞ
れについて 適 切 な 設 定 を 行 っておく 必 要 がある。
RSA での 鍵 交 換 を 行 う 場 合 にはサーバ 証 明 書 に 記 載 された 公 開 鍵 を 使 うことになっており、 本
ガイドラインの 発 行 時 点 では 鍵 長 2048 ビットの 公 開 鍵 がサーバ 証 明 書 に 通 常 記 載 されている。こ
のことは、RSA での 鍵 交 換 を 行 う 場 合 、サーバ 証 明 書 を 正 当 に 受 理 する 限 り、どのサーバもブラ
ウザも 当 該 サーバ 証 明 書 によって 利 用 する 鍵 長 が 2048 ビットにコントロールされていることを
意 味 する。 例 え 鍵 長 2048 ビットの RSA が 使 えないブラウザがあったとしても、 鍵 交 換 が 不 成 立 ・
通 信 エラーになるだけであり、2048 ビット 以 外 の 鍵 長 が 使 われることはない。
つまり、RSA での 鍵 交 換 に 関 しては、サーバ 証 明 書 の 発 行 時 に 利 用 する 鍵 長 を 正 しく 決 め、そ
の 鍵 長 に 基 づくサーバ 証 明 書 を 発 行 してもらえばよく、ほとんどの 場 合 、サーバやブラウザ 等 に
特 別 な 設 定 をする 必 要 はない。
一 方 、DHE、ECDH/ECDHE については、 利 用 する 鍵 長 がサーバ 証 明 書 で 明 示 的 にコントロー
ルされるのではなく、 個 々のサーバやブラウザでの 鍵 パラメータの 設 定 によって 決 められる。こ
のため、どの 鍵 長 が 利 用 されるかは、 使 用 する 製 品 での 鍵 パラメータの 設 定 状 況 に 大 きく 依 存 す
る。 例 えば、デフォルトで 使 用 する 鍵 長 が 製 品 やバージョンによって 異 なることが 知 られており、
2013 年 夏 頃 までは 鍵 長 1024 ビットの DHE しか 使 えない 製 品 やバージョンも 少 なくなかった。 有
名 なところでは、Apache 2.4.6 以 前 、Java 7(JDK7) 以 前 、Windows Server 2012 などがある。
図 4の 2015 年 1 月 の Alexa の 調 査 結 果 25 によれば、 約 47 万 の 主 要 なサイトについて、DHE が
利 用 できるのは 約 52.3%であり、そのうちの 約 87.5%( 全 体 では 約 45.8%)が 鍵 長 1024 ビットを
採 用 している。 一 方 、ECDHE が 利 用 できるのは 約 62.7%であり、そのうちの 約 98%( 全 体 では 約
61.5%)が 鍵 長 256 ビットを 採 用 している。
このことは、DHE を 利 用 した 場 合 は 鍵 長 1024 ビットが、ECDHE を 利 用 した 場 合 は 鍵 長 256 ビ
ットが 採 用 される 可 能 性 が 極 めて 高 いことを 意 味 している。
25 https://securitypitfalls.wordpress.com/2015/02/01/january-2015-scan-results/
SSL/TLS 暗 号 設 定 ガイドライン - 36

DHE で 鍵 長 2048 ビットとして
使 う 場 合 には、 鍵 長 2048 ビットをサポートしているバージョン
を 使 ったうえで、デフォルトで 使 用 可 となっているか、もしくは
使 用 可 のオプション 設 定 を 行 う
ことが 必 要 である。
【 明 示 的 に 鍵 長 2048 ビットを
指 定 できる
代 表 例 】
• OpenSSL
• Apache 2.4.7 以 降
• lighttpd 1.4.29 以 降
• nginx
• Javaa 8 以 降
これらについては Appendix B.3 に 実 際 の 設 定 例 を 記 す。
【 明 示 的 に 鍵 長 を 指 定 できるが、
鍵 長 20488 ビットをサポートしていない 代 表 例 】
• Apache 2.4.6 以 前
• Javaa 7 以 前
例 えば、 Java 7 以 前 では DHE で 扱 える 鍵 長 は 64 ビット 刻 みで 512 ビットから 1024 ビットまで
である。これらの 製 品 を 利 用 する 場 合 には、 必 ず 鍵 長 を 1024 ビットに 指 定 して 利 用 すること。
図 4
DHE/ECDHE の 鍵 長 の 設 定 状 況 (Alexa の 調 査 結 果 を 加 工 )
SSL/TLS 暗 号 設 定 ガイドライン - 37

【 明 示 的 に 鍵 長 を 指 定 できない 代 表 例 】
• Apache Tomcat
• Microsoft IIS
これらについては、DHE の 鍵 長 を 指 定 することができず、クライアント 側 からの 指 定 により
512 ビット、1024 ビット 等 の 弱 い 鍵 パラメータが 使 われる 可 能 性 がある。 例 えば、サーバ 側 の 設
定 が 鍵 長 2048 ビット 対 応 可 能 だったとしても、 本 ガイドライン 公 開 時 点 (2015 年 5 月 )では、ブ
ラウザ(クライアント) 側 が 鍵 長 2048 ビットに 対 応 していない 可 能 性 が 十 分 に 考 えられる。その
場 合 には、サーバ 側 は 鍵 長 1024 ビットを 自 動 的 に 選 択 することに 注 意 を 要 する。
この 点 は、RSA で 鍵 交 換 を 行 う 場 合 とは 大 きく 事 情 が 異 なるため、これらの 製 品 を 使 う 場 合 に
は、DHE を 含 む 暗 号 スイートは 選 択 せず、ECDHE または RSA を 含 む 暗 号 スイートを 使 うように
設 定 すべきである。
6.4 暗 号 スイートについての 実 装 状 況
SSL/TLS 用 の 暗 号 スイートは IETF で 規 格 化 されており、 任 意 に 暗 号 アルゴリズムを 選 択 して
「 鍵 交 換 _ 署 名 _ 暗 号 化 _ハッシュ 関 数 」の 組 を 自 由 に 作 れるわけではない。また、IETF で 規 格
化 されている 暗 号 スイートだけでも 数 多 くあるため、 実 際 の 製 品 には 実 装 されていない 暗 号 スイ
ートも 多 い。
多 くの 製 品 に 共 通 して 実 装 されている 暗 号 スイートを 設 定 すれば、 相 互 接 続 性 を 広 く 担 保 でき
る 可 能 性 が 高 まる。 一 方 、 特 定 の 製 品 のみに 実 装 されている 暗 号 スイートだけを 設 定 すれば、 意
図 的 に 当 該 製 品 間 での 接 続 に 限 定 することができる。
6.5 暗 号 スイートについての 詳 細 な 要 求 設 定
本 節 では、6.1 節 での 要 求 設 定 の 概 要 に 基 づき、 各 々の 詳 細 な 要 求 設 定 を 以 下 に 示 す。
なお、 鍵 交 換 に PSK または KRB が 含 まれる 暗 号 スイートは、サーバとクライアントの 両 方 で
特 別 な 設 定 をしなければ 利 用 することができないため、 本 ガイドラインの 対 象 外 とする。
また、 非 技 術 的 要 因 として、ECDH や ECDSA を 採 用 する 際 にはパテントリスクの 存 在 が 広 く
指 摘 されているので、 十 分 な 検 討 のうえで 採 用 の 可 否 を 決 めることが 望 ましい。
6.5.1 高 セキュリティ 型 での 暗 号 スイートの 詳 細 要 求 設 定
6.1 節 の 条 件 を 踏 まえて、 表 10 の 通 り、 選 定 した 暗 号 スイートをグループαとグループβに 分
類 する。グループ 分 けの 基 準 はブロック 暗 号 の 鍵 長 によるものとし、 安 全 性 の 高 いグループをグ
ループαに 割 り 当 て、 優 先 して 設 定 する。
なお、グループ 内 での 暗 号 スイートから 全 部 または 一 部 を 選 択 して 設 定 するが、その 際 の 優 先
順 位 は 任 意 に 定 めてよい。また、グループβの 暗 号 スイートについては 選 択 しなくてもよい。
SSL/TLS 暗 号 設 定 ガイドライン - 38

「 除 外 事 項 」は 設 定 で 除 外 すべき 暗 号 スイートを 示 したものである 26 。
表 10 高 セキュリティ 型 での 暗 号 スイートの 要 求 設 定 ( 基 本 )
グループα TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x00,0x9F)
TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0, 0x7D)
グループβ TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x00,0x9E)
TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x7C)
設 定 すべき 鍵 長 鍵 交 換 で DHE を 利 用 する 場 合 には 鍵 長 2048 ビット 以 上 の 設 定 を 必 須 と
する。なお、DHE の 鍵 長 を 明 示 的 に 設 定 できない 製 品 を 利 用 する 場 合 に
は、DHE を 含 む 暗 号 スイートは 選 定 すべきではない
高 セキュリティ 型 グループα、グループβ、 表 11 以 外 のすべての 暗 号 スイートを 利 用 除
での 除 外 事 項 外 とする
パテントリスクについても 検 討 したうえで ECDH や ECDSA を 採 用 することを 決 めた 場 合 には、
表 11 の 暗 号 スイートグループを 追 加 してよい。
表 11 高 セキュリティ 型 での 暗 号 スイートの 要 求 設 定 ( 楕 円 曲 線 暗 号 の 追 加 分 )
グループαへの TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0,0x2C)
追 加 または 代 替 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC0,0x30)
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0,0x87)
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0,0x8B)
グループβへの TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2B)
追 加 または 代 替 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F)
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x86)
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x8A)
設 定 すべき 鍵 長 鍵 交 換 で ECDHE を 利 用 する 場 合 には 鍵 長 256 ビット 以 上 の 設 定 を 必 須
とする
6.5.2 推 奨 セキュリティ 型 での 暗 号 スイートの 詳 細 要 求 設 定
6.1 節 の 条 件 を 踏 まえて、 表 12 の 通 り、 選 定 した 暗 号 スイートをグループ A、グ ル ー プ B、・・・
とグループ 分 けをする。グループ 分 けの 基 準 は 安 全 性 と 実 用 性 とのバランスの 観 点 に 立 って 行 い、
優 先 設 定 する 順 番 にグループ A から 順 に 割 り 当 てる。
グループ 内 での 暗 号 スイートから 全 部 または 一 部 を 選 択 して 設 定 するが、その 際 の 優 先 順 位 は
任 意 に 定 めてよい。また、グループ C 以 降 の 暗 号 スイートについては 選 択 しなくてもよい。
(RFC 必 須 )は、TLS1.2 を 規 定 する RFC においてサポートが 必 須 と 指 定 されている 暗 号 スイ
ートであり、 不 特 定 多 数 からのアクセスを 想 定 する SSL/TLS サーバにおいては 利 用 可 に 設 定 する
26
高 セキュリティ 型 の 暗 号 スイート 設 定 では、TLS1.2 でのサポートが 必 須 と 指 定 されている 暗 号
スイート AES128-SHA を 利 用 した 通 信 が 接 続 不 可 となることに 留 意 されたい
SSL/TLS 暗 号 設 定 ガイドライン - 39

ことが 推 奨 される 暗 号 スイートである 27 。
また、「 除 外 事 項 」は 設 定 で 除 外 すべき 暗 号 スイートを 示 したものである。
表 12 推 奨 セキュリティ 型 での 暗 号 スイートの 要 求 設 定 ( 基 本 )
グループ A TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x00,0x9E)
TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x7C)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x00,0x67)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0x00,0xBE)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x00,0x33)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x00,0x45)
グループ B TLS_RSA_WITH_AES_128_GCM_SHA256 (0x00,0x9C)
TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x7A)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x00,0x3C)
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0x00,0xBA)
TLS_RSA_WITH_AES_128_CBC_SHA (0x00,0x2F) (RFC 必 須 )
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x00,0x41)
グループ C 該 当 なし
グループ D TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x00,0x9F)
TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0, 0x7D)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x00,0x6B)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0x00,0xC4)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x00,0x39)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x00,0x88)
グループ E TLS_RSA_WITH_AES_256_GCM_SHA384 (0x00,0x9D)
TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0,0x7B)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x00,0x3D)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0x00,0xC0)
TLS_RSA_WITH_AES_256_CBC_SHA (0x00,0x35)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x00,0x84)
グループ F 該 当 なし
設 定 すべき 鍵 長 鍵 交 換 で DHE を 利 用 する 場 合 には 鍵 長 1024 ビット 以 上 、RSA を 利 用
する 場 合 には 鍵 長 2048 ビット 以 上 の 設 定 を 必 須 とする。なお、DHE の
鍵 長 を 明 示 的 に 設 定 できない 製 品 を 利 用 する 場 合 には、DHE を 含 む 暗 号
スイートは 選 定 すべきではない
推 奨 セキュリティ 型 グループ A~グループ F 及 び 表 13 以 外 のすべての 暗 号 スイートを 利 用
での 除 外 事 項 除 外 とする
27 TLS1.1 及 び TLS1.0 でのサポートが 必 須 と 指 定 されている 暗 号 スイートは Triple DES を 利 用 す
るものである。しかし、 推 奨 セキュリティ 型 を 適 用 する SSL/TLS サーバが 接 続 相 手 として 対 象 と
するブラウザは、BEAST 攻 撃 等 に 対 するセキュリティパッチが 適 用 されているブラウザであるこ
とを 考 慮 すれば、AES が 利 用 可 能 であり、6.5.2 節 の 設 定 であっても 事 実 上 問 題 がないと 判 断 した
SSL/TLS 暗 号 設 定 ガイドライン - 40

パテントリスクについても 検 討 したうえで ECDH や ECDSA を 採 用 することを 決 めた 場 合 には、
表 13 の 暗 号 スイートグループを 追 加 してよい。
表 13 推 奨 セキュリティ 型 での 暗 号 スイートの 要 求 設 定 ( 楕 円 曲 線 暗 号 の 追 加 分 )
グループ A への 追 加 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2B)
または 代 替 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F)
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x86)
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x8A)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xC0,0x23)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC0,0x27)
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (0xC0,0x72)
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xC0,0x76)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xC0,0x09)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC0,0x13)
グループ C への 追 加 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2D)
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x31)
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x88)
TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xC0,0x8C)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xC0,0x25)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xC0,0x29)
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (0xC0,0x74)
TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xC0,0x78)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xC0,0x04)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xC0,0x0E)
グループ D への 追 加 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0,0x2C)
または 代 替 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC0,0x30)
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0,0x87)
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0,0x8B)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xC0,0x24)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC0,0x28)
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (0xC0,0x73)
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xC0,0x77)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xC0,0x0A)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC0,0x14)
SSL/TLS 暗 号 設 定 ガイドライン - 41

推 奨 セキュリティ 型 での 暗 号 スイートの 要 求 設 定 ( 楕 円 曲 線 暗 号 の 追 加 分 )( 続 )
グループ F への 追 加 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0,0x2E)
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xC0,0x32)
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0,0x89)
TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xC0,0x8D)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xC0,0x26)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xC0,0x2A)
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (0xC0,0x75)
TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xC0,0x79)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xC0,0x05)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xC0,0x0F)
設 定 すべき 鍵 長 鍵 交 換 で ECDHE または ECDH を 利 用 する 場 合 には 鍵 長 256 ビット 以 上
の 設 定 を 必 須 とする
6.5.3 セキュリティ 例 外 型 での 暗 号 スイートの 詳 細 要 求 設 定
6.1 節 の 条 件 を 踏 まえて、 表 14 の 通 り、 選 定 した 暗 号 スイートをグループ A、グ ル ー プ B、・・・
とグループ 分 けをする。グループ 分 けの 基 準 は 安 全 性 と 実 用 性 とのバランスの 観 点 に 立 って 行 い、
優 先 設 定 する 順 番 にグループ A から 順 に 割 り 当 てる。
グループ A からグループ F までは 推 奨 セキュリティ 型 と 同 様 であるので、6.5.2 節 を 参 照 のこ
と。セキュリティ 例 外 型 では、 推 奨 セキュリティ 型 に 加 え、グループ G とグループ H として、 以
下 の 暗 号 スイートグループを 追 加 する。グループ 内 での 暗 号 スイートから 全 部 または 一 部 を 選 択
して 設 定 するが、その 際 の 優 先 順 位 は 任 意 に 定 めてよい。
(RFC 必 須 )は、TLS1.2、TLS1.1 及 び TLS1.0 を 規 定 する RFC においてサポートが 必 須 と 指 定
されている 暗 号 スイートであり、 不 特 定 多 数 からのアクセスを 想 定 する SSL/TLS サーバにおいて
は 利 用 可 に 設 定 すべき 暗 号 スイートである。
また、「 除 外 事 項 」は 設 定 で 除 外 すべき 暗 号 スイートを 示 したものである。
表 14 セキュリティ 例 外 型 での 暗 号 スイートの 要 求 設 定 ( 基 本 )
グループ A~
推 奨 セキュリティ 型 と 同 じ (6.5.2 節 参 照 )
グループ F
グループ G TLS_RSA_WITH_RC4_128_SHA (0x00,0x05)
グループ H TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x00,0x16)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00,0x0A) (RFC 必 須 )
設 定 すべき 鍵 長 鍵 交 換 で DHE を 利 用 する 場 合 には 鍵 長 1024 ビット 以 上 、RSA を 利 用
する 場 合 には 鍵 長 2048 ビット 以 上 の 設 定 を 必 須 とする。なお、DHE の
鍵 長 を 明 示 的 に 設 定 できない 製 品 を 利 用 する 場 合 には、DHE を 含 む 暗 号
スイートは 選 定 すべきではない
セキュリティ 例 外 型 グループ A~グループ G 及 び 表 13 以 外 のすべての 暗 号 スイートを 利 用
での 除 外 事 項 除 外 とする
SSL/TLS 暗 号 設 定 ガイドライン - 42

【コラム3】 輸 出 規 制 時 代 の 名 残 -FREAK 攻 撃
FREAK 28 攻 撃 は、 中 間 者 攻 撃 に 分 類 されるなかでも 特 にダウングレード 攻 撃 と 呼 ばれる
攻 撃 手 法 の 一 種 で、SSL/TLS で 利 用 する 暗 号 スイートを「RSA を 利 用 する 輸 出 規 制 対 象 の 暗
号 スイート(RSA_EXPORT)」に 強 制 的 にダウングレードさせる 攻 撃 である。
RSA_EXPORT は、2000 年 前 後 まで 続 いていた 輸 出 規 制 に 対 応 するためのもので、あえて
暗 号 強 度 を 弱 める 処 理 を 行 う。 具 体 的 には、たとえサーバ 証 明 書 で 鍵 長 2048 ビットの RSA
を 使 って 鍵 交 換 をするように 記 載 されていても、 強 制 的 に 暗 号 強 度 を 大 きく 弱 めた 鍵 長 512
ビットの RSA を 利 用 して 鍵 交 換 をするように 制 御 する。こうすることで、 鍵 交 換 での RSA
が 解 読 できればセッション 鍵 を 取 り 出 すことができるため、 当 該 SSL/TLS 通 信 を 復 号 するこ
とが 可 能 になる。
発 見 者 によれば、 鍵 長 512 ビットの RSA は Amazon EC2 で 100 ドル 出 せば 12 時 間 以 内 に
解 読 できると 主 張 している。 実 際 、 鍵 長 768 ビットの RSA の 解 読 事 例 が 2010 年 に 発 表 され
ていることを 考 慮 すれば、 鍵 長 512 ビットの RSA が 簡 単 に 解 読 されたとしてもおかしくは
ない。
FREAK 攻 撃 が 成 功 するためには、 少 なくともサーバが RSA_EXPORT を 受 け 付 ける 設 定 に
なっている 必 要 がある。 一 方 、 本 ガイドラインの 要 求 設 定 では、「 高 セキュリティ 型 」「 推 奨
セキュリティ 型 」「セキュリティ 例 外 型 」のいずれにおいても EXPORT を 使 う 暗 号 スイート
は 利 用 除 外 とするようになっているため、RSA_EXPORT が 選 択 されることはなく、FREAK
攻 撃 はもともと 成 功 しない。
なお、 今 では RSA_EXPORT を 必 要 とする 機 会 はほとんどないことから、サーバ・ブラウ
ザともに、デフォルトでは RSA_EXPORT を 受 け 付 けないようにするためのセキュリティパ
ッチがベンダ 各 社 から 提 供 されている。
28 Factoring RSA Export Keys
SSL/TLS 暗 号 設 定 ガイドライン - 43

7. SSL/TLS を 安 全 に 使 うために 考 慮 すべきこと
プロトコルとしての 脆 弱 性 だけでなく、 実 装 上 の 脆 弱 性 が 発 見 されることも 時 おり 起 きる。
そのような 脆 弱 性 が 発 見 されると 基 本 的 にはベンダからセキュリティパッチが 提 供 されるので、
ベンダが 提 供 するセキュリティパッチを 入 手 可 能 な 状 態 とし、 常 にセキュリティパッチを 適 用 し
て 最 新 の 状 態 にしておくことが 望 ましい。
それ 以 外 にも、SSL/TLS をより 安 全 に 使 うために、 以 下 の 項 目 を 参 考 にするとよい。
7.1 サーバ 証 明 書 の 作 成 ・ 管 理 について 注 意 すべきこと
7.1.1 サーバ 証 明 書 での 脆 弱 な 鍵 ペアの 使 用 の 回 避
OpenSSL などの 暗 号 モジュールにおいて 擬 似 乱 数 生 成 機 能 のエントロピー 不 足 などの 脆 弱 性 が
存 在 する 場 合 、これを 用 いて 鍵 配 送 ・ 共 有 や 署 名 で 使 う 公 開 鍵 と 秘 密 鍵 の 鍵 ペアを 生 成 した 際 に、
結 果 的 に 解 読 容 易 な 鍵 ペアが 生 成 されてしまうリスクがある。
こうしたリスクを 防 ぐためには、サーバ 管 理 者 は、 鍵 ペアの 生 成 時 点 で 脆 弱 性 が 指 摘 されてい
ない 暗 号 モジュールを 利 用 するよう 注 意 すべきである。また、 既 知 の 解 読 可 能 な 鍵 ペアでないこ
とを 確 認 するサービスなども 提 供 されている 29 。
7.1.2 推 奨 されるサーバ 証 明 書 の 種 類
ブラウザなどをはじめとするサーバ 証 明 書 を 検 証 するアプリケーションには、 一 定 の 基 準 に 準
拠 した 認 証 局 の 証 明 書 (ルート CA 証 明 書 )があらかじめ 登 録 されており、これらの 認 証 局 (と
その 下 位 認 証 局 )はパブリック 認 証 局 と 呼 ばれている。 一 般 に、パブリック 認 証 局 が、 第 三 者 の
立 場 から 確 認 したサーバの 運 営 組 織 等 の 情 報 を 記 載 したサーバ 証 明 書 を 発 行 し、ブラウザに 予 め
搭 載 されたルート CA 証 明 書 と 組 合 せて 検 証 を 行 うことで、サーバ 証 明 書 の 信 頼 性 を 確 保 する。
これにより、 当 該 サーバ 証 明 書 の 正 当 性 が 確 認 できれば、ブラウザは 警 告 表 示 することなく、 当
該 サーバへの 接 続 を 行 う。
パブリック 認 証 局 から 発 行 されるサーバ 証 明 書 は、その 用 途 や 利 用 範 囲 に 応 じて 表 15 に 示 す 3
種 類 に 分 類 される。これらのサーバ 証 明 書 のうち、 不 特 定 多 数 の 利 用 者 がアクセスする 一 般 的 な
Web サーバ 用 途 であれば、 運 営 サイトの 法 的 実 在 性 の 確 認 やグリーンバーによる 視 認 性 の 高 さと
いった 優 位 点 がある EV 証 明 書 が 利 用 者 にとって 一 番 安 心 できるサーバ 証 明 書 といえる。しかし、
本 ガイドライン 公 開 時 点 (2015 年 5 月 )においては、スマートフォンなど 一 部 の 機 器 においてま
だ 十 分 にグリーンバーが 機 能 しているとは 言 い 難 く、また 入 手 コストにおいて OV 証 明 書 とのギ
ャップが 大 きい、といった 課 題 もある。
そこで、 本 ガイドラインでは、 不 特 定 多 数 の 利 用 者 がアクセスする 一 般 的 なサーバ 用 途 につい
て、EV 証 明 書 の 利 用 を 推 奨 するに 留 める。
29
例 えば https://factorable.net/keycheck.html がある。ただし、 安 全 性 を 100% 証 明 するものではな
いことに 注 意 されたい
SSL/TLS 暗 号 設 定 ガイドライン - 44

サーバ 証 明 書 の 種 類
DV 証 明 書
(Domain Validation)
OV 証 明 書
(Organization Validation)
EV 証 明 書
(Extended Validation)
表 15 サーバ 証 明 書 の 種 類 と 違 い
内 容 の 違 い
サーバの 運 営 組 織 が、サーバ 証 明 書 に 記 載 されるドメインの 利 用 権 を
有 することを 確 認 したうえで 発 行 される 証 明 書 。
オンライン 申 請 による 短 時 間 発 行 や 低 コストで 入 手 できるものが 多
い、などのメリットがある。
一 方 、サーバの 運 営 組 織 の 実 在 性 や、ドメイン 名 と 運 営 組 織 の 関 係 に
ついては 確 認 されないので、 不 特 定 の 利 用 者 を 対 象 とする 一 般 的 な
Web サーバの 用 途 には 不 向 きである。
ドメイン 名 の 利 用 権 に 加 えて、サーバ 運 営 組 織 の 実 在 性 の 確 認 やドメ
イン 名 と 運 営 組 織 との 関 係 などについても 確 認 した 上 で 発 行 される 証
明 書 。
不 特 定 多 数 の 利 用 者 がアクセスするような 一 般 的 な Web サーバの 用 途
で 利 用 されるが、1 現 状 では 利 用 者 がブラウザで OV 証 明 書 と DV 証
明 書 を 明 確 に 識 別 することは 難 しい、2サーバ 運 営 組 織 等 の 確 認 項 目
や 確 認 方 法 は 個 々の 認 証 局 によって 異 なる、という 課 題 もある。
OV 証 明 書 と 同 様 で、ドメイン 名 の 利 用 権 に 加 えて,サーバ 運 営 組 織 の
実 在 性 等 の 確 認 やドメイン 名 と 運 営 組 織 との 関 係 などについても 確 認
した 上 で 発 行 される 証 明 書 。
3 つの 証 明 書 のなかでは 発 行 コストが 最 もかかるが、 以 下 の 点 で DV 証
明 書 や OV 証 明 書 に 対 して 優 位 点 を 持 つ。
• 運 営 組 織 の 法 的 実 在 性 について、CA/Browser Forum が 規 定 した 国 際
的 な 認 定 基 準 にもとづいて 確 認 が 行 われる。このため 認 証 局 に 依 ら
ず 一 定 レベルの 確 認 が 保 証 される
• ブラウザのアドレス 表 示 部 分 等 が 緑 色 になる「グリーンバー」 機 能
が 有 効 に 機 能 する 場 合 には、 利 用 者 にとって EV 証 明 書 であること
の 識 別 が 容 易
• グリーンバーには 運 営 組 織 も 表 示 されるため,ドメイン 名 との 関 係
が 一 目 でわかる
7.1.3 サーバ 証 明 書 の 有 効 期 限
サーバ 管 理 者 は、サーバ 証 明 書 の 更 新 漏 れによって 自 社 のサービスに 障 害 を 発 生 させることが
ないように、サーバ 証 明 書 の 有 効 期 間 を 管 理 し、 更 新 作 業 のために 必 要 なリードタイムを 考 慮 し
た 上 で、 適 切 な 管 理 方 法 ( 例 えば、 更 新 作 業 開 始 時 期 の 明 文 化 など)を 定 めることが 求 められる。
市 販 されているサーバ 証 明 書 の 有 効 期 間 は、 半 年 や 1 年 程 度 のものから、2 年 、3 年 程 度 のもの
等 様 々である。 一 般 に、 有 効 期 間 が 長 いほど、サーバ 証 明 書 の 更 新 頻 度 が 少 なく 更 新 作 業 の 工 数
を 削 減 できる。しかし、その 反 面 、 単 純 なミスによる 更 新 忘 れ、 組 織 改 編 ・ 担 当 者 異 動 時 の 引 き
継 ぎ 不 備 による 更 新 漏 れ、 鍵 危 殆 化 ( 秘 密 鍵 の 漏 えい)リスクの 増 大 、サーバ 証 明 書 に 記 載 され
たサーバの 運 営 組 織 情 報 が( 組 織 名 変 更 などにより) 正 確 でなくなるリスクの 増 大 、アルゴリズ
ム Agility(セキュリティ 強 度 の 変 化 に 対 して、 安 全 な 側 に 移 行 するための 対 策 に 要 する 時 間 、 迅
SSL/TLS 暗 号 設 定 ガイドライン - 45

速 さの 程 度 )の 低 下 などが 危 惧 されるようになる。 特 に、2 年 や 3 年 など 比 較 的 長 い 間 有 効 なサ
ーバ 証 明 書 を 利 用 する 場 合 には、 管 理 者 がサーバ 証 明 書 の 有 効 期 限 切 れに 気 づかず、 更 新 漏 れに
よるサービス 障 害 の 発 生 が 大 きなリスクとなりえる。
これらを 総 合 的 に 勘 案 し、 特 段 の 制 約 が 存 在 しない 限 り、サーバ 管 理 者 は、1 年 程 度 の 有 効 期
間 を 持 つサーバ 証 明 書 を 選 択 し、サーバ 証 明 書 の 更 新 作 業 を、 年 次 の 定 型 業 務 と 位 置 付 けること
が 望 ましい。
なお、SHA-1 を 利 用 しているサーバ 証 明 書 に 関 しては、クライアントにおいて SHA-256 への 対
応 が 進 み、SHA-1 でなくても 運 用 上 の 支 障 がなくなった 場 合 に、 速 やかに SHA-256 を 利 用 してい
るサーバ 証 明 書 への 移 行 ができるようにするため、 有 効 期 間 をできるだけ 短 く 設 定 することが 望
ましい。
7.1.4 サーバ 鍵 の 適 切 な 管 理
サーバ 管 理 者 は、サーバ 証 明 書 に 対 応 する 秘 密 鍵 について、 紛 失 、 漏 えい 等 が 発 生 しないよう
に 適 切 に 管 理 しなければならない。 秘 密 鍵 の 紛 失 (データ 破 壊 を 含 む)に 備 えバックアップを 作
成 し 保 管 する 場 合 には、 秘 密 鍵 の 危 殆 化 30 ( 漏 えいなど)が 発 生 しないようにするために、バッ
クアップの 方 法 や 保 管 場 所 、その 他 の 保 管 の 要 件 について 注 意 深 く 設 計 することが 求 められる。
サーバ 管 理 者 は、 秘 密 鍵 が 危 殆 化 した 際 に 遅 滞 なく 適 切 な 対 処 を 行 うため、 必 要 に 応 じて、 次
のような 事 項 について、あらかじめ、 方 針 及 び 手 順 を 整 理 し 文 書 化 することが 推 奨 される。
• 秘 密 鍵 の 危 殆 化 に 対 応 するための 体 制 ( 関 係 者 と 役 割 、 委 託 先 との 連 携 を 含 む)
• 秘 密 鍵 が 危 殆 化 した、またはその 恐 れがあると 判 断 するための 基 準
• 秘 密 鍵 の 危 殆 化 の 原 因 を 調 べること、 及 び、 原 因 の 解 消 を 図 ること
• 当 該 サーバ 証 明 書 の 利 用 を 停 止 すること( 実 施 の 判 断 基 準 、 手 順 を 含 む)
• 当 該 サーバ 証 明 書 を 遅 滞 なく 失 効 すること( 実 施 の 判 断 基 準 、 手 順 を 含 む)
• 新 しい 鍵 ペアを 生 成 し、 新 鍵 に 対 して 新 しくサーバ 証 明 書 の 発 行 を 行 うこと
• 秘 密 鍵 の 危 殆 化 についての 情 報 の 開 示 ( 通 知 先 、 通 知 の 方 法 、 公 表 の 方 針 等 )
7.1.5 複 数 サーバに 同 一 のサーバ 証 明 書 を 利 用 する 場 合 の 注 意
負 荷 分 散 や 冗 長 化 による 可 用 性 向 上 などを 目 的 として 複 数 のサーバに 同 一 のサーバ 証 明 書 をイ
ンストールして 利 用 する 場 合 、サーバ 管 理 者 は、 以 下 の 観 点 で 注 意 が 必 要 である。
• サーバ 証 明 書 の 更 新 や 再 発 行 の 際 には、 入 替 作 業 の 対 象 となる 全 てのサーバについて 漏 れ
なく 証 明 書 をインストールしなおすこと
• サーバ 証 明 書 の 入 替 えに 伴 って 暗 号 通 信 に 関 わる 設 定 (4 章 から 7 章 までを 参 照 )の 変 更
を 行 う 場 合 は、 対 象 となる 全 てのサーバに 漏 れなく 適 用 すること
30
安 全 性 上 の 問 題 が 生 じ、 信 用 できなくなる 状 態 のこと
SSL/TLS 暗 号 設 定 ガイドライン - 46

サーバ 管 理 者 は、サーバ 証 明 書 の 入 替 作 業 の 対 象 となるサーバに 漏 れが 発 生 しないよう、サー
バ 毎 にペアとなる 秘 密 鍵 や 暗 号 スイートなどの 情 報 を 一 覧 管 理 し、また 外 部 からの 監 視 /スキャ
ンツールを 用 いたチェックと 組 合 せるなど、 管 理 方 法 を 定 め 文 書 化 することが 推 奨 される。
7.1.6 ルート CA 証 明 書
サーバ 証 明 書 の 安 全 性 は、その 証 明 書 を 発 行 する 認 証 局 自 体 の 安 全 性 はもとより、 最 終 的 には
信 頼 の 起 点 (トラストアンカー)となる 最 上 位 の 認 証 局 (ルート CA)の 安 全 性 に 依 拠 している。
このことは、ルート CA の 用 いる 暗 号 アルゴリズムおよび 鍵 長 の 安 全 性 が 十 分 でなければ、サ
ーバ 証 明 書 の 安 全 性 も 確 保 することができないことを 意 味 している。 例 えば、ルート CA 証 明 書
の 安 全 性 に 問 題 が 生 じ、ブラウザベンダなどが 当 該 ルート CA 証 明 書 を 失 効 させた 場 合 、サーバ
証 明 書 自 体 には 問 題 がなかったとしてもルート CA 証 明 書 とともに 失 効 することとなる。
このようなリスクを 避 けるためには、サーバ 管 理 者 は、 信 頼 の 起 点 (トラストアンカー)とな
るルート CA についても、 当 該 サーバ 証 明 書 と 同 様 の 安 全 性 を 満 たすルート CA 証 明 書 を 発 行 し
ているルート CA を 選 ぶべきである。ルート CA 証 明 書 で 利 用 している 暗 号 アルゴリズムおよび
鍵 長 の 確 認 方 法 については、Appendix D.1 を 参 照 されたい。
【コラム4】 DigiNotar 認 証 局 事 件
2011 年 8 月 、オランダの 認 証 局 事 業 者 DigiNotar 社 によって 多 数 のサーバ 証 明 書 が 不 正 に
発 行 されていることが 発 覚 した。 本 事 件 は、 主 要 なブラウザベンダによって 同 社 のルート
CA 証 明 書 を 無 効 化 する 緊 急 パッチが 提 供 された 点 、ならびに 不 正 発 行 の 規 模 が 過 去 に 類 を
見 ないという 2 点 において 関 心 を 集 めた 象 徴 的 な 事 件 となった。
同 社 はパブリックルート 認 証 局 として 主 にオランダ 国 内 を 市 場 として 証 明 書 を 発 行 して
いたが、2011 年 6 月 に 同 社 の 認 証 局 システムが 攻 撃 者 によって 侵 入 され、1 ヶ 月 以 上 に 渡 る
遠 隔 操 作 により 少 なくとも 531 枚 以 上 の 不 正 な 証 明 書 が 発 行 された。これらの 証 明 書 は、イ
ラン 国 内 から Google 社 の Gmail サービスへのアクセスに 対 する 中 間 者 攻 撃 等 に 悪 用 された。
このような 事 態 を 踏 まえ、 同 年 9 月 には 同 社 ルート CA 証 明 書 が 主 要 なブラウザから 無 効 化
されることとなった。
ルート CA 証 明 書 が 無 効 化 された 場 合 、その 認 証 局 が 発 行 する 証 明 書 を 利 用 する Web サー
バへの 影 響 は 避 けられない。このような 場 合 、サーバ 管 理 者 は 他 の 認 証 局 からサーバ 証 明 書
を 早 急 に 取 得 しなおすことが 必 要 となる。
世 界 の 認 証 局 事 業 者 は、サーバ 証 明 書 やルート CA 証 明 書 に 用 いる 暗 号 アルゴリズムのみ
ならず、 認 証 局 システム 自 体 のセキュリティを 維 持 ・ 向 上 させるための 対 策 を 含 む 業 界 基 準
を 制 定 し(CA/ブラウザフォーラムによる「Baseline Requirement」 等 )、こうした 事 件 の 再 発
防 止 を 図 っている。
SSL/TLS 暗 号 設 定 ガイドライン - 47

7.2 さらに 安 全 性 を 高 めるために
7.2.1 HTTP Strict Transport Security(HSTS)の 設 定 有 効 化
例 えばオンラインショッピングサイトのトップページが 暗 号 化 なしの HTTP サイトで、ショッ
ピングを 開 始 する 際 に HTTPS へリダイレクトされるような 構 成 になっていた 場 合 、リダイレク
トを 悪 意 のあるサイトに 誘 導 し、 情 報 を 盗 むといった 中 間 者 攻 撃 が SSL strip というツールを 用 い
て 可 能 であるという 報 告 が Moxie Marlinspike によってなされた。
この 攻 撃 に 対 して、HTTP で 接 続 したら、すぐに 強 制 的 に HTTPS サイトへリダイレクトし、 以
降 の 通 信 は 全 て HTTPS とすることによって 防 御 する 技 術 が RFC 6797 で 規 定 されている HTTP
Strict Transport Security(HSTS)である。
HSTS に 対 応 した SSL/TLS サーバに HTTPS でアクセスした 場 合 、HTTPS 応 答 には 以 下 のよう
な HTTP ヘッダが 含 まれている。
Strict-Transport-Security:max-age= 有 効 期 間 秒 数 ;includeSubDomains
このヘッダを 受 け 取 った HSTS 対 応 のブラウザは、 有 効 期 間 の 間 は 当 該 サーバへは HTTP では
なく 全 て HTTPS で 通 信 するように 自 動 設 定 しておく。これにより、 以 前 接 続 したときに HSTS
が 有 効 になっているサーバであれば、 何 らかの 理 由 で、ブラウザが HTTP で 接 続 しようとしても
自 動 的 に HTTPS に 切 り 替 えて 接 続 する。
以 上 のように、HTTPS で 安 全 にサービスを 提 供 したい 場 合 などでは、ユーザに 意 識 させること
なくミスを 防 止 でき、ユーザの 利 便 性 を 向 上 させることができるので、HSTS の 機 能 を 持 ってい
るならば 有 効 にすることを 推 奨 する。 参 考 までに、いくつかの 設 定 例 を Appendix B.4 で 紹 介 する。
ただし、HSTS が 実 際 に 機 能 するためには、サーバだけでなく、ブラウザも 対 応 している 必 要
があることに 注 意 されたい。また、 一 度 も 接 続 したことがないサーバ( 例 外 的 に Firefox 17 以 降
ではあらかじめ 登 録 されているサーバもある)や、HSTS の 期 限 切 れになったサーバの 場 合 にも、
HTTPS への 変 換 は 行 われない。
2014 年 9 月 時 点 での 主 要 な 製 品 の HSTS へのサポート 状 況 は 以 下 の 通 りである。
• サーバ
‣ Apache 2.2.22 以 降 : 設 定 により 可 能
‣ Lighttpd 1.4.28 以 降 : 設 定 により 可 能
‣ nginx 1.1.19 以 降 : 設 定 により 可 能
‣ IIS: 設 定 により 可 能
• クライアント(ブラウザ)
‣ Chrome:4.0.211.0 以 降 でサポート
‣ Firefox:Firefox 17 以 降 でサポート
‣ Opera:Opera 12 以 降 でサポート
‣ Safari:Mac OS X Mavericks 以 降 でサポート
‣ Internet Explorer:Windows 10 IE 以 降 でサポート 予 定
SSL/TLS 暗 号 設 定 ガイドライン - 48

7.2.2 リネゴシエー
ーションの
脆 弱 性 への 対 策
リネゴシエーションとは、サー
ーバとクライアントとの 間 で 暗 号 アルゴリズムや 暗 号 鍵 の 設 定 の
ために 使 われる 事 前 通 信 (ハンドシェイク)において、 一 度 確 立 したセッションに 置 き 換 わる 新
たなセッションを 確 立 する 際 に、 、すでに 確 立 したセッションを 使 って 改 めてハンドシェイクを 行
う 機 能 である。
リネゴシエーションの 脆 弱 性 とは、クライアントとサーバの 間 に 攻 撃 者 が 入 る 中 間 者 攻 撃 によ
って、 通 信 データの 先 頭 部 分 に 任 意 のデー タを 挿 入 することがで
できるというものである( 図 5)。
これにより、 例 えば、 攻 撃 者 が 挿 入 した HTTP リクエストを、あたかも 正 当 なユーザから 送 られ
たリクエストであるかのようにサーバに 誤 認 させるといったことができる。
図 5 リネゴシエーションの 脆 弱 性
この 脆 弱 性 のポイントは、リネゴシエー
ションが 確 立 したセッションを 使 って 行 われることか
ら、リネゴシエーションの 前 後 の 通 信 が 同 じ 通 信 相 手 である、という 前 提 で 処 理 が 行 われる 点 に
ある。ところが、 実 際 に 図 5の(10)で 確 立 したセッションは、
クライアントにとっ
て 一 回 目 の
ハンドシェイクで 確 立 したセッション( 図 5 の( 1)の の 要 求 に 対 するセッシ
ョン)なのに 対 して、
サーバはリネゴシエー
ーションで 確 立 したセッション(
図 5 の( 7)の 要 求 に 対 するセッション)
になっている。
それにも
関 わらず、 両 者 がその
食 い 違 いを 認 識 できないため、
その 結 果 として、サー
ーバは、リ
ネゴシエー ーション 前 の 攻 撃 者 からの 通 信 ( 図 5 の(5)の 通 信 ) とリネゴシエーション 後 のクラ
SSL/TLS 暗 号 設 定 ガイドライン - 49

イアントからの 通 信 ( 図 5 の(11)(12)の 通 信 )を、 同 一 クライアントからの 通 信 と 誤 認 して
受 け 付 けて 処 理 を 行 うことになり、 予 期 せぬ 事 態 を 引 き 起 こす 可 能 性 がある。
【 推 奨 対 策 】
リネゴシエーションに 関 するプロトコル 上 の 脆 弱 性 であることから、 対 策 としては 以 下 のどち
らかの 設 定 とすることを 推 奨 する。
• リネゴシエーションを 利 用 不 可 とする
• リネゴシエーションの 脆 弱 性 対 策 (RFC5746)を 反 映 したバージョンの 製 品 を 利 用 すると
ともに、 対 策 が 取 られていないバージョンの 製 品 からのリネゴシエーション 要 求 は 拒 否 す
る 設 定 を 行 う
7.2.3 圧 縮 機 能 を 利 用 した 実 装 攻 撃 への 対 策
圧 縮 機 能 は、 何 度 も 出 てくる 同 じ 長 い 文 字 列 を 別 の 短 い 情 報 に 置 き 換 えることで 全 体 のデータ
サイズを 削 減 し、 通 信 効 率 を 向 上 させるために 利 用 するものである。
しかしながら、 圧 縮 対 象 となる 文 字 列 に 秘 密 情 報 が 含 まれている 場 合 、 圧 縮 機 能 によって 別 の
情 報 に 置 き 換 わることによるデータサイズの 変 動 に 着 目 することによって、どの 文 字 列 が 圧 縮 さ
れたのかが 分 かる 可 能 性 がある。しかも、 着 目 しているのはデータサイズであるので、データが
暗 号 化 されているかどうかは 関 係 がない。
実 際 にこのような 圧 縮 機 能 を 利 用 した 実 装 攻 撃 として、CRIME、TIME、BREACH などがある。
これらの 攻 撃 は、SSL/TLS のプロトコル 自 体 の 脆 弱 性 ではなく、 圧 縮 機 能 の 特 性 そのものを 利 用
した 攻 撃 方 法 である。したがって、 根 本 的 な 対 策 としては「SSL/TLS では 圧 縮 機 能 を 利 用 しない」
こと 以 外 に 方 法 はない。
このため、 最 近 のバージョンの OpenSSL や Windows などでは、デフォルト 設 定 がオフになっ
ていたり、そもそもサポートを 取 りやめたりしている。
7.2.4 OCSP Stapling の 設 定 有 効 化
サービス 提 供 の 終 了 やサーバの 秘 密 鍵 の 漏 えいなど、 何 らかの 理 由 で、サーバ 証 明 書 の 有 効 期
間 内 であっても 当 該 サーバ 証 明 書 が 失 効 している 場 合 がある。そのため、サーバ 証 明 書 の 正 当 性
を 確 認 する 時 には、 当 該 サーバ 証 明 書 が 失 効 していないかどうかもあわせて 確 認 すべきである。
サーバ 証 明 書 が 失 効 されていないか 確 認 する 方 法 として、CRL 31 と OCSP 32 の 二 つの 方 法 がある
が、CRL はサイト 数 の 増 大 に 伴 ってファイルサイズが 増 大 しており、 近 年 では OCSP のみに 依 存
するブラウザが 多 くを 占 めている。
ただ、OCSP を 使 用 した 場 合 には 2 つの 問 題 がある。
1) OCSP 実 行 時 の 通 信 エラー 処 理 について 明 確 な 規 定 がなく、ブラウザの 実 装 に 依 存 する。
このため、OCSP レスポンダの 通 信 障 害 等 で 適 切 な OCSP 応 答 が 得 られない 場 合 にサーバ
証 明 書 の 失 効 検 証 を 正 しく 行 わないまま SSL 通 信 を 許 可 してしまうブラウザも 少 なくな
31
Certificate Revocation List
32
Online Certificate Status Protocol
SSL/TLS 暗 号 設 定 ガイドライン - 50

い。そのようなブラウザに 対 しては、あるサイトのサーバ 証 明 書 が 失 効 していたとしても、
DDoS 攻 撃 などにより 意 図 的 に OCSP レスポンダに 接 続 させないことにより、 当 該 サイト
が 有 効 であるとして SSL/TLS 通 信 をさせることができる
2) OCSP を 使 った 場 合 には、あるサイトにアクセスがあったことを OCSP レスポンダも 知 り
得 てしまうため、プライバシー 上 の 懸 念 がある。 例 えば、ある 利 用 者 が、ある 会 員 制 のサ
イトにアクセスした 場 合 、ブラウザはサーバ 証 明 書 の 失 効 検 証 のために 当 該 サイトの
OCSP 応 答 を 取 得 する。そこで、OCSP レスポンダのアクセス 履 歴 から、ある 接 続 元 IP の
利 用 者 は、 当 該 サイトの 会 員 であると OCSP レスポンダが 知 り 得 ることになる
上 記 の 問 題 を 解 決 するために、RFC 6066 Transport Layer Security (TLS) Extension: Extension
Definition の 8 節 で、Certificate Status Request という TLS 拡 張 が 規 定 されている。これを 使 うこと
により、OCSP 応 答 を OCSP レスポンダからではなく、アクセス 先 サイトの Web サーバから 取 得
して SSL/TLS 通 信 を 開 始 することができる。
• OCSP レスポンダからの OCSP 応 答 を Web サーバがキャッシュしている 限 り、ブラウザは
OCSP 応 答 による 失 効 検 証 を 行 うことができる
• OCSP 応 答 を、OCSP レスポンダからではなく、Web サーバから 取 得 するので、 当 該 サイト
へのアクセス 履 歴 を OCSP レスポンダが 知 ることはない
なお、OCSP Stapling は 2014 年 9 月 時 点 で 以 下 の 環 境 においてサポートされている。 参 考 まで
に、いくつかの 設 定 例 を Appendix B.5 で 紹 介 する。
• サーバ
‣ Apache HTTP Server 2.3.3 以 降
‣ nginx 1.3.7 以 降
‣ Microsoft IIS on Windows Server 2008 以 降
など
• クライアント(ブラウザ)
‣ Mozilla Firefox 26 以 降
‣ Microsoft Internet Explorer (Windows Vista 以 降 )
‣ Google Chrome
など
7.2.5 Public Key Pinning の 設 定 有 効 化
近 年 、FLAME 攻 撃 や、DigiNotar、TURKTRUST などの 認 証 局 からのサーバ 証 明 書 の 不 正 発 行
など、 偽 のサーバ 証 明 書 を 使 った 攻 撃 手 法 が 増 加 傾 向 にある。これらの 攻 撃 により 発 行 されたサ
ーバ 証 明 書 は、 認 証 局 が 意 図 して 発 行 したものではないという 意 味 で“ 偽 物 ”であるが、 動 作 そ
のものは“ 本 物 ”と 同 じふるまいをする。
このため、この 種 の 攻 撃 に 対 しては、 従 来 の PKI による、 信 頼 するルート 証 明 書 のリストと、
SSL/TLS 暗 号 設 定 ガイドライン - 51

証 明 書 チェーンの 検 証 ( 認 証 パス 検 証 )だけでは 正 当 なサーバ 証 明 書 であるかどうかの 判 断 がつ
かない。
これを 補 う 目 的 で 導 入 されつつあるのが、Public Key Pinning(もしくは Certificate Pinning)と
呼 ばれている 技 術 である。 従 来 の PKI による 証 明 書 チェーンの 検 証 に 加 え、Public Key Pinning で
は、あるサイト 用 に 期 待 されるサーバ 証 明 書 の 公 開 鍵 情 報 (SPKI; Subject Public Key Info)フィー
ルドの 情 報 のハッシュ 値 を 比 較 することにより、 当 該 サーバ 証 明 書 が 正 当 なものであるかどうか
を 判 断 する。
2014 年 9 月 時 点 で、Public Key Pinning をサポートしている 環 境 は 以 下 の 通 りである。
• サーバ
‣ HTTP ヘッダを 追 加 可 能 な 任 意 のサーバ
• クライアント
‣ Google Chrome 13 以 降
‣ Mozilla Firefox 32 以 降 (デスクトップ 版 )、34 以 降 (Android 版 )
‣ Internet Explorer: マイクロソフト 脆 弱 性 緩 和 ツール(EMET 33 ) を 導 入 することで 設
定 可 能 (EMET バージョン 4.0 以 降 よりサポート)
期 待 されるハッシュ 値 の 提 供 方 法 には 2 通 りある。
1) ブラウザのソースコードに 主 要 なサイトの SPKI フィールドの 情 報 のハッシュ 値 リストを
保 持 し、これと 比 較 して SSL サーバ 証 明 書 が 正 当 であるかを 調 べるもの。2014 年 9 月 時
点 では Google Chrome や Mozilla Firefox がサポートしている。
2) サイトから 送 られる HTTP ヘッダに 含 まれる、SSL サーバ 証 明 書 の SPKI フィールドの 情
報 のハッシュ 値 を 元 に 正 当 性 を 比 較 するもの。IETF において、Public Key Pinning Extension
for HTTP として 発 行 された。 参 考 までに、いくつかの 設 定 例 を Appendix B.6 で 紹 介 する。
33 http://technet.microsoft.com/ja-jp/security/jj653751
SSL/TLS 暗 号 設 定 ガイドライン - 52

PART II:
ブラウザ&リモートアクセスの 利 用 について
SSL/TLS 暗 号 設 定 ガイドライン - 53

8. ブラウザを 利 用 する 際 に 注 意 すべきポイント
8.1 本 ガイドラインが 対 象 とするブラウザ
8.1.1 対 象 とするプラットフォーム
ベンダがセキュリティホールに 対 する 修 正 を 行 っている OS を 利 用 すべきである。 本 ガイドラ
インの 公 開 時 点 (2015 年 5 月 )で、サポート 対 象 となっているものは 以 下 の 通 りである。
• デスクトップ 向 け OS
‣ Windows Vista Service Pack 2 (2017 年 4 月 11 日 サポート 終 了 )
‣ Windows 7 Service Pack 1 (2020 年 4 月 11 日 サポート 終 了 )
‣ Windows 8 (2016 年 1 月 12 日 サポート 終 了 )
‣ Windows 8.1 (2023 年 1 月 10 日 サポート 終 了 )
‣ Mac OS X 10.9
• スマートフォン 向 け OS
‣ 当 該 端 末 で 利 用 できる 最 新 の Android(もっとも 古 いもので Android4.x)
‣ iOS 8
8.1.2 対 象 とするブラウザのバージョン
ブラウザは、 少 なくとも 提 供 ベンダがサポートしているバージョンのものを 利 用 すべきである。
本 ガイドラインの 公 開 時 点 (2015 年 5 月 )でサポートしている、8.1.1 節 に 挙 げた OS 上 で 動 作 す
るブラウザのバージョンは 以 下 のとおりである。
• Microsoft Internet Explorer
2016 年 1 月 12 日 以 降 は、サポートされるオペレーティングシステムで 利 用 できる 最 新 バ
ージョンの Internet Explorer のみがテクニカルサポートとセキュリティ 更 新 プログラムを
提 供 されるようになる( 表 16)。 詳 細 は、 以 下 を 参 照 のこと。
Microsoft Internet Explorer サポート ライフサイクル ポリシーに 関 する FAQ
http://support2.microsoft.com/gp/microsoft-internet-explorer
• Microsoft Internet Explorer 以 外 のブラウザ
‣ Apple Safari 最 新 版
‣ Google Chrome 最 新 版
‣ Mozilla Firefox 最 新 版
‣ Mobile Safari(iOS):iOS 8 に 搭 載 する Mobile Safari
SSL/TLS 暗 号 設 定 ガイドライン - 54

表 16 Internet Explorer のサポート 期 間
ブラウザバージョン
OSバージョン
サポート 期 間 (ライフサイクルポリシー@2014 年 11 月 10 日 時 点 )
2015 2016 2017 2018 2019 2020 2021 2022 2023
Internet Explorer 7 Windows Vista SP2 2016/1/12
Internet Explorer 8
Internet Explorer 9
Internet Explorer 10
Internet Explorer 11
Windows Vista SP2 2016/1/12
Windows 7 SP1 2016/1/12
Windows Vista SP2 2017/4/11
Windows 7 SP1 2016/1/12
Windows 7 SP1 2016/1/12
Windows 8 2016/1/12
Windows 7 SP1 2020/1/14
Windows 8.1 2023/1/10
8.2 設 定 に 関 する 確 認 項 目
8.2.1 基 本 原 則
8.1 節 で 対 象 とするブラウザは、インストール 時 のデフォルト 設 定 で 利 用 することを 各 ベンダ
は 推 奨 しているので、 企 業 の 情 報 システム 担 当 からの 特 別 な 指 示 がある 場 合 などを 除 き、 原 則 と
してデフォルト 設 定 を 変 えずに 利 用 することを 強 く 推 奨 する。
【 基 本 原 則 】
• ベンダがサポートしているブラウザであって、 更 新 プログラムを 必 ず 適 用 する(Internet
Explorer の 場 合 )、または 最 新 バージョンのブラウザを 利 用 する(Internet Explorer 以 外 )
• 自 動 更 新 を 有 効 化 しておく
• 企 業 の 情 報 システム 担 当 からの 特 別 な 指 示 がある 場 合 などに 限 り、 社 内 ポリシーに 従 う
8.2.2 設 定 項 目
設 定 項 目 を 標 準 機 能 で 提 供 していないブラウザ
以 下 のブラウザは、 設 定 変 更 オプションが 提 供 されておらず、そもそも 設 定 変 更 ができない。
• PC 版 Web ブラウザ
‣ Apple Safari
‣ Google Chrome
• スマートフォンに 含 まれる Web ブラウザ
‣ Android 標 準 ブラウザ
‣ Mobile Safari (iOS)
SSL/TLS 暗 号 設 定 ガイドライン - 55

設 定 項 目 を 標 準 機 能 で 提 供 しているブラウザ
以 下 のブラウザは、 設 定 変 更 オプションが 提 供 されている。ただし、 特 別 な 指 示 がない 限 り、
デフォルト 設 定 を 変 更 すべきではない。
• Microsoft Internet Explorer
他 のブラウザとは 異 なり、Internet Explorer では、
“ツール”→“インターネットオプション”→“ 詳 細 設 定 ”
を 選 択 すると 多 数 の 設 定 項 目 が 表 示 され、ユーザが 細 かく 設 定 できるようになってはいる。
しかし、 安 全 性 を 考 慮 してデフォルト 設 定 が 行 われていることから、 特 段 の 理 由 がない 場
合 には“プロトコルバージョンの 設 定 を 除 いて” 設 定 を 変 更 することは 推 奨 しない。
なお、Internet Explorer のセキュリティ 機 能 及 びデフォルト 設 定 については、 以 下 に 一 覧 と
してまとめられている。
バージョン 別 IE のセキュリティ 機 能
http://msdn.microsoft.com/ja-jp/ie/cc844005.aspx
【プロトコルバージョンの 設 定 】
“ツール”→“インターネットオプション”→“ 詳 細 設 定 ”を 選 択 した 後 、 設 定 項 目 を“セ
キュリティ”までスクロールさせると、「SSL2.0 を 使 用 する」「SSL3.0 を 使 用 する」「TLS1.0
を 使 用 する」「TLS1.1 を 使 用 」「TLS1.2 を 使 用 」といったチェックボックスが 表 示 される。
ここでのチェックボックスにチェックが 入 っているプロトコルバージョンが、ブラウザが
使 うことができるプロトコルバージョンとなる。
本 ガイドライン 公 開 時 点 (2015 年 5 月 )のデフォルト 設 定 では、IE6 では「SSL2.0 を 使 用
する」にチェックが 入 っている 一 方 、IE8 以 降 では TLS1.1 や TLS1.2 をサポートしている
ものの「TLS1.1 を 使 用 」「TLS1.2 を 使 用 」にはチェックが 入 っていない。
このように、Internet Explorer は 使 うバージョンによって 利 用 できるプロトコルバージョン
が 異 なるので、プロトコルバージョンについてのみ、 適 切 な 設 定 になっているかを 確 認 し、
必 要 に 応 じて 設 定 変 更 することを 推 奨 する。
TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0
IE6( 参 考 ) × × ▲ ○ ○
IE7 × × ○ ○ ▲
IE8 ▲ ▲ ○ ○ ▲
IE9 ▲ ▲ ○ ○ ▲
IE10 ▲ ▲ ○ ○ ▲
IE11 ▲ ▲ ○ ○ ▲
○:デフォルト 設 定 ON ▲:デフォルト 設 定 OFF ×:サポートしていない
SSL/TLS 暗 号 設 定 ガイドライン - 56

• Firefox
Firefox では、 、サーバ 証 明 書 の 検 証 、 失 効 機 能 においてどのように 処 理 するかの 動 作 につ
いてのみ 設 定 方 法 を 提 供 している。
この 設 定 については、
“メニュー ー”→“オプション”→“ 詳 細 ” →“ 証 明 書 ”→“ 検 証 (V)…”
を 選 択 することで 設 定 方 法 へのダイアログが 表 示 される。
デフォルトの
設 定 は 以 下 のようになっており、 特 段 の 理 由 がない 場 合 に 変 更 することは
推 奨 しない。
8.3 ブラウザ 利 用 時 の 注 意 点
8.3.1 鍵 長 1024 ビット、SHA-1 を 利 用 するサー ーバ 証 明 書 の 警 告 表 示
CA/Browser Forum にて、サー ーバ 証 明 書 の 有 効 期 限 が 2014 年 1 月 1 日 以 降 の 場 合 、RSA の 鍵 長
SSL/TLS 暗 号 設 定 ガイドライン -
57

を 最 小 2048 ビットにすると 決 められている。このため、ブラウザベンダ 各 社 では、RSA の 鍵 長
が 2048 ビット 未 満 のものは 順 次 無 効 にする 対 処 がされている。また、SHA-1 についても、 順 次
無 効 化 する 対 処 が 予 定 されている。
詳 しくは 以 下 のとおりである。
• Microsoft Internet Explorer
2017 年 1 月 1 日 より SHA-1 で 署 名 されたサーバ 証 明 書 を 受 け 付 けない 34 。 詳 細 は 別 途 追 記
予 定
• Google Chrome
Chrome 39 より 順 次 、SHA-1 で 署 名 されたサーバ 証 明 書 については、アドレスバーの 鍵 ア
イコンが 別 表 記 になる 35,36 。 以 下 のようにサーバ 証 明 書 の 有 効 期 限 によって 表 記 は 変 化 する。
バージョン サーバ 証 明 書 の 有 効 期 限 アドレスバーの 鍵 アイコンの 表 記
39 2017 年 1 月 1 日 以 降 黄 色 い 三 角 アイコン
40
2016 年 6 月 1 日 ~12 月 31 日 黄 色 い 三 角 アイコン
2017 年 1 月 1 日 以 降 HTTP と 同 様 の 表 示
42
2016 年 1 月 1 日 ~12 月 31 日 黄 色 い 三 角 アイコン
2017 年 1 月 1 日 以 降 赤 い×アイコン
• Firefox
2014 年 以 降 、SSL/TLS で 利 用 される RSA の 鍵 長 が 2048 ビットに 満 たないルート 証 明 書 は
順 次 無 効 になり、2015 年 の 中 頃 までにはすべてで 無 効 になる 37 。
また SHA-1 で 署 名 されたサーバ 証 明 書 についても、2015 年 以 降 にリリースされる 最 新 版 の
Firefox では、 以 下 のように 変 更 をする 予 定 である 38 。
バージョン サーバ 証 明 書 の 有 効 期 限 アドレスバーの 鍵 アイコンの 表 記
2015 年 以 降 の
バージョン
2017 年 1 月 1 日 以 降 警 告 表 示 をする UI を 追 加
2016 年 以 降 の
バージョン
2017 年 1 月 1 日 以 降 “ 接 続 の 安 全 性 を 確 認 できません”と 表 示
2017 年 以 降 の
バージョン
すべて
“ 接 続 の 安 全 性 を 確 認 できません”と 表 示
34 http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
35 http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html
36 https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/QNVVo4_dyQE
37 https://wiki.mozilla.org/CA:MD5and1024
38
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signaturealgorith
ms/
SSL/TLS 暗 号 設 定 ガイドライン - 58

8.3.2 SSL3.0 の 取 り 扱 い
POODLE 攻 撃 の 公 表 を 受 け、 各 ブラウザベンダは 順 次 SSL3.0 を 利 用 不 可 とする 対 処 を 取 り 始
めている。
• Internet Explorer
セキュリティ 情 報 MS15-032「Internet Explorer 用 の 累 積 的 なセキュリティ 更 新 プログラム
(3038314)」により、Internet Explorer 11 では SSL3.0 がデフォルトで 無 効 になっている。
それ 以 外 のバージョンの Internet Explorer では、 設 定 を 変 更 することにより、SSL3.0 を 無
効 化 することができる。 詳 しくは、 下 記 URL のマイクロソフトセキュリティアドバイザリ
を 参 照 のこと。
マイクロソフト セキュリティ アドバイザリ 3009008
https://technet.microsoft.com/ja-jp/library/security/3009008.aspx
• Google Chrome
Chrome 40 からデフォルトで SSL3.0 が 無 効 化 されている。
• Firefox
Firefox 34 および Firefox ESR 31.3.0 からデフォルトで SSL3.0 が 無 効 化 されている。
SSL/TLS 暗 号 設 定 ガイドライン - 59

9. その 他 のトピック
9.1 リモートアクセス VPN over SSL (いわゆる SSL-VPN)
SSL-VPN と 呼 ばれるものは、 正 確 には SSL を 使 った“リモートアクセス VPN”の 実 現 方 法 と
いえる。SSL-VPN 装 置 を 介 して SSL-VPN 装 置 の 奥 にあるサーバ(インターネットからは 直 接 ア
クセスできないサーバ)とクライアント 端 末 をつなぐ 形 での VPN であり、IPsec-VPN のような 特
定 端 末 間 だけで VPN を 構 成 する、いわゆる 拠 点 間 VPN とは 異 なる。
したがって、あくまでリモートアクセスでの 通 信 経 路 上 が SSL/TLS で 保 護 されているにすぎな
いと 考 え、 本 ガイドラインの 推 奨 セキュリティ 型 (または 高 セキュリティ 型 )の 設 定 を 適 用 する
こととし、Appendix A.3(または Appendix A.2)のチェックリストを 用 いて 確 認 すべきである。
なお、 一 口 に SSL-VPN といっても、 実 現 形 態 が 製 品 によって 全 く 異 なることに 注 意 がいる。
実 現 形 態 としては、 大 きく 以 下 の 3 通 りに 分 かれる。
• 通 常 のブラウザを 利 用 する“クライアントレス 型 ”
• 接 続 時 に 自 動 的 に Java や Active X をインストールすることでブラウザだけでなく、アプリ
ケーションでも 利 用 できるようにした“on-demand インストール 型 ”
• 専 用 のクライアントソフト( 通 信 アダプタなどを 含 む)をインストール・ 設 定 してから 利
用 する“クライアント 型 ”がある。
クライアントレス 型 は、ブラウザさえあればどの 端 末 からでもアクセス 可 能 であり、 利 便 性 に
優 れる 一 方 、SSL との 最 大 の 差 はグローバル IP をインターネットに 公 開 しているか 否 か 程 度 の 違
いといえる。 結 果 として、 最 初 のクライアント 認 証 を SSL/TLS サーバが 受 け 持 つか、SSL-VPN
装 置 が 受 け 持 つか 程 度 の 差 でしかなく、VPN というよりも、 本 質 的 には SSL/TLS と 同 じものとみ
るべきである。
On-demand インストール 型 も、 接 続 時 に 自 動 的 にインストールされることから、 特 に 利 用 端 末
に 制 限 を 加 えるものではなく、クライアントレス 型 と 大 きく 異 なるわけではない。むしろ、ブラ
ウザでしか 使 えなかったクライアントレス 型 を、 他 のアプリケーションでも 利 用 できるように 拡
張 したという 位 置 づけのものである。
一 方 、クライアント 型 は 上 記 の 2 つのタイプとは 明 らかに 異 なり、 専 用 のクライアントソフト
がインストールされた 端 末 との 間 でのみアクセスする。つまり、 誤 って 偽 サーバに 接 続 すること
がなく、また 内 部 サーバにアクセスできる 端 末 も 厳 格 に 制 限 できるため、 端 末 に IPsec-VPN ソフ
トをインストールして 構 成 するモバイル 型 の IPsec-VPN に 近 い 形 での 運 用 形 態 となる。
機 密 度 の 高 い 情 報 を 扱 うのだとすれば、 少 なくともクライアント 型 での SSL-VPN を 利 用 すべ
きである。
SSL/TLS 暗 号 設 定 ガイドライン - 60

【 参 考 : 通 常 の SSL/TLS】
【クライアントレス 型 (ブラウザベース)】
【On-demand インストール 型 (Java や Active X を 使 ってブラウザ
以 外 でも 利 用 可 能 )】
【クライアント 型 ( 専 用 ソフトベース)】
SSL/TLS 暗 号 設 定 ガイドライン -
61

Appendix:
付 録
SSL/TLS 暗 号 設 定 ガイドライン - 62

Appendix A:チェックリスト
チェックリストの 原 本 は 以 下 の URL からも 入 手 可 能 である。
[pdf
版 ] http: ://www.ipa.go.jp/files/000045652.pdf
[excel 版 ] http: ://www.ipa.go.jp/files/000045650.xlsx
A.1.
チェックリストの利 用 方 法
本 チェックリストは、 以 下 の 項 目 について、 選 択 した 設 定 基 準 に 対 応 したた 要 求 設 定 をもれなく
実 施 したことを 確 認 するためのチェックリストである。 選 択 した
設 定 基 準 に 応 じたチェックリス
トを 用 い、 すべてのチェック 項 目 について、 該 当 章 に 記 載 の 要 求 設 定 に 合 致 していることを 確 認
して「 済 」 にチェックが 入 ることが 求 められる。
SSL/TLS 暗 号 設 定 ガイドライン -
63

A.2.
高 セキュリティ 型 のチェックリスト
SSL/TLS 暗 号 設 定 ガイドライン - 64

A.3.
推 奨 セキュリティ型 のチェックリスト
SSL/TLS 暗 号 設 定 ガイドライン - 65

SSL/TLS 暗 号 設 定 ガイドライン - 66

SSL/TLS 暗 号 設 定 ガイドライン - 67

A.4.
セキュリティ 例 外 型 のチェックリスト
SSL/TLS 暗 号 設 定 ガイドライン - 68

SSL/TLS 暗 号 設 定 ガイドライン - 69

SSL/TLS 暗 号 設 定 ガイドライン - 70

Appendix B:サーバ 設 定 編
本 Appendix では、サーバ 設 定 を 行 う 上 での 参 考 情 報 として、 設 定 方 法 例 を 記 載 する。
なお、 利 用 するバージョンやディストリビューションの 違 いにより、 設 定 方 法 が 異 なったり、
設 定 ができなかったりする 場 合 があることに 留 意 すること。 正 式 な 取 扱 説 明 書 やマニュアルを 参
照 するとともに、 一 参 考 資 料 として 利 用 されたい。
B.1.
サーバ 設 定 方 法 例 のまとめ
B.1.1. Apache の 場 合
Apache HTTP Server の 設 定 ファイル(デフォルトの 場 合 、httpd-ssl.conf)での 設 定 例 を 以 下 に 示
す。
( 中 略 )
SSLEngine on
39
証 明 書 と 鍵 の 設 定
SSLCertificateFile /etc/ssl/chain.crt
SSLCertificateKeyFile /etc/ssl/server.key
暗 号 スイート 設 定 。Appendix C.2 も 参 照 のこと
SSLCipherSuite " 暗 号 スイート 設 定 "
プロトコルバージョン 設 定 。Appendix B.2.1 も 参 照 のこと
SSLProtocol バージョン 設 定
暗 号 スイート 順 序 サーバ 優 先 設 定
SSLHonorCipherOrder On
HTTP Strict Transport Security、OCSP Stapling、Public Key Pinning の 設 定 をする 場 合 には、
ここに 追 記 する。7.2 節 及 び Appendix B.4 以 降 も 参 照 のこと
39
設 定 する 内 容 は 以 下 のとおり。
/etc/ssl/chain.crt:サーバ 証 明 書 および 中 間 証 明 書 、/etc/ssl/server.key:サーバ 証 明 書 に 対 応 する
秘 密 鍵
SSL/TLS 暗 号 設 定 ガイドライン - 71

B.1.2. lighttpd の 場 合
lighttpd の 設 定 ファイル(デフォルトの 場 合 、modules.conf と lighttpd.conf)での 設 定 例 を 以
下 に 示 す。
〔modules.conf での 設 定 〕
server.modules = (
( 中 略 )
"mod_setenv"
)
〔lighttpd.conf での 設 定 〕
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine = "enable"
( 中 略 )
証 明 書 と 鍵 の 設 定
ssl.pemfile = "/etc/ssl/serverkey_cert.pem"
ssl.ca-file = "/etc/ssl/ca.crt"
暗 号 スイート 設 定 。Appendix C.2 も 参 照 のこと
ssl.cipher-list = " 暗 号 スイート 設 定 "
プロトコルバージョン 設 定 。Appendix B.2.2 も 参 照 のこと
ssl.use-プロトコルバージョン = " 利 用 可 否 "
暗 号 スイート 順 序 サーバ 優 先 設 定
ssl.honor-cipher-order = "enable"
}
HTTP Strict Transport Security、Public Key Pinning の 設 定 をする 場 合 には、ここに 追 記
する。7.2 節 及 び Appendix B.4 以 降 を 参 照 のこと。なお、lighttpd では OCSP Stapling
の 設 定 はできない
B.1.3. nginx の 場 合
nginx の 設 定 ファイル(デフォルトの 場 合 、nginx.conf)での 設 定 例 を 以 下 に 示 す。
server {
listen 443 ssl;
SSL/TLS 暗 号 設 定 ガイドライン - 72

( 中 略 )
証 明 書 と 鍵 の 設 定
ssl_certificate /etc/ssl/chain.crt;
ssl_certificate_key /etc/ssl/server.key;
暗 号 スイート 設 定 。Appendix C.2 も 参 照 のこと
ssl_ciphers " 暗 号 スイート 設 定 ";
プロトコルバージョン 設 定 。Appendix B.2.3 も 参 照 のこと
ssl_protocols プロトコルバージョン 設 定 ;
暗 号 スイート 順 序 サーバ 優 先 設 定
ssl_prefer_server_ciphers on;
HTTP Strict Transport Security、OCSP Stapling、Public Key Pinning の 設 定 をする 場 合
には、ここに 追 記 する。7.2 節 及 び Appendix B.4 以 降 を 参 照 のこと
}
B.2.
プロトコルバージョンの 設 定 方 法 例
B.2.1. Apache の 場 合
Apache での 設 定 例 を 以 下 に 示 す。
• 高 セキュリティ 型
SSLProtocol TLSv1.2
• 推 奨 セキュリティ 型
SSLProtocol All -SSLv2 -SSLv3
• セキュリティ 例 外 型
SSLProtocol All -SSLv2
B.2.2. lighttpd の 場 合
lighttpd での 設 定 例 を 以 下 に 示 す。
SSL/TLS 暗 号 設 定 ガイドライン - 73

• 高 セキュリティ 型
ssl.use-tlsv1.1 = "disable"
ssl.use-tlsv1 = "disable"
ssl.use-sslv3 = "disable"
ssl.use-sslv2 = "disable"
• 推 奨 セキュリティ 型
ssl.use-sslv3 = "disable"
ssl.use-sslv2 = "disable"
• セキュリティ 例 外 型
ssl.use-sslv2 = "disable"
B.2.3. nginx の 場 合
nginx での 設 定 例 を 以 下 に 示 す。なお、TLS1.1 及 び TLS1.2 は、バージョンが 1.1.13 または 1.0.12
であり、かつ OpenSSL のバージョンが 1.0.1 以 上 の 時 に 利 用 できる。
• 高 セキュリティ 型 (Ver. 1.1.13/1.0.12 かつ OpenSSL ver. 1.0.1 以 上 )
ssl_protocols TLSv1.2;
• 推 奨 セキュリティ 型
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;(Ver. 1.1.13/1.0.12 かつ OpenSSL ver. 1.0.1 以 上 )
ssl_protocols TLSv1;
• セキュリティ 例 外 型
ssl_protocols TLSv1.2 TLSv1.1 TLSv1 SSLv3; (Ver. 1.1.13/1.0.12 かつ OpenSSL ver. 1.0.1 以 上 )
ssl_protocols TLSv1 SSLv3;
B.2.4. Microsoft IIS の 場 合
各 OS におけるプロトコルバージョンのサポート 状 況 は 以 下 の 通 りである。
TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0
Windows Server 2008 × × ○ ○ ○
Windows Vista × × ○ ○ ○
Windows Server 2008 R2( 以 降 ) ○ ○ ○ ○ ○
Windows 7 以 降 の Windows ○ ○ ○ ○ ○
凡 例 :○ サポートあり × サポートなし
SSL/TLS 暗 号 設 定 ガイドライン - 74

サポートされているプロトコルバージョンの 利 用 可 否 については、 以 下 の 設 定 例 に 従 い、レジ
ストリを 設 定 する。
参 考 情 報 :
特 定 の 暗 号 化 アルゴリズムおよび Schannel.dll のプロトコルの 使 用 を 制 限 する 方 法
https://support.microsoft.com/en-us/kb/245030
• 高 セキュリティ 型
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥Schannel¥
Protocols¥SSL 2.0¥Server
"DisabledByDefault"=dword:00000001
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥Schannel¥
Protocols¥SSL 3.0¥Server
"DisabledByDefault"=dword:00000001
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥Schannel¥
Protocols¥TLS 1.0¥Server
"DisabledByDefault"=dword:00000001
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥Schannel¥
Protocols¥TLS 1.1¥Server
"DisabledByDefault"=dword:00000001
• 推 奨 セキュリティ 型
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥Schannel¥
Protocols¥SSL 2.0¥Server
"DisabledByDefault"=dword:00000001
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥Schannel¥
Protocols¥SSL 3.0¥Server
"DisabledByDefault"=dword:00000001
• セキュリティ 例 外 型
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥Schannel¥
Protocols¥SSL 2.0¥Server
"DisabledByDefault"=dword:00000001
B.3.
鍵 パラメータファイルの 設 定 方 法 例
B.3.1. OpenSSL による DHE、ECDH、ECDHE 鍵 パラメータファイルの 生 成
OpenSSL コマンドにより、DHE 鍵 パラメータファイル(2048 ビット)を 生 成 するには 以 下 を
SSL/TLS 暗 号 設 定 ガイドライン - 75

実 行 する。
openssl dhparam -out dh2048.pem -outform PEM 2048
また、ECDH、ECDHE 鍵 パラメータファイル(256 ビット)は 以 下 のようにして 生 成 すること
ができる。
openssl ecparam -out prime256v1.pem -name prime256v1
B.3.2. Apache における DHE、ECDH、ECDHE 鍵 パラメータ 設 定
SSLCertificateFile は 設 定 ファイル 中 でいくつも 指 定 できるプロパティであり、 通 常 は PEM 形 式
の SSL サーバ 証 明 書 を 指 定 するためのものである。
Apache 2.4.7 以 降 では、SSLCertificateFile で 設 定 するファイルの 中 に、DHE、ECDH、ECDHE
の 鍵 長 を 示 すパラメータファイルを 明 示 的 に 含 めることができる。そのために、Appendix B.1.1
の 証 明 書 と 鍵 の 設 定 の 部 分 で 指 定 するファイル(Appendix B.1.1 の 場 合 、/etc/ssl/chain.crt)に 対 し
て、Appendix B.3.1 で 生 成 した 鍵 パラメータファイルを 追 記 する。
例 えば、linux 等 であれば 以 下 の 処 理 を 行 う。
• DHE 鍵 パラメータファイル(2048 ビット)の 指 定 例
cat dh2048.pem >> /etc/ssl/chain.crt
• ECDH、ECDHE 鍵 パラメータファイル(256 ビット)の 指 定 例
cat prime256v1.pem >> /etc/ssl/chain.crt
B.3.3. lighttpd における DHE、ECDH、ECDHE 鍵 パラメータ 設 定
lighttpd では、Appendix B.3.1 で 生 成 した 鍵 パラメータファイルについて、Appendix B.1.2 の 証
明 書 と 鍵 の 設 定 の 部 分 に、 以 下 のように 追 加 する。
• DHE の 鍵 パラメータファイル(2048 ビット)の 指 定 例
ssl.dh-file = "/etc/ssl/dh2048.pem"
• ECDH、ECDHE の 楕 円 曲 線 パラメータ(256 ビット)の 指 定 例
ssl.ec-curve = "prime256v1"
B.3.4. nginx における DHE、ECDH、ECDHE 鍵 パラメータ 設 定
nginx では、Appendix B.3.1 で 生 成 した 鍵 パラメータファイルについて、Appendix B.1.3 の 証 明
書 と 鍵 の 設 定 の 部 分 に、 以 下 のように 追 加 する。
SSL/TLS 暗 号 設 定 ガイドライン - 76

• DHE の 鍵 パラメータファイル(2048 ビット)の 指 定 例
ssl_dhparam /etc/ssl/dh2048.pem;
• ECDH、ECDHE の 楕 円 曲 線 パラメータ(256 ビット)の 指 定 例
ssl_ecdh_curve prime256v1;
B.4.
HTTP Strict Transport Security(HSTS)の 設 定 方 法 例
B.4.1. Apache の 場 合
HTTP ヘッダに HSTS の 情 報 を 追 加 するために、 設 定 ファイルに 以 下 の 記 述 を 追 加 する。なお、
max-age は 有 効 期 間 を 表 し、この 例 では 365 日 (31,536,000 秒 )の 有 効 期 間 を 設 定 することを 意 味
している。また、includeSubDomains がある 場 合 、サブドメインにも 適 用 される。
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
なお、HTTP の 場 合 に 強 制 的 に HTTPS にリダイレクトするためには、 中 の
RewriteRule、RewriteEngine の 設 定 を 以 下 のように 追 記 する。
( 中 略 )
ServerAlias *
RewriteEngine On
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
B.4.2. lighttpd の 場 合
HTTP ヘッダに HSTS の 情 報 を 追 加 するために、 設 定 ファイル(Appendix B.1.2 の 場 合 、
lighttpd.conf)に 以 下 の 記 述 を 追 加 する。なお、max-age は 有 効 期 間 を 表 し、この 例 では 365 日
(31,536,000 秒 )の 有 効 期 間 を 設 定 することを 意 味 している。また、includeSubDomains がある 場
合 、サブドメインにも 適 用 される。
setenv.add-response-header = (
"Strict-Transport-Security" => "max-age=31536000; includeSubDomains"
)
なお、HTTP の 場 合 に 強 制 的 に HTTPS にリダイレクトするためには、 設 定 ファイル(Appendix
B.1.2 の 場 合 、modules.conf と lighttpd.conf)に 以 下 のように 追 記 する。
SSL/TLS 暗 号 設 定 ガイドライン - 77

〔modules.conf での 設 定 〕
server.modules = (
( 中 略 )
"mod_redirect"
)
〔lighttpd.conf での 設 定 〕
$HTTP["scheme"] == "http" {
( 中 略 )
$HTTP["host"] =~ ".*" {
url.redirect = (".*" => "https://%0$0")
}
}
B.4.3. nginx の 場 合
HTTP ヘッダに HSTS の 情 報 を 追 加 するために、 設 定 ファイルに 以 下 の 記 述 を 追 加 する。なお、
max-age は 有 効 期 間 を 表 し、この 例 では 365 日 (31,536,000 秒 )の 有 効 期 間 を 設 定 することを 意 味
している。また、includeSubDomains がある 場 合 、サブドメインにも 適 用 される。
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
なお、HTTP の 場 合 に 強 制 的 に HTTPS にリダイレクトするためには、"listen 80;" 中 に、 以 下 の
ように 追 記 する。
server {
listen 80;
( 中 略 )
return 301 https://$hostname$request_uri;
}
B.4.4. Microsoft IIS の 場 合
IIS では、HTTP ヘッダに HSTS の 情 報 を 追 加 するために、 以 下 の 手 順 により 設 定 する。
1) 「IIS マネージャー」を 開 く
2) 「 機 能 ビュー」を 開 く
3) 「HTTP 応 答 ヘッダ」をダブルクリックする
4) 「 操 作 」のペインで「 追 加 」をクリックする
SSL/TLS 暗 号 設 定 ガイドライン - 78

5) 「 名 前 」「 値 」 の 箇 所 を 以 下 のように
設 定 する。 なお、max-age は 有 効 期 間 を 表 し、この 例
で は 365 日 ( 31,536,0000 秒 )の 有 効 期 間 を 設 定 することを 意 味 している
。また、
includeSubDomains がある場 合 、サブドメインにも 適 用 される
名 前 :Strict-Transport-Security
値 :max-age= =31536000; includeSubDomains
6) 「OK」をクリックする。
B.5.
OCSP Stapling の 設 定 方 法 例
B.5.1. Apache の 場 合
OCSP stapling を 有 効 にするために、 設 定 ファイルに
以 下 の 記 述 を 追 加 する。
なお、SSLStaplingCache の stapling_cachee はキャッシュサイズを
表 し、このの 例 では 128,000 バイ
トを 設 定 することを 意 味 している。また、
の 前 に 記 載 すること。
SSLStaplingCache
shmcb:/tmp/stapling_cache(128000)
SSL/TLS 暗 号 設 定 ガイドライン -
79

( 中 略 )
SSLCACertificateFile /etc/ssl/ca-certs.pem
SSLUseStapling on
B.5.2. nginx の 場 合
OCSP stapling を 有 効 にするために、 設 定 ファイルに 以 下 の 記 述 を 追 加 する。
server {
( 中 略 )
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ca-certs.pem;
}
B.5.3. Microsoft IIS の 場 合
Windows Server 2008 以 降 の Windows では、デフォルトで OCSP Stapling が 設 定 されている。
B.6.
Public Key Pinning の 設 定 方 法 例
Public Key Pinning で 使 用 される HTTP ヘッダの 属 性 名 は"Public-Key-Pins"であり、ヘッダの 例
は 以 下 のようになる。
Public-Key-Pins 'pin-sha256="サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値 ";
pin-sha256=" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値 "; max-age= 有 効 期 間 ;
includeSubDomains'
Public-Key-Pins 'pin-sha1="サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base64 値 "; pin-s
ha1=" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base64 値 "; max-age= 有 効 期 間 ; includeSu
bDomains'
• エンドエンティティ(SSL サーバ 証 明 書 )から、 最 上 位 の 中 間 証 明 書 まで 全 てを 列 挙 する
• 公 開 鍵 情 報 のハッシュ 値 を 計 算 するハッシュ 関 数 は 複 数 指 定 することができ、それぞれヘ
ッダを 追 加 すればよい。 上 記 の 例 では、SHA-256 と SHA-1 の 両 方 を 指 定 することになる。
• max-age により 有 効 期 間 ( 秒 )を 指 定 する。
• includeSubDomains がある 場 合 、サブドメインにも 適 用 される
SSL/TLS 暗 号 設 定 ガイドライン - 80

〔 具 体 的 な 表 記 例 〕
Public-Key-Pins 'pin-sha256="QtXc8+scL7K6HiPksQ8mqIyY08Xdc4Z5raHT+xSh9/s="; pin-sha256
="kb6xLprt35abNnSn74my4Dkfya9arbk5zN5a60YzuqE="; max-age=3000; includeSubDomains'
Public-Key-Pins 'pin-sha1="FhxvMPhD7Q+byiiwygLO0mL7L70="; pin-sha1="KqqJgAYLy9ogXOW
ETcR36ioKf20="; max-age=3000; includeSubDomains'
この 例 では、あるサーバ 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値 が"QtXc8+"か
ら 始 まる 値 であり、 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値 が"kb6xLp"から
始 まる 値 であることを 意 味 する。 同 様 に、"FhxvM"、"KqqJgA"から 始 まる 値 はそれぞれの SHA-1
ハッシュ 値 の Base64 値 である。
また、この 場 合 の max-age は 50 分 (3,000 秒 )の 有 効 期 間 を 意 味 している。
なお、ハッシュ 値 の Base64 値 を 簡 単 に 計 算 する 方 法 はいくつかある。
例 えば、OpenSSL を 利 用 する 方 法 や、PEM 形 式 のサーバ 証 明 書 を 入 力 して Public-Key-Pins ヘ
ッダを 自 動 作 成 するサイト 40 がある。
〔OpenSSL を 利 用 する 方 法 〕
PEM 形 式 のあるサーバ 証 明 書 (certificate.pem)の SHA-256 ハッシュ 値 の Base64 値 を 求 める
場 合 は、 以 下 のように 計 算 する
openssl x509 -noout -in certificate.pem -pubkey | openssl asn1parse -noout -inform pem -out pu
blic.key;
openssl dgst -sha256 -binary public.key | openssl enc -base64
B.6.1. Apache の 場 合
B.6 の 表 記 に 従 い、mod_headers モジュールを 有 効 にし、 以 下 の 設 定 を 追 加 する。この 例 では
SHA-256 と SHA-1 の 両 方 のヘッダを 指 定 することを 意 味 している。
Header add Public-Key-Pins 'pin-sha256="サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の
Base64 値 "; pin-sha256=" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値 "; max-ag
e= 有 効 期 間 '
Header add Public-Key-Pins 'pin-sha1="サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base6
4 値 "; pin-sha1=" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base64 値 "; max-age= 有 効 期 間
'
ちなみに、mod_headers モジュールを 有 効 にするためには、httpd.conf において
40 https://projects.dm.id.lv/s/pkp-online/calculator.html
SSL/TLS 暗 号 設 定 ガイドライン - 81

LoadModule headers_module modules/mod_headers.so
を 設 定 する。
41
B.6.2. lighttpd での 設 定 例
B.6 の 表 記 に 従 い、 設 定 ファイルにおいて、 以 下 の 設 定 を 追 加 する。この 例 では SHA-256 と
SHA-1 の 両 方 のヘッダを 指 定 することを 意 味 している。
setenv.add-response-header = (
"Public-Key-Pins" => "pin-sha256=¥"サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Bas
e64 値 ¥"; pin-sha256=¥" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値 ¥"; maxage=
有 効 期 間 ",
"Public-Key-Pins" => "pin-sha1=¥"サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base64
値 ¥"; pin-sha1=¥" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base64 値 ¥"; max-age= 有 効
期 間 "
)
B.6.3. nginx の 場 合
B.6 の 表 記 に 従 い、 設 定 ファイルにおいて、 以 下 の 設 定 を 追 加 する。この 例 では SHA-256 と
SHA-1 の 両 方 のヘッダを 指 定 することを 意 味 している。
add_header Public-Key-Pins 'pin-sha256="サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の B
ase64 値 "; pin-sha256=" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値 "; max-age=
有 効 期 間 ';
add_header Public-Key-Pins 'pin-sha1="サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base6
4 値 "; pin-sha1=" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base64 値 "; max-age= 有 効 期 間
';
B.6.4. Microsoft IIS の 場 合
IIS では、B.6 の 表 記 に 従 い、 以 下 の 手 順 により 設 定 する。
1) 「IIS マネージャー」を 開 く
2) 「 機 能 ビュー」を 開 く
3) 「HTTP 応 答 ヘッダ」をダブルクリックする
4) 「 操 作 」のペインで「 追 加 」をクリックする
41 HSTS と Public Key Pinning を 同 時 に 設 定 する 場 合 には、 一 つの setenv.add-response-header 内 に
両 方 の 設 定 を 追 加 すること
SSL/TLS 暗 号 設 定 ガイドライン - 82

5) B.6 の 表 記 に 従 い、「 名 前 」「 値 」の 箇 所 に 以 下 のように 設 定 する。この 例 では SHA-256 と
SHA-1 の 両 方 のヘッダを 指 定 することを 意 味 している。
名 前 :Public-Key-Pinning
値 : pin-sha256="サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値 ",
pin-sha256=" 中 間 証 明 書 の 公 開 鍵 情 報 の SHA-256 ハッシュ 値 の Base64 値
",pin-sha1="サーバ 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base64 値 ",pin-sha1="
中 間 証 明 書 の 公 開 鍵 情 報 の SHA-1 ハッシュ 値 の Base64 値 ",max-age= 有 効 期 間
6) 「OK」をクリックする。
SSL/TLS 暗 号 設 定 ガイドライン - 83

Appendix C: 暗 号 スイートの
設 定 例
本 Appendix では、 暗 号 スイー ートの 設 定 を 行 う 上 での
参 考 情 報 として、 設 定 方 法 例 を 記 載 する。
なお、 利 用 するバー ージョンやディストリビューションの 違 いにより、 実 装 されている 暗 号 スイ
ートの 種 類 や 設 定 方 法 が 異 なる 場 合 があることに 留 意 すること。 正 式 な 取 扱 説 明 書 やマニュアル
を 参 照 するとともに、
一 参 考 資 料 として 利 用 されたい。
C.1.
Windows
での 設 定 例
42
1. コマンドプロンプトで gpedit.msc と 入 力 し、Enterr を 押 してグループポリシーオブジェクトエ
ディタを 起 動 する。
2. [コンピューター
ーの 構 成 ]>[ 管 理 用 テンプレー ト]>[ネットワーク]>[SSL 構 成 設 定 ]
の 順 に 展 開 する。
3. [SSLL 構 成 設 定 ] で[SSL 暗 号 (「SSLL 暗 号 化 スイート」と 表 記 される場 合 もある)の 順 序 ]
をダブルクリックする。
4. [SSLL 暗 号 の 順 序 ]ウィンドウで、[ 有 効 ]をクリックする。
5. ウィンドウで、[S
SSL 暗 号 ]フ フィールドの
内 容 を、 設 定 したい 暗 号 リストのの 内 容 と 置 き 換 える。
42
Windows
Server 2008, 2008 R2, 2012, 20122 R2 については、GUI
で 暗 号 スイートやプロトコルバ
ージョンを
設 定 できるフリーウェアを NARTAC IIS Crypto が 公 開 している
https://www.nartac.com/Products/IISCrypto/
SSL/TLS 暗 号 設 定 ガイドライン - 84

なお、 暗 号 リストは「,」で 暗 号 スイートを 連 結 して 1 行 で 記 述 し、 空 白 や 改 行 を 含 めない。
優 先 順 位 は 記 述 した 順 番 で 設 定 される。
• 高 セキュリティ 型 の 設 定 例 ( 楕 円 曲 線 暗 号 あり)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AE
S_128_GCM_SHA256_P256
• 推 奨 セキュリティ 型 の 設 定 例 ( 楕 円 曲 線 暗 号 あり)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AE
S_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_EC
DHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_S
HA_P256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,T
LS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES
_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECD
HE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SH
A_P256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA
• セキュリティ 例 外 型 の 設 定 例 ( 楕 円 曲 線 暗 号 あり)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AE
S_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_EC
DHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_S
HA_P256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,T
LS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES
_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECD
HE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SH
A_P256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS
_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA
6. [ 適 用 (A)]>[OK]をクリックする。
7. グループポリシーオブジェクトエディタを 閉 じ、システムを 再 起 動 する。
C.2.
OpenSSL 系 での 設 定 例
C.2.1. Apache, lighttpd, nginx の 場 合
Apache、lighttpd、nginx での 暗 号 スイートの 設 定 においては、C.2.2 の OpenSSL での 暗 号 スイ
ート 設 定 例 に 従 った 設 定 を 行 う。
• Apache の 場 合 の 記 述
C.2.2 に 従 い、VirtualHost 中 の SSLCipherSuite の 設 定 を 以 下 のように 追 記 する。
SSLCipherSuite " 暗 号 スイート 設 定 例 "
SSL/TLS 暗 号 設 定 ガイドライン - 85

• lighttpd の 場 合 の 記 述
C.2.2 に 従 い、$SERVER 中 の ssl.cipher-list の 設 定 を 以 下 のように 追 記 する。
ssl.cipher-list = " 暗 号 スイート 設 定 例 "
• nginx
C.2.2 に 従 い、server 中 の ssl_ciphers の 設 定 を 以 下 のように 追 記 する。
ssl_ciphers " 暗 号 スイート 設 定 例 ";
C.2.2. OpenSSL 系 での 暗 号 スイートの 設 定 例
OpenSSL 系 では、6.5 節 に 記 載 する 暗 号 スイート 名 に 対 応 する 独 自 の 表 記 を 利 用 する( 表 17
参 照 )。
〔SSLCipherSuite " 暗 号 スイート 設 定 例 "の 表 記 方 法 〕
例 えば、 高 セキュリティ 型 の 設 定 例 ( 基 本 )なら
SSLCipherSuite "DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256"
と 表 記 する。
なお、OpenSSL では 暗 号 スイートの 設 定 をパターンによる 表 記 43 で 簡 略 化 して 記 載 することが
できる。ただし、パターンによる 設 定 は、6.5 節 に 記 載 する 詳 細 要 求 設 定 に 従 った 設 定 を 行 うこ
とが 難 しいため、 本 ガイドラインでは 取 り 上 げない。
• 高 セキュリティ 型 の 設 定 例 ( 基 本 44 )
DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
• 高 セキュリティ 型 の 設 定 例 ( 楕 円 曲 線 暗 号 あり 45 )
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES2
56-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA25
6:DHE-RSA-AES128-GCM-SHA256
43 「ECDHE+AESGCM:DHE+CAMELLIA:DHE+AES:!DSS:!DH:!PSK:!SRP」のような 表 記 をパター
ンによる 表 記 という
44 「DHE+AESGCM:!DSS:!PSK:!SRP」での 設 定 パターンによる 暗 号 スイートを 6.5.1 節 の 優 先 順
位 に 合 わせたもの
45 「ECDHE+AESGCM:EDH+AESGCM:!DSS:!PSK:!SRP」での 設 定 パターンによる 暗 号 スイートを
6.5.1 節 の 優 先 順 位 に 合 わせたもの
SSL/TLS 暗 号 設 定 ガイドライン - 86

• 推 奨 セキュリティ 型 の 設 定 例 ( 基 本 46 )
DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA128-SHA
:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:CAMELLIA128-SHA:AES1
28-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-CAMELLIA
256-SHA:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SH
A:AES256-SHA
• 推 奨 セキュリティ 型 の 設 定 例 ( 楕 円 曲 線 暗 号 あり 47 )
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES1
28-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES
128-SHA:AES128-GCM-SHA256:AES128-SHA256:CAMELLIA128-SHA:AES128-SHA:ECDH-E
CDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-G
CM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RS
A-AES256-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES256-SHA:AES256-GCM-S
HA384:AES256-SHA256:CAMELLIA256-SHA:AES256-SHA:ECDH-ECDSA-AES256-GCM-SH
A384:ECDH-RSA-AES256-GCM-SHA384
• セキュリティ 例 外 型 の 設 定 例 ( 基 本 48 )
DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA128-SHA
:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:CAMELLIA128-SHA:AES1
28-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-CAMELLIA
256-SHA:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SH
A:AES256-SHA:RC4-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA
46
「DHE+AESGCM:RSA+AESGCM:DHE+CAMELLIA:DHE+AES:RSA+CAMELLIA:RSA+AES:!DSS:!
PSK:!SRP」での 設 定 パターンによる 暗 号 スイートを 6.5.2 節 の 優 先 順 位 に 合 わせたもの
47
「ECDHE+AESGCM:DHE+AESGCM:RSA+AESGCM:DHE+CAMELLIA:DHE+AES:RSA+CAMELLI
A:RSA+AES:ECDH+AESGCM:!DSS:!PSK:!SRP」での 設 定 パターンによる 暗 号 スイートを 6.5.2 節
の 優 先 順 位 に 合 わせたもの
48
「DHE+AESGCM:RSA+AESGCM:DHE+CAMELLIA:DHE+AES:RSA+CAMELLIA:RSA+AES:RC4-S
HA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!DSS:!PSK:!SRP」での 設 定 パターンによる 暗 号 ス
イートを 6.5.3 節 の 優 先 順 位 に 合 わせたもの
SSL/TLS 暗 号 設 定 ガイドライン - 87

表 17 代 表 的 な 暗 号 スイートの 対 比 表
6.5 節 に 記 載 する 暗 号 スイート 名 OpenSSL での 暗 号 スイート 名 表 記
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE-RSA-AES256-GCM-SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
DHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
DHE-RSA-AES128-GCM-SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
DHE-RSA-AES256-SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
DHE-RSA-AES128-SHA256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE-RSA-CAMELLIA256-SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE-RSA-CAMELLIA128-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
DHE-RSA-AES256-SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
DHE-RSA-AES128-SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
AES256-GCM-SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
AES128-GCM-SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
AES256-SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
AES128-SHA256
TLS_RSA_WITH_CAMELLIA_256_SHA
CAMELLIA256-SHA
TLS_RSA_WITH_CAMELLIA_128_SHA
CAMELLIA128-SHA
TLS_RSA_WITH_AES_256_CBC_SHA
AES256-SHA
TLS_RSA_WITH_AES_128_CBC_SHA
AES128-SHA
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 ECDH-RSA-AES256-GCM-SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 ECDH-ECDSA-AES256-GCM-SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 ECDH-ECDSA-AES128-GCM-SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 ECDH-RSA-AES128-GCM-SHA256
TLS_RSA_WITH_RC4_128_SHA
RC4-SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
EDH-RSA-DES-CBC3-SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
DES-CBC3-SHA
SSL/TLS 暗 号 設 定 ガイドライン - 88

Appendix D:ルート CA 証 明 書 の 取 り 扱 い
D.1.
ルート CA 証 明 書 の 暗 号 アルゴリズムおよび 鍵 長 の 確 認 方 法
主 要 な 認 証 事 業 者 のルート CA 証 明 書 の 暗 号 アルゴリズムおよび 鍵 長 を 別 表 に 掲 載 する。
ただし、 事 業 者 によってはサーバ 証 明 書 発 行 サービスを 複 数 展 開 しているケースがあり、サー
ビスによってルート CA が 異 なる 場 合 があるので、どのサービスがどのルート CA の 下 で 提 供 さ
れているのかは、 各 事 業 者 に 確 認 する 必 要 がある。
なお、サーバ 証 明 書 を 発 行 するサービスから 発 行 された 既 存 のサーバ 証 明 書 を 利 用 したサイト、
あるいはテストサイトなどの URL がわかっている 場 合 には、 当 該 URL にアクセスして、 以 下 の
ような 手 順 を 経 ることで、ルート CA の 公 開 鍵 暗 号 アルゴリズムおよび 鍵 長 を 確 認 することが 可
能 である。
【Internet Explorer 11 で EV 証 明 書 のサイトにアクセスする 場 合 】
1 南 京 錠 マーク 横 のサイト 運 営 組 織 の 表 示 をクリックする
2 「 証 明 書 の 表 示 」をクリックする
3 「 証 明 のパス」タブをクリックする
4 一 番 上 に 表 示 されている 証 明 書 (これがルート CA 証 明 書 に 当 たる)を 選 択 し、「 証 明 書 の
表 示 」をクリックする
5 「 詳 細 」タブをクリックする
6 スクロールバーを 一 番 下 までスクロールさせ、「 公 開 キー」フィールドに 表 示 されている 値
(RSA (2048 Bits))を 確 認 する
この 例 では、 暗 号 アルゴリズムが RSA、 鍵 長 が 2048 ビットであることがわかる
SSL/TLS 暗 号 設 定 ガイドライン - 89

1
3
2
4
5
6
SSL/TLS 暗 号 設 定 ガイドライン - 90

D.2.
Active Directory を 利 用 したプライベートルート CA 証 明 書 の 自 動
更 新
SSL/TLS 暗 号 設 定 ガイドライン -
91

SSL/TLS 暗 号 設 定 ガイドライン
~ 安 全 なウェブサイトのために( 暗 号 設 定 対 策 編 )~
【 作 成 】
CRYPTREC とは、 総 務 省 ・ 経 済 産 業 省 ・NICT・IPA が 実 施 しているる 暗 号 技 術 評 価
プロジェクトのこと。 暗 号 技 術 の 専 門 家 により 安 全 性 と 実 装 性 に 優 れると 判 断 さ
れた CRYPTREC 暗 号 リストを 作 成 ・ 公 表 している。
【 発 行 】
独 立 行 政 法 人 情 報 処 理 推 進 機 構
セキュリティセンター
2015
年 5 月 12 日 第 1 版
SSL/TLS 暗 号 設 定 ガイドライン -
92