Ver. 2.0
SSL/TLS 暗号設定
ガイドライン
～安全なウェブサイトのために（暗号設定対策編）～
作成
発行
SSL/TLS 暗号設定ガイドライン － 1 本書は、以下の URL からもダウンロードできます。
「SSL/TLS 暗号設定ガイドライン」
(IPA) https://www.ipa.go.jp/security/vuln/ssl_crypt_config.html (CRYPTREC) http://www.cryptrec.go.jp/
SSL/TLS 暗号設定ガイドライン － 2
CRYPTREC GL-3001-2.0
SSL/TLS
暗号設定ガイドライン
平成 30 年 5 月 独立行政法人 情報処理推進機構 国立研究開発法人 情報通信研究機構SSL/TLS 暗号設定ガイドライン － 3
目次
1. はじめに ... 7 1.1 本書の内容及び位置付け ... 7 1.2 本書が対象とする読者 ... 7 1.3 ガイドラインの検討体制 ... 8 1.3.1 Version 2.0 における検討体制 ... 8 1.3.2 Version 1.x における検討体制 ... 9 2. 本ガイドラインの理解を助ける技術的な基礎知識 ... 10 2.1 SSL/TLS の概要 ... 10 2.1.1 SSL/TLS の歴史 ... 10 2.1.2 プロトコル概要 ... 12 2.1.3 TLS1.3 の概要 ... 13 2.1.4 TLS プロトコルの最新動向 ... 16 2.2 暗号アルゴリズムの安全性 ... 17 2.2.1 CRYPTREC 暗号リスト ... 17 2.2.2 異なる暗号アルゴリズムにおける安全性の見方 ... 18 PART I： サーバ構築における設定要求項目について ... 20 3. 設定基準の概要 ... 21 3.1 実現すべき設定基準の考え方 ... 21 3.2 要求設定の概要 ... 23 3.3 チェックリスト ... 24 4. プロトコルバージョンの設定 ... 26 4.1 プロトコルバージョンについての要求設定 ... 26 4.2 プロトコルバージョンごとの安全性の違い ... 27 【コラム①】SSL/TLS から TLS へ －プロトコルとしての本格的な世代交代へ－ ... 28 5. サーバ証明書の設定 ... 30 5.1 サーバ証明書についての要求設定 ... 30 5.2 サーバ証明書に記載されている情報 ... 33 5.3 サーバ証明書で利用可能な候補となる暗号アルゴリズム ... 34 5.4 サーバ証明書で考慮すべきこと ... 35 5.4.1 信頼できないサーバ証明書の利用は止める ... 35 5.4.2 ルート CA 証明書の安易な手動インストールは避ける ... 35 5.4.3 サーバ証明書で利用すべき鍵長 ... 36 5.4.4 サーバ証明書を発行・更新する際に新しい鍵情報を生成する重要性 ... 36【コラム②】DNS の CAA (Certification Authority Authorization) リソースレコード ... 38
6. 暗号スイートの設定 ... 39
6.1 暗号スイートについての要求設定 ... 39
6.2 暗号スイートで利用可能な候補となる暗号アルゴリズム ... 41
SSL/TLS 暗号設定ガイドライン － 4
6.3.1 秘密鍵漏えい時の影響範囲を狭める手法の採用（Perfect Forward Secrecy の重要性）
42 6.3.2 鍵交換で利用すべき鍵長 ... 43 6.3.3 DHE/ECDHE での鍵長の設定状況についての注意 ... 43 6.4 暗号スイートについての実装状況 ... 46 6.5 暗号スイートについての詳細な要求設定 ... 46 6.5.1 高セキュリティ型での暗号スイートの詳細要求設定 ... 46 6.5.2 推奨セキュリティ型での暗号スイートの詳細要求設定 ... 47 6.5.3 セキュリティ例外型での暗号スイートの詳細要求設定 ... 50 7. SSL/TLS を安全に使うために考慮すべきこと ... 51 7.1 サーバ証明書の作成・管理について注意すべきこと ... 51 7.1.1 サーバ証明書での脆弱な鍵ペアの使用の回避 ... 51 7.1.2 推奨されるサーバ証明書の種類 ... 51 7.1.3 サーバ証明書の有効期限 ... 53 7.1.4 サーバ鍵の適切な管理 ... 53 7.1.5 複数サーバに同一のサーバ証明書を利用する場合の注意 ... 54 7.1.6 ルート CA 証明書 ... 54 7.2 さらに安全性を高めるために ... 54
7.2.1 HTTP Strict Transport Security（HSTS）の設定有効化 ... 54
7.2.2 リネゴシエーションの脆弱性への対策 ... 55
7.2.3 圧縮機能を利用した実装攻撃への対策 ... 56
7.2.4 OCSP Stapling の設定有効化 ... 57
7.2.5 Public Key Pinning の設定有効化 ... 58
【コラム③】完全HTTPS 化の落とし穴 ... 59 PART II： ブラウザ＆リモートアクセスの利用について ... 61 8. ブラウザを利用する際に注意すべきポイント ... 62 8.1 本ガイドラインが対象とするブラウザ ... 62 8.1.1 対象とするプラットフォーム ... 62 8.1.2 対象とするブラウザのバージョン ... 62 8.2 設定に関する確認項目 ... 63 8.2.1 基本原則 ... 63 8.2.2 設定項目 ... 63 8.3 ブラウザ利用時の注意点 ... 65 8.3.1 SHA-1 を利用するサーバ証明書の警告表示 ... 65 9. その他のトピック ... 66 9.1 リモートアクセス VPN over SSL （いわゆる SSL-VPN） ... 66 Appendix： 付録 ... 68 Appendix A：チェックリスト ... 69 A.1. チェックリストの利用方法 ... 69
SSL/TLS 暗号設定ガイドライン － 5 A.2. 高セキュリティ型のチェックリスト ... 70 A.3. 推奨セキュリティ型のチェックリスト ... 71 A.4. セキュリティ例外型のチェックリスト ... 74 Appendix B：サーバ設定編 ... 77 Appendix C：暗号スイートの設定例 ... 77 Appendix D：ルート CA 証明書の取り扱い ... 78 D.1. ルート CA 証明書の暗号アルゴリズムおよび鍵長の確認方法 ... 78 D.2. Active Directory を利用したプライベートルート CA 証明書の自動更新 ... 80
SSL/TLS 暗号設定ガイドライン － 6 【修正履歴】 修正日 修正内容 2018.5.8 (Ver.2.0) 最新動向を踏まえ、「セキュリティ例外型」を中心とした設定基準の見 直しを実施。 最新データへの更新を実施。 2015.8.3 (Ver.1.1) Appendix B.6 での誤記を修正
SSL/TLS 暗号設定ガイドライン － 7
1. はじめに
1.1 本書の内容及び位置付け
本ガイドラインは、2018 年 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 暗号設定ガイドライン － 8 ーバの構築を発注するシステム担当者としている。 一部の内容については、ブラウザを使う一般利用者への注意喚起も対象とする。
1.3 ガイドラインの検討体制
1.3.1 Version 2.0 における検討体制
本ガイドライン Version 2.0 への改訂にあたっては、2017 年度 CRYPTREC 暗号技術活用委員会 において、2015 年以降の動向調査を実施し、その結果を踏まえて本ガイドライン Version 1.x の 記述を修正・追記・削除すべきかの検討を行った。 表 1 暗号技術活用委員会の構成（2018 年 3 月時点） 委員長 松本 勉 横浜国立大学 大学院環境情報研究院 教授 委員 上原 哲太郎 立命館大学 情報理工学部 情報システム学科 教授 委員 垣内 由梨香 日本マイクロソフト株式会社 セキュリティレスポンスチーム セキュリティプログラムマネージャー 委員 菊池 浩明 明治大学 総合数理学部 先端メディアサイエンス学科 教授 委員 清藤 武暢 日本銀行金融研究所 情報技術研究センター 委員 須賀 祐治 株式会社インターネットイニシアティブ セキュリティ本部セキュリティ情報統括室 シニアエンジニア 委員 杉尾 信行 株式会社 NTT ドコモ サービスイノベーション部 委員 手塚 悟 慶應義塾大学 大学院政策・メディア研究科 特任教授 委員 寺村 亮一 NRI セキュアテクノロジーズ株式会社 サイバーセキュリティ事業開発部 主任 委員 松本 泰 セコム株式会社 IS 研究所 コミュニケーションプラットフォームディビジョン マネージャー 委員 三澤 学 三菱電機株式会社 情報技術総合研究所 情報ネットワーク基盤技術部 車載セキュリティグループ 主席研究員 委員 満塩 尚史 内閣官房 IT 総合戦略室 政府 CIO 補佐官 委員 山岸 篤弘 一般財団法人日本情報経済社会推進協会 電子署名・認証センター 主席研究員 委員 山口 利恵 東京大学 大学院情報理工学系研究科 ソーシャル ICT 研究センター 特任准教授 委員 渡邊 創 国立研究開発法人産業技術総合研究所 情報・人間工学領域 研究戦略部 研究企画室 研究企画室長 執筆 とりまとめ 神田 雅透 情報処理推進機構 技術本部 セキュリティセンターSSL/TLS 暗号設定ガイドライン － 9
1.3.2 Version 1.x における検討体制
本ガイドライン Version 1.x は、CRYPTREC 暗号技術活用委員会の配下に設置された運用ガイド ラインワーキンググループに参加する委員の知見を集約したベストプラクティスとして作成され たものであり、暗号技術活用委員会の承認を得て発行されたものである。 運用ガイドラインワーキンググループは表 2 のメンバーにより構成されている。 表 2 運用ガイドラインワーキンググループの構成（2015 年 3 月時点） 主査 菊池 浩明 明治大学 総合数理学部 先端メディアサイエンス学科 教授 委員 阿部 貴 株式会社シマンテック SSL 製品本部 SSL プロダクトマーケティング部 マネージャー 委員 漆嶌 賢二 富士ゼロックス株式会社 CS 品質本部 品質保証部 マネージャー 委員 及川 卓也 グーグル株式会社 エンジニアリング シニアエンジニアリングマネージャー 委員 加藤 誠 一般社団法人 Mozilla Japan 技術部 テクニカルアドバイザ 委員 佐藤 直之 株式会社イノベーションプラス Director 委員 島岡 政基 セコム株式会社 IS 研究所 コミュニケーションプラットフォームディビジョン 暗号・認証基盤グループ 主任研究員 委員 須賀 祐治 株式会社インターネットイニシアティブ サービスオペレーション本部 セキュリティ情報統括室 シニアエンジニア 委員 高木 浩光 独立行政法人産業技術総合研究所 セキュアシステム研究部門 主任研究員 委員 村木 由梨香 日本マイクロソフト株式会社 セキュリティレスポンスチーム セキュリティプログラムマネージャー 委員 山口 利恵 東京大学 大学院 情報理工学系研究科 ソーシャル ICT 研究センター 特任准教授 執筆 とりまとめ 神田 雅透 情報処理推進機構 技術本部 セキュリティセンターSSL/TLS 暗号設定ガイドライン － 10
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]モードの利用が可能になった。 表 3 に SSL/TLS のバージョンの概要をまとめる。最近では、IETF において、TLS1.3 の規格化 の議論が進んでいる。 なお、SSL/TLS に対する攻撃方法の技術的な詳細については、「CRYPTREC 暗号技術ガイドラ イン（SSL/TLS における近年の攻撃への対応状況）[ 6]」を参照されたい。 表 3 SSL/TLS のバージョン概要 バージョン 概要 SSL2.0 （1994） いくつかの脆弱性が発見されており、なかでも「ダウングレード攻撃（最弱の アルゴリズムを強制的に使わせることができる）」と「バージョンロールバック 攻撃（SSL2.0 を強制的に使わせることができる）」は致命的な脆弱性といえる SSL2.0 は利用すべきではなく、2005 年頃以降に出荷されているサーバやブラウ ザでは SSL2.0 は初期状態で利用不可となっている
[1] CBC: Cipher 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
SSL/TLS 暗号設定ガイドライン － 11 バージョン 概要 SSL3.0 （RFC6101） （1995） SSL2.0 での脆弱性に対処したバージョン 2014 年 10 月に POODLE[ 7]攻撃が発表されたことにより特定の環境下での CBC モードの利用は危険であることが認識されている。POODLE 攻撃は、SSL3.0 に おけるパディングチェックの仕方の脆弱性に起因しているため、この攻撃に対 する回避策は現在のところ存在していない POODLE 攻撃の発表を受け、2018 年 3 月時点での主流の最新版ブラウザで SSL3.0 は初期状態で利用不可となっている TLS1.0 （RFC2246） （1999） 2018 年 3 月時点での SSL Pulse の調査結果[ 8]によれば、約 12 万の主要なサイト について TLS1.0 が利用できるのは約 88% ブロック暗号を CBC モードで利用した時の脆弱性を利用した攻撃（BEAST 攻 撃など）が広く知られているが、容易な攻撃回避策が存在し、すでにセキュリ ティパッチも提供されている。また、SSL3.0 で問題となった POODLE 攻撃は、 プロトコルの仕様上、TLS1.0 には適用できない 暗号スイートとして、より安全なブロック暗号の AES と Camellia、並びに公開 鍵暗号・署名に楕円曲線暗号が利用できるようになった 秘密鍵の生成などに擬似乱数関数を採用 MAC の計算方法を HMAC に変更 TLS1.1 （RFC4346） （2006） ブロック暗号を CBC モードで利用した時の脆弱性を利用した攻撃（BEAST 攻 撃等）への対策を予め仕様に組み入れるなど、TLS1.0 の安全性強化を図ってい る 実装に関 しては 、規格 化された 年が TLS1.2 とあまり 変わら なかっ たため、 TLS1.1 と TLS1.2 は同時に実装されるケースも多く、2018 年 3 月時点での SSL Pulse の調査結果[8]によれば約 12 万の主要なサイトについて TLS1.1 が利用でき るのは約 85% TLS1.2 （RFC5246） （2008） 暗号スイートとして、より安全なハッシュ関数 SHA-256 と SHA-384、CBC モー ドより安全な認証付き秘匿モード（GCM、CCM）が利用できるようになった。 特に、認証付き秘匿モードでは、利用するブロック暗号が同じであっても、CBC モードの脆弱性を利用した攻撃（BEAST 攻撃等）がそもそも適用できない 必須の暗号スイートを TLS_RSA_WITH_AES_128_CBC_SHA に変更 IDEA と DES を使う暗号スイートを削除 擬似乱数関数の構成を MD5/SHA-1 ベースから SHA-256 ベースに変更 2018 年 3 月時点での SSL Pulse の調査結果[8]によれば約 12 万の主要なサイトに ついて TLS1.2 が利用できるのは約 91%
[7] POODLE: Padding Oracle On Downgraded Legacy Encryption [8] https://www.ssllabs.com/ssl-pulse/
SSL/TLS 暗号設定ガイドライン － 12 バージョン 概要
TLS1.3 （draft28）
共通鍵暗号は認証暗号（AEAD: Authenticated Encryption with Associated Data）の み採用した結果、AES-GCM、AES-CCM、ChaCha20-Poly1305 のみが規定された。 このうち、AES-GCM が必須になった 鍵交換は、DHE、ECDHE、PSK のみが規定され、ECDHE が必須になった 署名は、RSA-PSS、RSASSA-PKCS1-v1_5、ECDSA が必須になった ハッシュ関数は SHA-256 以上が規定された。このうち、SHA-256 が必須になっ た 楕円曲線は secp256r1 (NIST P-256)が必須になった
ハンドシェイク性能の向上のため、1-RTT、0-RTT（Round Trip Time）になるよ うにシーケンスが簡素化された ハンドシェイクのデータを暗号化して保護した TLS1.2 互換に配慮し、ClientHello、ServerHello、ChangeCipherSpec が規定された まだ draft であるが、サーバやブラウザで実装が始まっている
2.1.2 プロトコル概要
SSL/TLS はセッション層に位置するセキュアプロトコルで、通信の暗号化、データ完全性の確 保、サーバ（場合によりクライアント）の認証を行うことができる。セッション層に位置するこ とで、アプリケーション層ごとにセキュリティ確保のための仕組みを実装する必要がなく、HTTP、 SMTP、POP など様々なプロトコルの下位に位置して、上記の機能を提供することができる。 SSL/TLS では、暗号通信を始めるに先立って、ハンドシェイクが実行される（図 1 参照）。 ハンドシェイクでは、①ブラウザ（クライアント）とサーバが暗号通信するために利用する暗 号アルゴリズムとプロトコルバージョンを決定し、②サーバ証明書によってサーバの認証を行い、 ③そのセッションで利用するセッション鍵を共有する、までの一連の動作を行う。 その際、SSL/TLS では相互接続性の確保を優先してきたため、一般には複数の暗号アルゴリズ ムとプロトコルバージョンが実装されている。結果として、暗号通信における安全性強度は、ハ ンドシェイクの①の処理でどの暗号アルゴリズムとプロトコルバージョンを選択したかに大きく 依存する。サイトの身分証明ともいえるサーバ証明書は、Trusted Third Party である認証局（CA[ 9]）によっ
て発行されるのが一般的であり、特に Web Trust for CA などの一定の基準を満たしている代表的 な認証局の証明書はルート CA として予めブラウザに登録されている。(4)の検証では、ブラウザ に登録された認証局の証明書を信頼の起点として、当該サーバ証明書の正当性を確認する。
SSL/TLS 暗号設定ガイドライン － 13 図 1 SSL/TLS プロトコル概要
2.1.3 TLS1.3 の概要
TLS1.3 は、TLS1.2 策定以降に見つかった新たな脆弱性や攻撃手法への対策を施すと共に、QUIC 等のプロトコルに対応するための性能向上を狙いとして、プロトコルと暗号アルゴリズムの抜本 的な再設計が行われた。最新仕様は draft28 であり、2018 年 3 月に RFC Editor Queue に進み、RFC 発効前の最終作業が続いている（2018 年 4 月現在）。
TLS1.2（以前）との差異の観点から見た主な特徴を以下に示す。
(1) 脆弱なアルゴリズムとして、Triple DES、DSA、RC4、MD5、SHA-1、SHA-224、静的な RSA が削除された。また、認証暗号（AEAD）でない AES の CBC モードが削除された。 (2) NIST FIPS/SP で規定されていないアルゴリズムとして、共通鍵暗号の ChaCha20 と署名の
EdDSA が追加された。 (3) 鍵交換は、DHE、ECDHE、PSK のみが規定され、ECDHE が必須になった。 (4) 楕円曲線として secp256r1 が必須になった。 (5) ハッシュ関数は SHA-256 が必須になった。 (6) 脆弱なハンドシェイク機能として、リネゴシエーション、圧縮、セッション回復が削除さ れた。
SSL/TLS 暗号設定ガイドライン － 14
(7) HMAC ベースの導出関数（HKDF-Expand(・), HKDF-Extract(・)）を使った鍵導出に変更さ れた。 図 2 鍵の導出方法 (8) ServerHello 以降のハンドシェイクパラメータを暗号化して保護する。 図 3 TLS1.2 と TLS1.3 との暗号化開始個所の比較
EarlySecret(ES) = HKDF-Extract(PSK, 0) # 初期状態ではPSK=0
x=HKDF-Expand(ES, …)
HandshakeSecret(HS) = HKDF-Extract ((EC)DHE, x)
x=HKDF-Expand(HS, …)
client_handshake_traffic_secret= HKDF-Expand(HS , …)
server_handshake_traffic_secret= HKDF-Expand(HS , …)
MasterSecret(MS) = HKDF-Extract (0, x)
client_application_traffic_secret_0= HKDF-Expand(MS , …)
server_application_traffic_secret_0= HKDF-Expand(MS , …)
exporter_master_secret= HKDF-Expand(MS , …)
resumption_master_secret= HKDF-Expand(MS , …)
client_early_traffic_secret= HKDF-Expand(ES , …)
early_exporter_master_secret= HKDF-Expand(ES , …)
binder_key= HKDF_Expand(ES, …)
※鍵の色は、図4～図6の シーケンスと対応する
TLS1.2
TLS1.3
ClientHello
ClientKeyExchange
ChangeCipherSpec
Finished
ServerHello
Certificate
CertificateVerify
Finished
ServerHello
ServerCertificcate
ServerKeyExchange
ServerHelloDone
ChangeCipherSpec
Finished
ここから暗号化する
ClientHello
Finished
ここから暗号化する
SSL/TLS 暗号設定ガイドライン － 15 図 4 TLS1.3 のシーケンス図 (9) 性能向上のため、1-RTT でハンドシェイクが完了するようにメッセージおよび拡張が見直 された。 図 5 1-RTT のシーケンス図 ClientHello (KeyShare,
signature_algorithms) ServerHello (KeyShare) EncryptedExtentions() CertificateRequset() Certificate() CertificateVerify() Finished() Application Data Certificate() CertificateVerify() Finished() NewSessionTicket(ticket) Application Data ※暗号化で使う鍵の色は 図2の鍵の色に対応する。
Client
Server
ClientHello( KeyShare, psk_key_exchange_modes， pre_shared_key) ServerHello( KeyShare , pre_shared_key ) EncryptedExtentions() Finished() Application Data Finished() Application Data ※暗号化で使う鍵の色は 図2の鍵の色に対応する。Client
Server
SSL/TLS 暗号設定ガイドライン － 16 (10) QUIC 等への適用を考慮し、0-RTT でアプリデータを送信する機能が追加された。 図 6 0-RTT のシーケンス図 (11) ClientHello、ServerHello、ChangeCipherSpec の TLS1.2 互換性を保つことにより、中間ノー ドによる接続性を向上した。
2.1.4 TLS プロトコルの最新動向
TLS1.3 がまもなく RFC として発行されるのを受け（ガイドライン発行時の状況によっては文 章修正の可能性有り）、2017 年 11 月に NIST は TLS に関する新たなガイドラインのドラフト版[ 10] を発表した。このドラフト版では、2020 年 1 月 1 日までに、①連邦政府で利用する全てのサーバ 及びクライアント（ブラウザ）で TLS1.2 をサポートすることを要求するとともに、②TLS1.3 を サポートし移行する計画を作るよう勧告する、内容になっている。 また、2015 年 4 月以降に発行された SSL/TLS に関する RFC 32 件のうち、「プロトコルバージ ョン」「サーバ証明書」「暗号スイート（暗号アルゴリズム）」の 3 つの観点から、利用可否や利用 期間などの記述が含まれるものは、以下のとおりである。例えば、既存の TLS1.2 までのプロトコ ルに対して、SSL3.0 の無効化や RC4 の無効化など、プロトコルの脆弱性の排除に関するものが 規格化されている。[10] NIST SP 800-52 Rev. 2 (draft), Guidelines for the Selection, Configuration, and Use of Transport
Layer Security (TLS) Implementations
Client Server ClientHello（early_data, KeyShare, psk_key_exchange_modes， pre_shared_key) Application Data ServerHello（ pre_shared_key ， KeyShare) EncryptedExtentions(early_data) Finished() Application Data EndOfEarlyData Finished() ※暗号化で使う鍵の色は 図2の鍵の色に対応する。 Application Data Application Data
SSL/TLS 暗号設定ガイドライン － 17 表 4 2015 年 4 月以降に「プロトコルバージョン」「サーバ証明書」 「暗号スイート（暗号アルゴリズム）」に関連して発行された RFC RFC Title プロトコ ル サーバ 証明書 暗号 スイート 内容
7465 Prohibiting RC4 Cipher Suites × × ○ RC4 禁止 7507 TLS Fallback Signaling Cipher Suite
Value (SCSV) for Preventing Protocol Downgrade Attacks
× × ○ 新暗号スイートの定義
7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
○ × × SSL2.0, SSL3.0 禁止 TLS1.0, TLS1.1 非推奨
7568 Deprecating Secure Sockets Layer Version 3.0
○ × × SSL3.0 禁止
7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)
× × 〇 ChaCha20-Poly1305 の 暗号スイート追加
2.2 暗号アルゴリズムの安全性
2.2.1 CRYPTREC 暗号リスト
総務省と経済産業省は、暗号技術に関する有識者で構成される CRYPTREC 活動を通して、電子 政府で利用される暗号技術の評価を行っており、2013 年 3 月に「電子政府における調達のために 参照すべき暗号のリスト(CRYPTREC 暗号リスト)」 を策定した[ 11]。CRYPTREC 暗号リストは、 「電子政府推奨暗号リスト」、「推奨候補暗号リスト」及び「運用監視暗号リスト」で構成される。 「政府機関の情報セキュリティ対策のための統一基準（平成 28 年度版）」（平成 28 年 8 月 31 日、サイバーセキュリティ戦略本部）では以下のように記載されており、 政府機関における情報 システムの調達及び利用において、CRYPTREC 暗号リストのうち「電子政府推奨暗号リスト」が 原則的に利用される。 政府機関の情報セキュリティ対策のための統一基準（抄） 6.1.5 暗号・電子署名－遵守事項(1)(b) 情報システムセキュリティ責任者は、暗号技術検討会及び関連委員会（CRYPTREC）に より安全性及び実装性能が確認された「電子政府推奨暗号リスト」を参照した上で、情報 システムで使用する暗号及び電子署名のアルゴリズム並びにそれを利用した安全なプロト コル及びその運用方法について、以下の事項を含めて定めること。 （ア） 行政事務従事者が暗号化及び電子署名に対して使用するアルゴリズム及びそれ を利用した安全なプロトコルについて、「電子政府推奨暗号リスト」に記載され [11] http://www.cryptrec.go.jp/list.htmlSSL/TLS 暗号設定ガイドライン － 18 た暗号化及び電子署名のアルゴリズムが使用可能な場合には、それを使用させる こと。 （イ） 情報システムの新規構築又は更新に伴い、暗号化又は電子署名を導入する場合に は、やむを得ない場合を除き、「電子政府推奨暗号リスト」に記載されたアルゴ リズム及びそれを利用した安全なプロトコルを採用すること。 （以下、略）
2.2.2 異なる暗号アルゴリズムにおける安全性の見方
異なる技術分類の暗号アルゴリズムを組合せて利用する際、ある技術分類の暗号アルゴリズム の安全性が極めて高いものであっても、別の技術分類の暗号アルゴリズムの安全性が低ければ、 結果として、低い安全性の暗号アルゴリズムに引きずられる形で全体の安全性が決まる。逆に言 えば、異なる技術分類の暗号アルゴリズムであっても、同程度の安全性とみなされている暗号ア ルゴリズムを組合せれば、全体としても同程度の安全性が実現できることになる。 異なる技術分類の暗号アルゴリズムについて同程度の安全性を持つかどうかを判断する目安と して、“ビット安全性（等価安全性ということもある）”という指標がある。具体的には、評価対 象とする暗号アルゴリズムに対してもっとも効率的な攻撃手法を用いたときに、どの程度の計算 量があれば解読できるか（解読計算量[ 12]）で表現され、鍵長[ 13]とは別に求められる。表記上、解 読計算量が 2xである場合に“x ビット安全性”という。例えば、共通鍵暗号においては、全数探 索する際の鍵空間の大きさで 2x（x は共通鍵のビット長）、ハッシュ関数の例としては、一方向性 で 2x、衝突困難性で 2(x/2)（x は出力ビット長）が解読計算量の（最大）理論値である。 “ビット安全性”による評価では、技術分類に関わらず、どの暗号アルゴリズムであっても、 解読計算量が大きければ安全性が高く、逆に小さければ安全性が低い。また、解読計算量が実現 可能と考えられる計算量を大幅に上回っていれば、少なくとも現在知られているような攻撃手法 ではその暗号アルゴリズムを破ることは現実的に不可能であると予測される。 そこで、暗号アルゴリズムの選択においては、“x ビット安全性”の“x ビット”に着目して、 長期的な利用期間の目安とする使い方ができる。例えば、NIST SP800-57 Part 1 revision 4[ 14]では、表 5 のように規定している。 なお、表記の便宜上、本ガイドラインでは以下の表記を用いる。 AES-xxx：鍵長が xxx ビットの AES のこと Camellia-xxx：鍵長が xxx ビットの Camellia のこと RSA-xxx：鍵長が xxx ビットの RSA のこと DH-xxx：鍵長が xxx ビットの DH のこと
ECDH-xxx：鍵長が xxx ビット（例えば NIST 曲線パラメータ P-xxx を利用）の ECDH のこと
[12] 直感的には、基本となる暗号化処理の繰り返し回数のことである。例えば、解読計算量 220
といえば、暗号化処理 220回相当の演算を繰り返し行えば解読できることを意味する [13] ハッシュ関数の場合はダイジェスト長に相当する
SSL/TLS 暗号設定ガイドライン － 19
ECDSA-xxx：鍵長が xxx ビット（例えば NIST 曲線パラメータ P-xxx を利用）の ECDSA のこと
HMAC-xxx：メッセージ認証子を作る HMAC において利用するハッシュ関数 SHA-xxx のこと。SSL/TLS では、暗号スイートで決めるハッシュ関数は HMAC として利用 される。 SHA-xxx：デジタル署名を作成する際に利用するハッシュ関数 SHA-xxx のこと。 表 5 NIST SP800-57 でのビット安全性の取り扱い方針（WG で加工） ビット安全性 SSL/TLS で 利 用 す る 代 表 的 な 暗 号アルゴリズム 利用上の条件 長期的な利用期間 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 ビ ッ ト か ら 192 ビットの間 RSA-4096 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 暗号設定ガイドライン － 20
PART I：
SSL/TLS 暗号設定ガイドライン － 21
3. 設定基準の概要
本章では、SSL/TLS サーバの構築時に、主に暗号通信に関わる設定に関しての要求事項を決め るために考慮すべきポイントについて取りまとめる。3.1 実現すべき設定基準の考え方
SSL/TLS は、1994 年に SSL2.0 が実装されて以来、その利便性から多くの製品に実装され、利 用されている。一方、プロトコルの脆弱性に対応するため、何度かプロトコルとしてのバージョ ンアップが行われている影響で、製品の違いによってサポートしているプロトコルバージョンや 暗号スイート等が異なり、相互接続性上の問題が生じる可能性がある。 本ガイドラインでは、安全性の確保と相互接続の必要性のトレードオフにより、「高セキュリテ ィ型」「推奨セキュリティ型」「セキュリティ例外型」の 3 段階の設定基準に分けて各々の要求設 定を定める。それぞれの設定基準における、安全性と相互接続性についての関係は表 6 のとおり である。 実際にどの設定基準を採用するかは、安全性の確保と相互接続の必要性の両面を鑑みて、サー バ管理やサービス提供に責任を持つ管理者が最終的に決定すべきことではあるが、本ガイドライ ンでは、安全性もしくは相互接続性についての特段の要求がなければ「推奨セキュリティ型」の 採用を強く勧める。本ガイドラインの発行時点では、「推奨セキュリティ型」がもっとも安全性と 可用性（相互接続性）のバランスが取れている要求設定であると考えている。 「セキュリティ例外型」は、システム等の制約上、脆弱なプロトコルバージョンである SSL3.0 の利用を全面禁止することが現実的ではなく、安全性上のリスクを受容してでも SSL3.0 を継続 利用せざるを得ないと判断される場合にのみ採用すべきである。なお、セキュリティ例外型であ っても、SSL3.0 の無期限の継続利用を認めているわけではなく、近いうちに SSL3.0 を利用不可 に設定するように変更される可能性がある。 また、SSL3.0 を利用する関係から、利用可能な暗号スイートの設定においても、脆弱な暗号ア ルゴリズムである RC4 の利用を認めている。ただし、本来的には RC4 は SSL3.0 に限定して利用 すべきであるが、TLS1.0 以上のプロトコルバージョンで RC4 の利用を不可にする設定を行うこ とが難しいため、TLS1.0 以上であっても RC4 が使われる可能性が排除できないことにも注意さ れたい。 したがって、セキュリティ例外型を採用する際は、推奨セキュリティ型への移行完了までの短 期の暫定運用として、移行計画や利用終了期限を定めたりするなど、今後への具体的な対処方針 の策定をすべきである。SSL/TLS 暗号設定ガイドライン － 22 表 6 安全性と相互接続性についての比較 設定基準 概要 安全性 相互接続性の確保 高セキュ リティ型 扱う情報が漏えいした際、組織の運営や資 産、個人の資産やプライバシー等に致命的ま たは壊滅的な悪影響を及ぼすと予想される情 報を、高い安全性を確保して SSL/TLS で通信 するような場合に採用する設定基準 ※高い安全性を必要とする理由があるケース を対象としており、高度な使い方をする場合 の設定基準である。 ＜利用例＞ 政府内利用（G2G 型）のなかでも、高い安全 性が要求される通信を行う場合 本ガイドライ ンの公開時点 （2018 年 5 月）におい て、標準的な 水準を大きく 上回る高い安 全性水準を達 成 本ガイドラインで対象 とするブラウザ（8.1.2 節）が搭載されている PC、スマートフォンな どでは問題なく相互接 続性を確保できる 本ガイドラインが対象 としない、バージョン が古い OS やブラウザ の場合や発売開始から ある程度の年月が経過 している一部の古い機 器（フィーチャーフォ ンやゲーム機など）に ついては接続できない 可能性がある 推奨 セキュリ ティ型 扱う情報が漏えいした際、組織の運営や資 産、個人の資産やプライバシー等に何らかの 悪影響を及ぼすと予想される情報を、安全性 確保と利便性実現をバランスさせて SSL/TLS での通信を行うための標準的な設定基準 ※ほぼすべての一般的な利用形態で使うこと を想定している ＜利用例＞ • 政府内利用（G2G 型）や社内システムへの リモートアクセスなど、特定された通信相 手との安全な通信が要求される場合 • 電子申請など、企業・国民と役所等との電 子行政サービスを提供する場合 • 金融サービスや電子商取引サービス、多様 な個人情報の入力を必須とするサービス等 を提供する場合 • 既存システムとの相互接続を考慮すること なく、新規に社内システムを構築する場合 本ガイドライ ンの公開時点 （2018 年 5 月）における 標準的な安全 性水準を実現 ほとんどのすべての機 器について相互接続性 を確保できる ※すでにサポートが切 れているなどかなり古 い機器などで接続でき ない場合があるが、こ の種の機器は本来接続 させるべきではない
SSL/TLS 暗号設定ガイドライン － 23 設定基準 概要 安全性 相互接続性の確保 セキュリ ティ 例外型 脆弱なプロトコルバージョンや暗号が使われ るリスクを受容したうえで、安全性よりも相 互接続性に対する要求をやむなく優先させて SSL/TLS での通信を行う場合であって、推奨 セキュリティ型への移行完了までの短期の暫 定運用としての設定基準 ＜利用例＞ • 利用するサーバやクライアントの実装上の 制約、もしくは既存システムとの相互接続 上の制約により、推奨セキュリティ型（以 上）の設定が事実上できない場合 本ガイドライ ンの公開時点 （2018 年 5 月）におい て、最低限度 の安全性水準 を満たしてい るとは言えな い状況になっ ている。速や かな推奨セキ ュリティ型へ の移行を強く 求める ほとんどのすべての機 器について相互接続性 を確保できる
3.2 要求設定の概要
SSL/TLS における暗号通信に関わる設定には以下のものがある。 プロトコルバージョンの設定（4 章） サーバ証明書の設定（5 章） 暗号スイートの設定（6 章） SSL/TLS を安全に使うために考慮すべきこと（7 章） 本ガイドラインでは、上記の設定項目のうち、プロトコルバージョン、サーバ証明書、暗号ス イートの 3 つの項目について、3.1 節に記載した設定基準に対応した詳細な要求設定を該当章に 各々まとめている。 表 7 に要求設定の概要を記す。SSL/TLS 暗号設定ガイドライン － 24 表 7 要求設定の概要 要件 高セキュリティ型 推奨セキュリティ型 セキュリティ例外型 想定対象 G2G 等 一般 推奨セキュリティ型以 上の設定が現実的では ない等の特殊事情が あるケースに限定 暗号スイートの （暗号化）セキュリティ レベル ①256 bit ②128 bit ①128 bit ②256 bit ① 128 bit ② 256 bit ③ RC4, Triple DES 暗号ア ルゴリ ズム 鍵交換 鍵長 2048 ビット以上 の DHE または 鍵長 256 ビット以上の ECDHE 鍵長 1024 ビット以上の DHE または鍵長 256 ビ ット以上の 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*
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 チェックリスト
図 7 に高セキュリティ型のチェックリストのイメージを示す。 チェックリストの目的は、 選択した設定基準に対応した要求設定項目をもれなく実施したことを確認し、設定忘れを 防止することSSL/TLS 暗号設定ガイドライン － 25 サーバ構築の作業受託先が適切に要求設定項目を設定したことを、発注者が文書として確 認する手段を与えること である。したがって、選択した設定基準に応じたチェックリストを用い、すべてのチェック項目 について、該当章に記載の要求設定に合致していることを確認して「済」にチェックが入ること が求められる。 Appendix A には、各々の設定基準に対応したチェックリストを載せる。 図 7 チェックリスト（高セキュリティ型の例）
SSL/TLS 暗号設定ガイドライン － 26
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 節 表 8 参照）を踏まえ、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 暗号設定ガイドライン － 27
【セキュリティ例外型の要求設定】
SSL2.0 を設定無効（利用不可）にする TLS1.1、TLS1.2 については、実装されているのであれば、設定有効にする プロトコルバージョンの優先順位が設定できる場合には、設定有効になっているプロトコ ルバージョンのうち、最も新しいバージョンによる接続を最優先とし、接続できない場合 に順番に一つずつ前のプロトコルバージョンでの接続するように設定することが望ましい TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0 3 つのうち のいずれか ◎ ○ ○ ○ × － ◎ ○ ○ × － － ◎ ○ × ○：設定有効（◎：優先するのが望ましい） ×：設定無効化 －：実装なし4.2 プロトコルバージョンごとの安全性の違い
SSL2.0 から TLS1.2 までの各プロトコルバージョンにおける安全性の違いを表 8 にまとめる。 表 8 プロトコルバージョンでの安全性の違い 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） 可 不可 不可 不可 不可 楕円曲線暗号 可 可 可 不可 不可SSL/TLS 暗号設定ガイドライン － 28 【コラム①】SSL/TLS から TLS へ －プロトコルとしての本格的な世代交代へ－ インターネットは、1960 年代の ARPANET 開発等を起源に、1980 年代に学術ネットワー クとして世界中に広がっていったネットワークである。この時代には、「ネチケット（ネット ワーク＋エチケット：基本的なネットワーク利用ルールを意味する造語）」という言葉が存 在したように、「限られた善良なユーザが暗黙の利用ルールを守ってインターネットを利用 する」という性善説に立った運用がなされており、セキュリティ確保はあまり重要な要件で はなかった。 1990 年代にビジネス利用が徐々に解禁されると、悪意を持ったユーザがインターネットに 入り込むことが容易になり、またネットワーク初心者も増えた結果、性善説に立ってインタ ーネットを運用することが難しい状況になった。そのような状況になって、セキュリティ確 保の重要性が高まるなか、SSL (Secure Sockets Layer)が誕生した。
SSL が画期的なのは、ブラウザベンダであった Netscape 社が開発したことで当初からブラ ウザに標準搭載され、セキュリティの予備知識を持たないユーザにもセキュアなインターネ ット環境を提供したことである。この結果、オンラインバンキング・オンラインショッピン グ等を利用するユーザ数が爆発的に増え、インターネットビジネスの隆盛につながっていっ たことは疑いの余地がない。IETF が定める正式名称 TLS (Transport Layer Security)よりも SSL の方がはるかに知名度があることはその証左といえるだろう。本ガイドラインが「SSL/TLS」 と謳っているのもそのためである。
しかし、2010 年代に入ると急速に SSL の安全性は低下する。
SSL3.0 で使える暗号アルゴリズムは、2000 年の輸出規制緩和以前に定められたこともあ って、RC4 と Triple DES 等であるが、これらに対する暗号解読手法の進展により、今では危 殆化した暗号に位置づけられている。例えば、RC4 は無線 LAN の一方式である WEP (Wired Enhanced Privacy) で も 使 わ れ て い た が 、 2000 年 代 に 現 実 的 な 解 読 方 法[ 15 ][ 16 ]が 見 つ か り
WPA/WPA2 への移行が進められた。2013 年以降、SSL/TLS での RC4 利用に対しても様々な 攻撃手法が提案[ 17]されている。Triple DES も、2016 年に Sweet32 とよばれる攻撃手法[ 18]が
公表されたことを受け、2017 年 11 月に NIST は Triple DES の利用方法の見直しを実施する
[ 19]とともに、利用終了期限を含めた今後のスケジュール検討に入る[ 20]ことを表明した。
また、2014 年に発表された POODLE (Padding Oracle On Downgraded Legacy Encryption)攻 撃[ 21]は SSL3.0 の仕様上の脆弱性に起因する攻撃方法であったことから、SSL3.0 を利用不可 にするしか回避策がなかった。 このため、この数年間でほぼ全てのブラウザで SSL3.0 を利用不可とする設定が行われて いる。 [15] https://iacr.org/archive/asiacrypt2005/390/390.pdf [16] https://eprint.iacr.org/2007/120.pdf [17] https://www.rc4nomore.com/ [18] https://sweet32.info/ [19] https://csrc.nist.gov/publications/detail/sp/800-67/rev-2/final [20] https://csrc.nist.gov/news/2017/update-to-current-use-and-deprecation-of-tdea [21] https://www.openssl.org/~bodo/ssl-poodle.pdf
SSL/TLS 暗号設定ガイドライン － 29 最近では、より根本的な対策として 2.1.3 節で紹介したように、SSL3.0 の流れを汲む TLS1.0、TLS1.1、TLS1.2 から外れ、新しい方針で作られた TLS1.3 が誕生した。しかも、TLS1.3 は IETF での標準化前からブラウザ等への搭載が始まるなど、今までにない速いテンポで準 備が進んでいる。 実際、NIST では、2020 年 1 月 1 日までに TLS1.2 をサポートすること、及び TLS1.3 をサ ポートし移行する計画を作ることを求めるガイドライン案[ 22]を公表している。 [22] https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft
SSL/TLS 暗号設定ガイドライン － 30
5. サーバ証明書の設定
サーバ証明書は、①クライアントに対して、情報を送受信するサーバが意図する相手（サーバ の 運 営 組 織 等 ） に よ っ て 管 理 さ れ る サ ー バ で あ る こ と を 確 認 す る 手 段 を 提 供 す る こ と と 、 ② SSL/TLS による暗号通信を行うために必要なサーバの公開鍵情報をクライアントに正しく伝える こと、の 2 つの役割を持っている。 これらの役割を正しく実行するために、5.1 節にサーバ証明書についての要求設定をまとめる。 5.2 節以降にはサーバ証明書の設定を決める際の検討項目の概要を記す。5.1 サーバ証明書についての要求設定
後述する 5.2 節以降の内容を踏まえ、サーバ証明書についての要求設定を以下のように定める。 なお、本ガイドライン公開時点（2018 年 5 月）においては、推奨セキュリティ型の要求設定は高 セキュリティ型と同様とする。 高セキュリティ型（推奨セキュリティ型）の要求設定では、少なくともハッシュ関数として SHA-256 が使えることが必須条件となることに注意されたい。例えば、SHA-SHA-256 が使えないブラウザ （クライアント）では、サーバ証明書の検証ができず、警告表示が出るか、当該サーバとの接続 は不能となる。このことは、DSA や ECDSA を使う場合についても同様である。 一方、セキュリティ例外型の要求設定では、ハッシュ関数として SHA-1 の利用も許容しており、 過去のシステムとの相互接続性は高い。ただし、SHA-1 を利用したサーバ証明書はパブリック認 証局から発行してもらうことが出来なくなったので、自らプライベート認証局を運用しなければ ならなくなるなど、非常に運用管理の負荷がかかることを強く認識する必要がある。また、現在 の主要ブラウザでは SHA-1 を使うサーバ証明書に対して無効化されていることに注意すること。 DSA については、5.3 節で示すように電子政府推奨暗号リストに選定されており、安全性上の 問題はない。しかし、サーバ証明書としては現時点でほとんど利用されておらず、技術的にも RSA や ECDSA と比較して大きなメリットがあるとは言えないことから、本ガイドラインでは積極的 には DSA の利用を勧めない[ 23]。【高セキュリティ型の要求設定】
本ガイドライン公開時点（2018 年 5 月）で、多くの認証局から入手可能なサーバ証明書の うち、安全性が高いものを利用する。 サーバ証明書の アルゴリズムと 鍵長 サーバ証明書の発行・更新を要求する際に生成する鍵情報（Subject Public Key Info）でのアルゴリズム（Subject Public Key Algorithm）と鍵長として は、以下のいずれかを必須とする。
[23] 本ガイドラインでは、DSA は利用しないことを要求設定の前提としているため、6 章の暗号
SSL/TLS 暗号設定ガイドライン － 31 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 証明書をインストールする
【推奨セキュリティ型の要求設定（高セキュリティ型の要求設定と同じ）】
本ガイドライン公開時点（2018 年 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）以上
SSL/TLS 暗号設定ガイドライン － 32 サーバ証明書の 発行・更新時の 鍵情報の生成 サーバ証明書の発行・更新を要求する際には、既存の鍵情報は再利用 せず、必ず新たに公開鍵と秘密鍵の鍵ペアを生成しなければならない 上記の指示をサーバ管理者への仕様書、運用手順書、ガイドライン等 に明示しなければならない クライアントでの 警告表示の回避 当該サーバに接続することが想定されている全てのクライアントに 対して、以下のいずれかの手段を用いて警告表示が出ないようにする か、警告表示が出るブラウザはサポート対象外であることを明示しな ければならない パブリック認証局からサーバ証明書を入手する 警告表示が出るクライアントの利用を禁ずる措置を取る 5.4.2 節の例外規定に従って、信頼できるプライベート認証局のル ート CA 証明書をインストールする
【セキュリティ例外型の要求設定】
本ガイドライン公開時点（2018 年 5 月）で、多くの認証局から入手可能なサーバ証明書の うち、許容可能な水準以上の安全性を確保しているサーバ証明書で、最も相互接続性が高 いものを利用する。なお、 過去のシステム・ブラウザ等との相互接続性の確保の観点から、 SHA-1 を利用するサーバ証明書がどうしても必要である場合には、パブリック認証局から 発行してもらうことが出来なくなったので、自らプライベート認証局を運用しなければな らなくなった。これは、SSL/TLS サーバの運用だけでなく、認証局の運用も含めて安全に 管理する必要があることを意味し、非常に運用管理の負荷がかかることを強く認識する必 要がある。このため、真にやむを得ない場合を除いては、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-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 ビット以上
SSL/TLS 暗号設定ガイドライン － 33 ※ 過去のシステム・ブラウザ等との相互接続性の確保を最優先するなら SHA-1 を利用したサーバ証明書を使うことも妨げるものではないが、 非常に運用管理の負荷がかかることを強く認識しなければならない。 ※ また、現在の主要ブラウザでは SHA-1 を使うサーバ証明書に対して無 効化されていることに注意すること。詳細については 8.3.1 節を参照 のこと サーバ証明書の 発行・更新時の 鍵情報の生成 サーバ証明書の発行・更新を要求する際には、既存の鍵情報は再利用 せず、必ず新たに公開鍵と秘密鍵の鍵ペアを生成しなければならない 上記の指示をサーバ管理者への仕様書、運用手順書、ガイドライン等 に明示しなければならない クライアントでの 警告表示の回避 当該サーバに接続することが想定されている全てのクライアントに 対して、以下のいずれかの手段を用いて警告表示が出ないようにする か、警告表示が出るブラウザはサポート対象外であることを明示しな ければならない パブリック認証局からサーバ証明書を入手する 警告表示が出るクライアントの利用を禁ずる措置を取る 5.4.2 節の例外規定に従って、信頼できるプライベート認証局のル ート CA 証明書をインストールする
5.2 サーバ証明書に記載されている情報
サーバ証明書には、表 9 に示す情報が記載されている。これらの情報は、証明書プロパティの 「詳細」で見ることができる。 これらのうち、当該サーバ証明書を発行した認証局が「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）用途にも 使えることを意味する。
SSL/TLS 暗号設定ガイドライン － 34 表 9 サーバ証明書に記載される情報
証明書のバージョン Version
シリアル番号 Serial Number
署名アルゴリズム Certificate Signature Algorithm
発行者 Issuer
有効期間（開始～終了） Validity (Not Before ～ Not After)
サブジェクト（発行対象） Subject
（サブジェクトが使う）公開鍵情報[ 24] Subject Public Key Info (Algorithm, Public Key Value)
拡張情報 Extensions
キー使用法 Certificate Key Usage 署名 Certificate Signature Value
