【0：常時 SSL の必要性】

[はじめに]
SSL サーバー証明書には 2 つの役割が存在しています。「暗号化」 と 「実在証明」 です。これは、サイトを常時 SSL 化した場合であっても同様の役割となります。SSL により暗号化されたサイトにアクセスし、データの送付を行ったとしても、暗号化通信によりデータが盗み見られることはありません。実在証明がされたサーバー証明書が設定されているサイトであれば、サイトの運営組織を確認することができます。実在証明は OV 証明書または EV 証明書が対象です。

 

それでは、SSL サーバー証明書が設定されているページであれば安全と言えるのでしょうか。

 

[選択すべき SSL / TLS]
実際にページにアクセスをする利用者についても、ただアクセスをすればよいというわけではなく、使用する暗号方式をブラウザで選択する必要性があります。以下の表のような流れで SSL 及び TLS のバージョンがリリースされました。

 

SSL 1.0	リリース前に脆弱性が発見され公開されず
SSL 2.0	1994 年リリース
SSL 3.0	1995 年リリース
TLS 1.0	1999 年リリース
TLS 1.1	2006 年リリース
TLS 1.2	2008 年リリース
TLS 1.3	2018 年 3 月 IETF で承認

 

現在では、最低でも TLS 1.0 以上を選択するような潮流になっていますが、セキュリティ強化のためにも TLS 1.2 を設定するようにはしたいところです。現時点 (2018 年 9 月時点) では、TLS 1.2 までがリリースされています。しかしながら、TLS 1.2 や 2018 年 3 月に IETF にて承認された TLS 1.3 であっても恒久的に暗号の強度の保証がされているわけではありません。いずれ当該の暗号方式についても解読手法などが確立され、安全とはいえない危険な状況になっていきます。これを暗号の 「危殆化 (きたいか)」 と呼びます。この危殆化は防ぐことができないため、最新の暗号方式を選択する必要があります。また、秘密鍵の漏えいなどによっても暗号解読の危険性を招いてしまうため、厳重に管理をする必要があります。

 

ブラウザ上での暗号方式の選択について、参考までに次に記載します。

 

Internet Explorer を開き、【設定】 ⇒ 【インターネットオプション】 ⇒ 【詳細設定タブ】 を選び、セキュリティの項目にある暗号方式を選択することで設定ができます。

 

 

本来は、TLS 1.2 のみを選択していることが望ましいのですが、サーバーなどアクセスする先の設定状況によっては TLS 1.2 以外の暗号方式を選択していることもあるため、TLS 1.0 や TLS 1.1 を選択から外すことが難しいという事情もあります。こういったことからも、サーバーなどシステムを管理している立場においても、より最新の暗号方式への切り替えを進める必要性があります。サーバーの設定については、次の章に記載します。

 

更に、現在では SSL サーバー証明書の利用箇所として情報を送信するフォームだけではなく、フォームなどが設置されていないページであっても SSL サーバー証明書を設定するという、サイト上の全てのページを SSL 設定する 「常時 SSL 化」 の流れも進んできています。サイトの常時 SSL 化は、金融関係のサイトから始まり、大手のポータルサイトなどに広がり、今では Web サイトを利用した各種サービスにまで普及が進んでいます。

 

[常時 SSL が必要な理由]
それではなぜ、このようにサイトの常時 SSL 化の普及が進んでいったほうがよいのでしょうか。

 

現在、公共の場所などでは無料で使える Wi-Fi スポットが設置されている所が多々あります。そこでは、悪意ある第三者が、偽の Wi-Fi スポットを設置し、情報を盗み取るためのソフトウェアを入れるなどすることで、この Wi-Fi スポットを経由した通信で流れる情報を盗み取ることが考えられます。このような場合でも、アクセスするサイトが常時 SSL 化されていることで、Wi-Fi スポットを経由する際にも暗号化された通信となるため、情報が盗み取られる脅威は大幅に少なくなります。

 

