第2回 HTTPSの詳細：超入門HTTPS
最近ではWebサイトを常時HTTPS対応させることが多い。今回は、HTTPSプロトコルの詳細や証明書、HTTPS化対応の方法などについて解説する。
本入門連載では、システム管理者やシステムエンジニアの方々を主な対象として、IT業界でよく使われる技術や概念、サービスなどの解説をコンパクトにまとめておく。
- 第1回「HTTPS（HTTP over SSL／TLS）とは」
- 第2回「HTTPSの詳細」（最終回）
HTTPSとは
「HTTPS（HTTP over SSL／TLS）」とは、簡単に言うと「SSL（Secure Sockets Layer)」や「TLS（Transport Layer Security）」で暗号化した通信路上でHTTPプロトコルを利用する技術である。SSLやTLSは、暗号化された通信路を実現するためのプロトコルの1つだ。
通常のHTTPを使った通信では、Webサーバ側のTCPのポート番号は（デフォルトでは）80番となっている。一方HTTPSの場合は443番でSSL／TLSのポートをリッスン（待ち受け）している。Webブラウザがこのポートに接続すると、最初にSSL／TLSで暗号化された通信路（コネクション）を確立し、それが成功したら、その上でHTTPプロトコルによる通信を行う。
HTTPとHTTPSによる通信の比較
HTTPによる通信では、Webサーバのポート80番に接続して、その上でHTTPのコマンドを送受信する。これに対してHTTPSでは、Webサーバのポート443番に接続後、SSLかTLSによって暗号化された通信路を開設し、その中でHTTPのコマンドを送受信する。通信内容は暗号化して保護されているので、どんなコマンドやデータがやりとりされているのかは、第三者には分からない。
HTTPSの通信確立の段取りをもう少し詳しく説明しよう。
HTTPプロトコルはステートを持たないプロトコルである。セッションの開始前にネゴシエーションを行わず、TCPで接続したらすぐにGETやPOSTなどの要求メソッドを送信して、サーバ側からの応答を待つことは既に超入門「HTTPプロトコル」で述べた。
これに対してHTTPSでは最初にSSL／TLSの通信路の開設処理を行う。SSL／TLSはステートを持つプロトコルであり、暗号化アルゴリズムの選択や証明書情報の交換、暗号化用の鍵データの交換などを行って通信路を開設する。それが完了すれば、後はその上でHTTPプロトコルのやりとりを行う。この部分はHTTPプロトコルだけで通信する場合と同じである。
HTTPSに関する規格
HTTPS関連の規格は、元々はNetscape NavigatorというWebブラウザに実装されていた、暗号化通信のための機能をベースにしている。当初はブラウザと一体化されていたが、SSL／TLSの部分が汎用の暗号化通信プロトコルとして分離され、独立したプロトコルとなった。
Webブラウザ以外でも、例えばメールのSMTPやPOP、IMAPプロトコルと組み合わせた「SMTP over SSL／TLS」「POP over SSL／TLS」「IMAP over SSL／TLS」などがある。
SSL／TLSプロトコルのバージョンについて次の表にまとめておく。
| バージョン | 概要 |
|---|---|
| SSL 1.0 | Netscape Navigatorに実装された最初のバージョン。既に廃止 |
| SSL 2.0 | 最初に公開されたSSL規格（1995年）。既に廃止 |
| SSL 3.0 | Netscape社が開発した、SSL 2.0の改善版（改善内容は暗号化やハッシュ化のアルゴリズムの追加や更新、脆弱性の改善など。以下同）。RFC 6101で定義（1996年）。POODLE脆弱性（ぜいじゃく）などにより、既に廃止 |
| TLS 1.0 | Internet関連の技術標準化団体IETFがリリースした、SSL 3.0の改善版（内部バージョン番号はSSL 3.1）。RFC 2246で定義（1999年）。脆弱性の発覚などにより、既に非推奨 |
| TLS 1.1 | TLS 1.0の改善版（内部バージョン番号はSSL 3.2）。RFC 4346で定義（2006年）。脆弱性の発覚などにより、既に非推奨 |
| TLS 1.2 | TLS 1.1の改善版（内部バージョン番号はSSL 3.3）。RFC 5246で定義（2008年） |
| TLS 1.3 | TLS 1.2の改善版（内部バージョン番号はSSL 3.4の予定）。現在は草案段階 |
| SSL／TLSの規格 | |
当初はSSL、現在ではTLSという名称になっているが（内部的には、SSL 1.0から連続したバージョン番号が付けられている）、このうちSSLプロトコルは現在では全て古いプロトコルとして廃止されている（そのため、本来ならば常時TLSなどと呼ぶべきだが、常時SSLと言うのが一般的である）。特にSSL 3.0には2014年10月にPOODLEという大きな脆弱性が見つかり、話題になったことで覚えているユーザーもいるだろう。
- 「プードル（POODLE）にかみつかれないためのIE対策」（Server & Storage）
- 「ちっともかわいくなかった、セキュリティ界の『POODLE』」（Security & Trust）
TLS 1.0や1.1でも、一部の暗号化アルゴリズムの扱いに脆弱性が見つかったことから、もう使わないことが望ましい。現在推奨されるプロトコルはTLS 1.2か1.3である。
SSL／TLSのバージョンは、例えばInternet Explorerではオプション画面で選択、確認できる。
使用するプロトコルの選択画面
これはWindows 10のInternet Explorerのオプション画面。暗号化通信で使用するプロトコルを選択できる。
（1）使用する暗号化プロトコルを選択する。SSL 3.0以前は既に非推奨なので使用しないこと。可能な限り新しいTLSを利用するのが望ましい。
ただし最近の新しいブラウザ（Microsoft EdgeやGoogle Chromeなど）ではこのようなプロトコルの選択画面は表示されず、脆弱性のない新しいプロトコルが自動的に利用されるようになっている。
SSL／TLSセッションの詳細
SSL／TLSによる暗号化通信路の確立までのシーケンスは次のようになっている。
SSL／TLSの開始までの処理
これは典型的なSSL／TLSの開始シーケンスの例。SSL／TLSのバージョンによって細部は異なるし、クライアント側を認証するオプションもある。SSL／TLSでは、最初に暗号化のアルゴリズムの選択やサーバ証明書の受け渡しなどを行う。次に暗号化のための共通鍵データの生成と（サーバの公開鍵を使っての）暗号化を行ってサーバに送信する。サーバ側では秘密鍵を使って共通鍵を取り出す。以後は共通鍵を使って通信内容を暗号化する。
もう少し詳しく見てみると、次のようになる。
- サーバ（Webサーバ）とクライアント（Webブラウザ）間の通信路は共通鍵暗号＊1方式で暗号化することにする。そのためには、暗号化のために使う共通鍵情報を、誰にも知られずに安全に、サーバとクライアント間で共有する必要がある
- サーバ側には、公開鍵暗号＊2のための証明書がインストールされている。サーバは公開鍵と秘密鍵を持っている
- サーバは最初にサーバ証明書や公開鍵などの情報をクライアントに送信する
- クライアントは受信したサーバ証明書に記載されているドメイン名が、アクセスしようとしているサーバのドメイン名と一致することを確認する
- クライアントは暗号化用の共通鍵データを生成して、サーバの公開鍵で暗号化し、それをサーバに返信する
- サーバは受信したデータを自分自身の秘密鍵で復号する。これでサーバは暗号化用の共通鍵を入手できる
- 暗号化や鍵情報交換のためのアルゴリズムなどは最初にお互いにネゴシエーションして決定する
- 以後は、お互いが持つ暗号化用の共通鍵を使ってデータを暗号化してから送信する
- 同じ情報をやりとりすると、いつも同じ結果になって通信の内容が漏えいしやすくなるので、乱数などを加えて通信データのランダム化を図る
SSL／TLSでは、通信内容を暗号化するために、サーバとクライアントは同じ1つの共通鍵を使っている。その鍵データをそのまま相手に送らず、サーバの公開鍵（と乱数データなど）で暗号化してから送信しているところが要点である。この方法を使うことにより、安全に共通鍵データを相手に送信できる。
＊1 共通鍵暗号とは、暗号化とその復号で同じ鍵を使う暗号化方式のこと。AESやDESなどがある。SSL／TLSでは、鍵情報交換フェーズで共通鍵の情報をサーバとクライアント間で共有し、以後の通信データの暗号化に使用する。
＊2 公開鍵暗号とは、暗号化とその復号で異なる鍵（公開鍵と秘密鍵）を使う暗号化方式のこと。公開鍵は第三者に知られてもよいし（むしろ積極的に配布する）、秘密鍵はその所有者のみが保持するべき情報である。データを公開鍵で暗号化した場合は秘密鍵でのみ復号できる（暗号データ送信としての利用）。
逆にデータを秘密鍵で暗号化した場合は公開鍵で復号できる（デジタル署名としての利用）。証明書情報を秘密鍵で暗号化して送信すれば、公開鍵を使って復号できるので、誰でもその正当性を検証できる。そのような証明書を作成できるのは、秘密鍵を持っている正当な所有者だけだからだ。以下の記事も参照のこと。
・マスターIT／暗号技術「暗号化の基礎」
SSL／TLSではさまざまな暗号化／改ざん検出アルゴリズムや鍵長などのパラメータを選択できる。そのため、Webブラウザは最初にサーバに対して自分自身が利用できるアルゴリズムなどのリストを送信する。サーバはその中からいずれかを選択して利用する。
暗号技術は日々開発・強化されているし、脆弱性が見つかって使用が推奨されなくなることもある。そのため、最新のセキュリティパッチを適用するなどして、Webサーバやクライアント、証明書などを常に最新の状態にしておくことが望ましい。
SSL／TLS初期化後の通信
以上のようにしてSSL／TLSの通信路が確立できれば、後はその通信路上でHTTPプロトコルを使った通信を行えばよい。この部分はHTTPでもHTTPSでも変わらない。Webブラウザのデバッグ機能を使えば、HTTPS通信であってもメソッドやその内容を確認できる。
HTTPSでの通信例
HTTPSであっても、上位のプロトコルは暗号化されていない場合のHTTPプロトコルと同じである。開発者ツールを使えばその通信内容を確認できる。
（1）Windows 10のMicrosoft Edgeでhttps://〜を使ってアクセスしてみる。
（2）開発者ツールで［ネットワーク］を選択する。
（3）HTTPSとなっている（実際にはTLS 1.2上でHTTP 1.1プロトコルが使われている）。
（4）GETやPOSTなどのメソッドが使われているのはHTTPの場合と同じ。
サーバ証明書
HTTPSではWebサーバにセットされている「サーバ証明書」が重要な役割を持つ。暗号化の鍵として利用されるだけでなく、そのWebサーバがある特定のドメインに属している正当なシステムであることを保証したり、ユーザーに対して、そのドメインが正規の組織が管理しているドメインであることを表明したりするからだ。サーバ証明書にはWebサーバの所有者の情報や公開鍵暗号システムで利用される公開鍵などが含まれ、それが発行者によって電子署名されている。
●サーバ証明書の種類
Webサーバにセットする証明書には次のように幾つかの種類がある。
| 種別 | 内容 |
|---|---|
| DV（Domain Validation） ドメイン認証型証明書 |
一番手軽なサーバ証明書。ドメインの正当な所有者であれば、メールなどで申し込み可能（物理的な個人／組織／団体として存在していなくてもよい）。比較的低コスト。無料のものもある |
| OV（Organization Validation） 実在認証型証明書 |
ドメインの所有者の組織や団体が実際に存在することを確認して保証する証明書。他人がある組織を偽って証明書を取得する、といった不正はできない （脆弱性や手続きのミスを除く） |
| EV（Extended Validation） 拡張実在認証型証明書 |
一番厳格な証明書。組織（会社など）が確実に存在し、社会的にもある程度の期間継続していて、さらに担当者なども実際に存在することが確認されるなど、かなり厳格な存在チェックが行われる。存在チェックが厳しくコストも高いが信頼性は一番高い |
| Webサーバ証明書の種類 | |
DVからOV、EVとなるにつれて所有者の存在確認などが厳しくなり、その分証明書としての信頼性が高くなるが、コストも上昇する。
もっとも、Let's Encryptのような無料の証明書サービスもあるので（次のリンク参照）、以前よりもHTTPS導入のためのハードルは低くなってきているのも事実である。
- Tech Basics「無料のHTTPS用証明書サービスLet's Encrypt」
以上のいずれかの証明書が使われていれば、Webブラウザのアドレスバーに暗号化を表す鍵マークなどが表示される。特にEV証明書の場合は、組織名が（ほとんどのブラウザでは）緑色で大きく表示されるなど、より特別に正当な組織であることが分かるようになっている。
サーバ証明書の種類の違いによる表示の違い
証明書の種類によって表示方法が異なる。これはWindows 10のMicrosoft Edgeの例。
（1）OVやDV証明書の場合はこのようなシンプルな鍵マークの表示になる。
（2）EV証明書の場合は組織名などが緑色で表示され、より信頼できるサイトであることが分かる。大手企業や金融機関などでの採用が多い。
証明書の詳細は次の通りである。
証明書の例
上記のサイトのWebサーバ証明書の詳細を表示させたところ（Internet Explorerによる表示）。
（1）証明書の発行者（証明機関）。
（2）「サブジェクト」は発行された証明書の対象を表す。
（3）証明書の署名などで使われているアルゴリズム。以前はSHA-1も使われていたが、脆弱性が見つかったので現在ではもう使われない。利用できるアルゴリズムなどの仕様は、SSL／TLSのバージョンや実装などによって変わっている。いつまでも古い証明書や実装を使い続けるのは危険である。
（4）証明書の発行対象のドメイン名（FQDN名）。この名前が正しく存在することを証明している。
（5）証明書の発行対象の組織情報（もしくは証明書販売業者の情報など）。
●サーバ証明書に使われているアルゴリズムに注意
サーバ証明書ではデータを符号化するためにさまざまな数学的アルゴリズムを利用できる。それらのうち、SHA-1を使った証明書は安全性が低いため（SHA-1の脆弱性が見つかったため）、現在では非推奨となっている。SHA-1を使った証明書（や、自己発行の、いわゆるオレオレ証明書）をインストールしてあるWebサイトへ接続するとWebブラウザが警告メッセージを表示するようになっている。
WebサイトのHTTPS化
現在HTTP（だけ）で運用しているWebサーバを全面的にHTTPS化（常時HTTPS化）する場合、サーバ証明書を導入してWebサーバの設定を変更するだけでは済まない。
さまざまなリソースをHTTPS経由でもアクセスできるように更新する他、今までHTTPでアクセスされてきた外部公開URLなどをHTTPSでのアクセスに切り替えさせる（リダイレクトする）対策も必要である。これを行わないと、今までブックマークされたり、告知していたりしたリンク情報（例：「http://〜」など）が急に全て無効になってしまうからだ。
HTTPS化する方法を全て説明するのは本記事の趣旨からは外れるので、ここでは主な作業項目だけを列挙しておく。
- サーバ証明書を用意して、HTTPだけでなく、HTTPS（SSL／TLS）でのアクセス「も」受け付けるように、WebサーバやWebサイト（ファイアウォール、負荷分散装置、なども含む）の設定を変更する
- HTTPSでのアクセスをHTTPに中継するようなリバースプロキシを使って、サイト全体をHTTPS化するという方法もある（Tech Basics「リバースプロキシ」参照）
- サイト内の全てのリソース（画像やスクリプト、CSS、他）へHTTPSでアクセスできるように、設定やコンテンツを直す
- 内部リンク（サイト内で利用しているリンクなど）をHTTPSのページを指すように変更する。一部のリソース（例：*.gifや*.jsなど）へのアクセスがhttp://〜のまま残って混在していると、アプリやブラウザでエラーになることが少なくない
- HTTP（http://〜）でアクセスされた場合は、HTTPSへのリンク（htts://〜）へリダイレクトさせるように設定する
- sitemap.xmlなどの検索エンジンbot制御用のファイルも設定を変更する
- Google Search ConsoleやGoogle Analyticsといった分析ツールにHTTPSのサイトの設定を加える
本記事ではHTTPSプロトコルについて簡単にまとめてみた。WebサイトのHTTPS化／常時SSL化には、通信内容の暗号化による情報漏洩の防止だけでなく、SEO対策やサイトの高速化など、さまざまなメリットがある。まだ移行していないなら、ぜひ移行・導入を検討するべきだろう。
Copyright© Digital Advantage Corp. All Rights Reserved.