本記事では、Web通信のデファクトスタンダードになっているHTTPSを支える技術であるTLSの解説を行います。HTTPSを使用することで、通信を盗み見されたり改善されるリスクを大幅に軽減できます。現在、WebサイトのHTTPS対応は必須であり、HTTPS対応がされていないWebサイトに対して、ブラウザが警告を出すようになっています。
HTTPSを利用するためには、TLSでクライアントとサーバーがセッションを確立できる必要があります。これには、デジタル証明書の運用、TLSのバージョンと暗号スイートといった要素が関わってきます。TLSの設定が誤っているとHTTPSでの通信ができず、ユーザーはWebサイトに繋がらなくなります。 そのため、サイトを安定して運用する際は、HTTPS(とそれを支えるTLS)の理解が必須となります。
この記事では、HTTPSとTLSがどのようにWeb通信を保護するのか、そしてそれがなぜ重要なのかを詳しく解説します。
HTTPS(HyperText Transfer Protocol Secure)とは
HTTPSは、安全なウェブ通信を提供するために用いられるプロトコルです。HTTPにセキュリティ層が加えられたもので、TLSを使用してデータを暗号化します。
HTTPSは、セキュリティの向上とプライバシー保護のために、通信相手の認証、通信の暗号化、データの完全性保証の3つの機能を提供します。
- 通信相手の認証: サーバーは、デジタル証明書を使用して自身の身元を証明します。これにより、ユーザーは信頼できるサイトと通信していることを確認できます。
- 通信の暗号化: データを暗号化することで、第三者によるデータの盗聴や傍受を防ぎます。これにより、インターネットを介した通信が安全に行われます。
- データの完全性保証: データが送信中に改ざんされないことを保証します。
HTTPSのプロトコルスタックは、次の図の通りです。
クライアントとサーバーがHTTPSで通信する際は、
- TCPのコネクション確立
- TLSのセッション確立
- HTTPで通信開始
という流れで行われます。 素のHTTPと比較すると、2のTLSのセッション確立が追加されています。
TLS(Transport Layer Security)とは
TLSは、前述した通りHTTPSで通信する際に必須になる技術です。HTTPSが提供している認証、暗号化、データの完全性保証の3つの機能はTLSによって支えられています。
TLSで通信を行う際に、サーバーはクライアントにデジタル証明書を提示します。 デジタル証明書には、サーバーが持つ秘密鍵と対になる公開鍵が含まれているため、これを使ってクライアントとサーバーの間で暗号化に使用するためのセッションキー(共通鍵)を安全に交換することができます。
クライアントとサーバーでTLSのセッションを確立するまでの大まかな流れは次の通りです。この手続きのことをTLSハンドシェイク(TLS Handshake)と呼びます。
- クライアントとサーバーが利用可能なTLSのバージョンや暗号化アルゴリズムをお互いに通知
- サーバーがデジタル証明書(と証明書に含まれる公開鍵)をクライアントに送信
- クライアントがセッションキー(共通鍵)の作成に必要な情報(プレマスターシークレット)を公開鍵で暗号化して安全に送信
- クライアントとサーバーの双方が、セッションキーを作成し、暗号化した通信の開始(HTTPSの通信開始)
ここでのポイントは、TLSは実際の通信の暗号化には共通鍵を用いますが、その共通鍵をクライアントとサーバーの双方で安全に生成するために公開鍵暗号方式を用いるという組み合わせで動作していることです。TLSでは
共通鍵暗号方式と公開鍵暗号方式に馴染みがない方はUdemyの記事をご覧ください。
なぜデジタル証明書を信頼できるのか？
先ほど、デジタル証明書に入っている公開鍵を使ってTLSの通信に必要なセッションキー(共通鍵)を生成するという話をしました。
では、サーバーが提示してきた証明書をクライアントが信頼する根拠はなんでしょうか？
証明書は誰でも作成することができるので、サーバーが証明書を提示してくるだけでは、サーバーを信頼することはできません。デジタル証明書の役割の1つは、サーバーを認証し、クライアントが信頼できるサイトと通信していることを確認できるようにすることでした。
これはどのように実現されているのでしょうか？
答えは、信頼できる認証局が証明書を発行しているからです。
Webサイトで使われる証明書は、認証局(Certificate Authority、CA)と呼ばれる組織によって発行されます。
クライアントであるWebブラウザやOSは、事前に信頼する認証局のリストを保有しているので、信頼する認証局(CA)が発行している証明書かを確認することで証明書を信頼するかを決めています。
認証局を信頼している、だから、その認証局が発行した証明書も信用するという論法です。
クライアントは、サーバーから受け取った証明書が信頼している認証局から発行されているか検証を行うことでサーバーを信頼します。
この検証には、デジタル署名と信頼の連鎖(Chain of Trust)という概念が関わってきます。
(※) 認証局が発行していない、証明書の事を自己署名証明書、通称オレオレ証明書と言います。このような証明書は、信頼できる認証局から発行されていないため、クライアント側で個別に信頼する設定をしないと検証が失敗し、TLSのセッション確立ができません。
デジタル署名と信頼の連鎖(Chain of Trust)
先ほど、信頼できるルートCAが発行しているデジタル証明書を信頼するという話をしましたが、基本的には、ルートCAが証明書を発行する代わりに中間CAと呼ばれる機関が証明書を発行します
これはセキュリティ上の理由です。 ルートCAの秘密鍵が危険にさらされると、システム全体が危険にさらされるため、通常は非常に厳重に保管され、使用されることがほとんどありません。中間CAが存在することで、ルートCAの秘密鍵を直接的なリスクから遠ざけることができます。
次の図は、サーバー証明書とそれに連なるCAの関係性を示しています。 サーバー証明書に含まれるデジタル署名は中間CAの秘密鍵でサインされています。
デジタル署名は、証明書の内容が改ざんされていないことを保証するために、証明書を発行したCAによって生成されます。署名では、証明書の内容がハッシュ関数を通じて処理された後、そのハッシュに対してCAの秘密鍵で暗号化が施されます。
これにより、このサーバー証明書は中間CAが認証して発行したということを技術的に示すことができます。また、中間CAの証明書はルート証明書の秘密鍵で署名されています。同じく、中間CAの証明書はルートCAが認証して発行したことを示すことができます。
この一連の流れを信頼の連鎖(Chain of Trust)と呼びます。クライアントは、ルートCAを信頼している。クライアントが信頼しているルートCAは中間CAを信頼している。ルートCAに信頼されている中間CAがサーバー証明書を発行している。だから、クライアントはサーバー証明書を信頼する。という連鎖になっています。
そして、クライアントのサーバー証明書の検証プロセスもこの流れに沿っています。
TLSハンドシェイクのサーバー証明書の送信時には、サーバー証明書と中間CA証明書が送信されます。ルート証明書はクライアントが持っているので送信されません。
クライアントは、受け取ったサーバー証明書の署名を中間CA証明書の公開鍵で検証、さらに中間CA証明書の署名をルート証明書の公開鍵で検証と繰り返します。無事に署名が検証でき、事前に持っていたルート証明書に繋がったことを確認することでサーバー証明書の検証を行います。
証明書の検証
証明書の検証では、証明書チェーンをたどってルート証明書に繋がることを検証するのに加えて、次の検証も行われます。
- 証明書の有効期限内か
- 接続先のドメイン名がCNかSANに含まれているか
- 証明書が失効していないか
これらを順に解説していきます。
証明書の有効期限内か
証明書には有効期限があります。現在は、Appleが証明書の有効期限が398日以内でないと有効な証明書と判断しないという方針にしたため、後述する3種類のどの証明書でもこれより短い有効期限でなければなりません。
下記はこのサイトで利用している証明書の有効期限です。2023年12月5日から2025年1月2日の394日間有効であることが分かります。
接続先のドメイン名がCNかSANに含まれているか
クライアントは、接続先サーバーのドメイン名が証明書のCN(Common Name)かSAN(Subject Alternative Name)が含まれていることを検証します。
CNとSANの主な違いは、CNが証明書で指定された主要なドメイン名を表すのに対し、SANはその証明書でセキュリティ保護を提供する追加のドメイン名やサブドメイン名を指定するために使用される点です。CNは古くからの概念で、一つのドメインのみを指定しますが、SANは複数のドメインやサブドメインを一つの証明書でカバーする柔軟性を提供します。SANにより証明書の管理が簡単になります。
下記はこのサイトで利用している証明書のCNとSANです。 このサイトは、証明書の管理を簡単にするために弊社のホームページである https://www.bloomblock.net/ と同じ証明書で保護をしています。そのため、SANにこのサイトのドメイン名 www.bloomblock.net が含まれるワイルドカード *.bloomblock.net を記載しています。
証明書では、ワイルドカードが利用可能であり、*.bloomblock.net を記載しておけば、今後 site.bloomblock.netや corp.bloomblock.net など他のサブドメインを追加した場合に証明書を発行し直す必要がありません。
ワイルドカードの注意点は、*.bloomblock.net には、 bloomblock.net が含まれないことです。 そのため、SANに明示的に bloomblock.net を追加しています。
証明書が失効していないか
証明書は、不正に発行されたり、秘密鍵が漏洩したりした場合に失効(Revoke)されることがあります。
証明書の取り消し状態を確認する方法にはCRLとOCSPの2つがあります。OCSPの方がリアルタイム性に優れるため、現在はOCSPが主流です。
- CRL（Certificate Revocation List）: 証明書が取り消された場合にその証明書をリストに追加します。クライアントはこのリストを確認して、証明書が取り消されたかどうかを判断します。
- OCSP（Online Certificate Status Protocol）: クライアントがリアルタイムで証明書のステータスを確認できるプロトコルです。証明書のシリアル番号をOCSPサーバーに問い合わせ、取り消し情報を即座に取得します。
下記はこのサイトで利用している証明書のOCSPでの問い合わせ先です。AWSのRoute53にて証明書の発行を行なっているため、Amazonが管理しているOCSPサーバーが問い合わせ先となっています。
デジタル証明書の種類
認証局が発行する際のチェックの厳格さに応じて、証明書は3種類に分類されます。
- DV(Domain Validation)証明書
- OV(Organization Validation)証明書
- EV(Extended Validation)証明書
DVのチェックが最も簡易であり、OV、EVと順にチェックが厳格になっていきます。
最もチェックが簡易なDV証明者では、そのドメインを管理する権限を持っていることだけチェックされます。DV証明書は、デジタル上でのチェックだけで発行されるため、証明書の発行や更新を簡単に自動化することができます。
また、DV証明書は無料で発行できるサービスも多く、ACM(Amazon Certificate Manager)やLet’s Encryptが有名です。
一方で、OV証明書はより厳格なチェックをした後で発行されます。認証局は、OV証明書の発行を申請した組織が合法的に存在することを商業登記簿や実際に連絡を行うことで確認します。また、DV証明書と同様に申請社がドメインを管理する権限を持っていることも確認します。
EV証明書は、OV証明書の発行の時よりも、より多くの法的文書などから詳細なチェックが行われ、発行されます。
無料で発行されることが多いDV証明書とは異なり、OV証明書とEV証明書は有料で認証局に申請を行い、発行して貰います。また、OV/EV証明書は、更新の際に認証局から新たに発行された証明書をサーバーやACMなどの証明書を管理するサービスにインポートするという作業が発生します。
そのため、OV/EV証明書とDV証明書の選択は、企業サイトの信頼性と証明書の発行費用 + 運用コストを天秤にかけて判断しましょう。もし判断に迷った時は、自社と同規模の会社の証明書を見る事をおすすめします。
Google Chromeでの証明書の確認方法は次の記事が参考になります。
Google ChromeでWebサイトのSSLサーバ証明書を調査、確認する
まとめ
HTTPSとそれを支えるTLSは、デジタル時代における私たちの情報の安全を保証するための重要な技術です。この記事では、TLSの仕組み、特にデジタル証明書について詳しく説明しました。
CDNを運用する際には、デジタル証明書の適切な運用が必要になります。証明書の導入に誤りがあるとユーザーがWebサイトに繋がらなくなるなど大きな影響があります。本記事が理解の助けになれば幸いです。
次回は、CDNを導入する際のHTTPSの設定方法を実践的な形で紹介します。
CDN入門の記事一覧ページはこちらです。