また、インターネット上ではなりすましという脅威も存在します。アクセスしたサイトが正しい組織によって運営されていることを確認する手段がサーバー証明書です。常時 SSL 化されていれば、サイト内のどこにアクセスをしたとしても、サーバー証明書によりサイトの運営組織を確認することができます。

 

一方、サイトを運営している組織から見た場合、常時 SSL 化を一度してしまえば、いつまでも万全というわけではなく、SSL サーバー証明書の中には有効期限があり、有効期限までに SSL サーバー証明書の更新をし、入れ替えの作業を行わなければなりません。先に記載した暗号の危殆化に対する措置や秘密鍵の管理、そして有効期限の管理など、SSL サーバー証明書は適切に管理する必要があります。

 

[フィッシングサイトなのに証明書が使われている？]
前述では正しい組織が運営していることを確認する手段としてサーバー証明書があると説明しましたが、フィッシングサイトはどうでしょうか。例えば、Apple をかたるフィッシングサイトには非常に多くのパターンが存在しており、その一つとして以下のようなものがあります。

 

 

フィッシングサイトであるにもかかわらず、正規の証明書が使われていることがわかります。通常、サーバー証明書を取得する際には証明書ベンダによる確認作業が必要となりますが、証明書の中には 「ドメイン名の登録権のみを確認して発行する証明書」 である DV 証明書というものがあり (詳細は後述)、ドメイン名の登録を証明しさえすれば、証明書を発行してもらうことができるため、攻撃者は証明書付きフィッシングサイトを作ることが簡単にできてしまうのです。そのため、正しい運営を行っている組織が DV 証明書を使っている場合、このように DV 証明書を使ったフィッシングサイトをたてられてしまうと、どちらのサイトが正しいのかを判断することが難しくなるため、より信頼性の高い OV または EV 証明書 (詳細は後述) を使うことが求められます。

 

参照：各ブラウザによる SSL サーバー証明書の表示の違い (2018/03/27)
https://www.antiphishing.jp/report/wg/_ssllooks_20180327.html

 

 

【1：サーバーの設定について】
前項では、常時 SSL の必要性について論じてまいりましたが、次に SSL / TLS 通信を行うサーバーの設定について説明します。

 

[サーバー証明書の種類]
まず、SSL / TLS 通信には、サーバー証明書が必須となります。サーバー証明書は、証明書を発行する際に確認する情報に応じて、ドメイン認証 (DV)、組織認証 (OV)、EV (Extended Validation) の 3 つのタイプがあります。詳細と、そのユースケースについては、以前弊 WG にて公開した記事をご参照ください。

 

参考：
SSL / TLS サーバー証明書のユースケースついて (2018/03/29)
https://www.antiphishing.jp/report/wg/_sslusecase_20180329.html

 

[サーバー証明書として、OV または EV の使用]
サーバー証明書は、前述の通り、3 種類に分類されます。前項でご紹介した内容と一部繰り返しとなりますが、昨今、発行の際に確認する情報の少ないタイプの、ドメイン認証 (DV) 証明書を巧妙に取得し、悪用する事例が増えております。

 

参考：
ゆうちょ銀行をかたるフィッシング (2019/03/04)
https://www.antiphishing.jp/news/alert/jpbank_japanpost_20190304.html

 

ドメイン認証 (DV) 証明書は、利用者の実在性の確認が行われず、ドメインの実在性の確認のみで、比較的容易に取得することが可能です。それに対し、組織認証 (OV) と EV (Extended Validation) 証明書は、証明書発行時に、組織の実在性確認が行われるため、より信頼性の高い証明書となります。昨今では、フィッシングサイトなどの危険な Web サイトも常時 SSL に対応しており、自分達の Web サイトを、信頼性の高い Web サイトとするためには、組織認証 (OV) 以上の信頼性の高いサーバー証明書を利用していく必要があります。

 

[ルート CA 証明書の設定]
次の論点として、全てのサーバー証明書の信頼性を担保するルート CA 証明書の設定について説明します。

 

ルート CA 証明書とは、サーバー証明書を発行した認証局の証明書となります。サーバー証明書を検証するアプリケーション (主としてブラウザ) は、一定の基準に準拠したルート CA 証明書が登録されており、サーバーから提示されたサーバー証明書と、あらかじめ登録されたルート CA 証明書とを組み合わせて検証を行うことで、サーバー証明書の信頼性を検証しています。サーバーには、サーバー証明書と、それに紐づくルート CA 証明書を設定する必要があり、信頼されないルート CA 証明書を利用した場合、利用者に 「危険なサーバー」 と警告が表示されることとなります。そのため、自分たちの Web サイトを、信頼性の高い Web サイトとするためには、信頼性の高いサーバー証明書を使用することに加えて、信頼されたルート CA 証明書を利用することが必要となります。

 

[プロトコルバージョン / 暗号スイートの設定]
さて、今までの項では、サーバー証明書について論じてきましたが、この項では、SSL / TLS のプロトコルバージョンと暗号スイートについて説明します。

 

暗号スイートは、「鍵交換_署名_暗号化_ハッシュ関数」 の組によって構成され、サーバーとクライアント間での暗号化通信前の事前通信 (ハンドシェイク) 時に、両者の合意のもと、一つの暗号スイートが選択されます。暗号スイートは、設定された優先順位の上位から順に、サーバーとクライアントの両者が合意できるものが選択されます。また、「【0：常時 SSL の必要性】 [選択すべき SSL / TLS]」 にて、SSL / TLS のプロトコルバージョンについて論じましたが、設定できる暗号スイートは、SSL / TLS のプロトコルバージョンによって異なり、高いバージョンであるほど、高セキュリティなものが利用可能です。

 

参考：
RFC 4346:The Transport Layer Security (TLS) Protocol Version 1.1
https://tools.ietf.org/html/rfc4346

RFC 5246:The Transport Layer Security (TLS) Protocol Version 1.2
https://tools.ietf.org/html/rfc5246

RFC 8446:The Transport Layer Security (TLS) Protocol Version 1.3
https://tools.ietf.org/html/rfc8446

 

暗号スイートを選択する際、多くのクライアントとの相互接続性を確保するには、多くの製品に共通して実装されているものを選択する必要がありますが、高い安全性を確保するためには、新しい製品でのみ実装されている、最新の高い安全性を持つ暗号スイートを設定する必要があります。

 

参考：
独立行政法人 情報処理推進機構セキュリティセンター
SSL / TLS 暗号設定ガイドライン 第 6 章 「暗号スイートの設定」
https://www.ipa.go.jp/security/ipg/documents/ipa-cryptrec-gl-3001-2.0.pdf

 

 

【2：常時 SSL 化における注意点】
前 2 項では常時 SSL 化の必要性とサーバーの設定について説明しましたが、ここではサーバーを SSL / TLS で使う設定にすること以外にも対処すべき主な課題を説明します。

 

次の事項に当てはまる場合には、利用者の混乱を招く可能性があり対処が必要ですのでご留意ください。

 

[混在コンテンツを解消していない]
同一コンテンツ内に HTTPS と HTTP が混在する場合、ブラウザによっては警告・注意喚起が表示されたり、逆に鍵マークが表示されなかったりする場合があります (この状態は 「mixed content」 と呼ばれています)。この場合、コンテンツを HTTPS で参照するように書き換えるなどの対処が必要です。

 

[サーバー証明書のコモンネームと常時 SSL 化の範囲が一致していない]
例えば、過去に Web フォームのみ SSL 化し、その証明書を用いて常時 SSL 化も行った場合など、常時 SSL 化以前のサーバー証明書に記載されているコモンネームが常時 SSL 化した範囲と一致しない場合、サーバー証明書の検証エラーの原因となります。常時 SSL 化の範囲と発行する証明書の内容を一致させる必要があります。例えば複数のサブドメインでの運用サイトを常時 SSL 化する場合、ワイルドカードサーバー証明書を用いるなどの対処が考えられます。

 

[SSL / TLS 終端をクラウドサービス事業者のサーバーにしている]
例えば、クラウドサービス事業者のコンテンツ配信サービスや WAF などを利用している場合など、SSL / TLS 終端がクラウドサービス事業者のサーバーの場合、事業者のサーバーが実際に管理するドメイン名とサーバー証明書のコモンネームが異なり、「正しいサーバー証明書を持たないアクセス先の Web サーバー」 とみなされ警告が表示される場合があります。一致させるためにクラウドサービスの設定を見直すなどの必要があります。

 

[HTTP からのリダイレクトを追加していない]
外部リンクや利用者のブックマークなどから常時 SSL 化前の HTTP で始まる URL にアクセスされることを想定し、HTTPS で始まる URL へのリダイレクト設定をするなどの対処が必要です。また、HSTS (HTTP Strict Transport Security) の設定を行うことで、次回以降のアクセスには HTTPS のみ使うよう利用者のブラウザに通知することができます。

 

他にも、アクセス解析ツール (Google アナリティクスなど) で設定している URL を HTTPS から始まるものに変更したり、利用者に配布する印刷物の記載内容を変更したりする必要もあります。

 

 

【3：まとめ】
常時 SSL 化普及の流れを受け、利用者が安心してアクセスできる SSL / TLS Web サイトをサイト運営者が構築するためのチェックポイントとしてサーバー証明書の設定・管理、SSL / TLS サーバーの設定、コンテンツ構成やアクセス先ドメインなどのサーバー設定以外の注意点について述べてきましたが、運用を開始して以降も利用者が安心してアクセスできる状態を維持していくためには、前述のチェックポイントに関してアップデートされる情報に留意し適切な更新作業を継続して実施していくことが必要です。

 

例えば、サーバー証明書には有効期限があるため更新手続きが必要ですが、その際には従前使用した鍵情報 (秘密鍵・公開鍵の鍵ペア) を再度用いることはせず、新たに鍵ペアを生成すること、サーバー証明書の秘密鍵は第三者に漏えいすることのないよう厳格に管理すること、また Web サイトのコンテンツはアクセスした利用者にエラーが表示されないように配置することなどが留意事項として挙げられます。

 

また、SSL / TLS プロトコルのバージョン設定に関し、サーバーとブラウザとの間で共通のバージョンが使用できるように設定されていないと、Web サイトへのアクセスがエラーとなるため、利用者に対し設定の確認や変更のガイドが必要な場合があります。最近ニュースなどで取り上げられていますが、Google Chrome 68 で非 HTTPS (非 SSL / TLS) の Web サイトにアクセスすると 「保護されていません」、「保護されていない通信」 と表示されるようになりました。Microsoft、Google、Mozilla、Apple などが提供する主要ブラウザで、HTTPS (SSL / TLS) に対応している Web サイトおよび対応していない Web サイトにアクセスした際に、それぞれどのような表示が行われるかについてブラウザ各社の動向に留意することも有効と思われます。

 

[最後に]
SSL / TLS に対応した Web サイトであっても、適切な設定や更新作業が行われないことで利用者を危険にさらしてしまう可能性があることを認識し、設計の段階から更新作業を考慮して Web サイトを構築し運用を行う、または設定・更新作業を適切に実施するアウトソース先を選定することにより、利用者が常に安心してアクセスできる状態であるように努めることが Web サイト運営者に求められると考えます。

 

 

 

＜本件に関するお問い合わせ先＞
■フィッシング対策協議会 (JPCERT コーディネーションセンター内) 事務局
電話：03-6271-8905