HTTPSプロトコルとは

HTTPSプロトコル = HTTPプロトコル+TLS(SSL)プロトコル

TLS暗号化通信の前提知識

TLS（Transport Layer Security）は、インターネット上で安全な通信を実現するプロトコルです。HTTPSのSの部分がTLSに相当し、WebサイトやAPIの通信を暗号化して盗聴や改ざんから守ります。

TLS通信では「対称暗号」と「非対称暗号（公開鍵暗号）」という2つの暗号化方式を組み合わせて使用します。対称暗号は同じ鍵で暗号化と復号を行う高速な方式で、非対称暗号は公開鍵と秘密鍵のペアを使う安全性の高い方式です。

TLSハンドシェイクの流れ

TLS通信を開始する際の「TLSハンドシェイク」という手順を、身近な例で説明します。これは、初対面の人と安全に秘密の会話を始めるための段取りに似ています。

Step 1: Client Hello（クライアントからの挨拶）

クライアント（ブラウザなど）がサーバーに「こんにちは、暗号化通信をしたいです」と挨拶します。この時に以下の情報を送信します。

対応可能なTLSバージョン（TLS 1.2、TLS 1.3など）
対応可能な暗号化方式の一覧（暗号スイート）
ランダムな値（Client Random）
サーバー名（SNI - Server Name Indication）

これは「私はこれらの暗号化方式に対応していますが、どれを使いますか？」という提案のようなものです。

Step 2: Server Hello（サーバーからの返答）

サーバーがクライアントの提案を受けて、使用する暗号化方式を決定し返答します。

選択したTLSバージョン
選択した暗号スイート
ランダムな値（Server Random）
サーバーのデジタル証明書

この段階で「この暗号化方式を使いましょう」という合意が成立します。

Step 3: Certificate Verification（証明書の検証）

クライアントがサーバーから受け取ったデジタル証明書を検証します。これは身分証明書の確認に相当します。

証明書には以下が含まれています：

サーバーの公開鍵
サーバーのドメイン名
証明書の有効期限
認証局（CA）のデジタル署名

クライアントは、信頼できる認証局によって署名されているか、有効期限内か、ドメイン名が一致するかなどを確認します。

Step 4: Key Exchange（鍵交換）

ここが最も重要な部分です。実際の通信で使用する「共通の秘密鍵」を安全に共有します。

従来の方式（RSA鍵交換）：

クライアントがランダムな値（Pre-Master Secret）を生成
サーバーの公開鍵でこの値を暗号化してサーバーに送信
サーバーが自身の秘密鍵で復号

現代の方式（ECDHE鍵交換）：

クライアントとサーバーがそれぞれ一時的な鍵ペアを生成
公開鍵を交換
数学的な計算により同じ共通鍵を導出

ECDHE方式の利点は「前方秘匿性」です。後から秘密鍵が漏洩しても、過去の通信は解読されません。

Step 5: Session Key Generation（セッション鍵の生成）

クライアントとサーバーが、交換した情報から実際の通信で使用する対称暗号の鍵を生成します。

以下の値を組み合わせて鍵を導出します：

Pre-Master Secret（または共有秘密）
Client Random
Server Random

この計算により、両者が同じセッション鍵を持つことになります。

Step 6: Finished Messages（完了メッセージ）

最後に、お互いが正しく鍵を共有できたことを確認します。

クライアントが「Finished」メッセージを新しい鍵で暗号化して送信
サーバーがこれを復号できれば、鍵共有が成功
サーバーも「Finished」メッセージを暗号化して返信
クライアントが復号できれば、双方向の確認完了

実際の暗号化通信開始

ハンドシェイクが完了すると、以降のHTTPリクエスト・レスポンスは全て生成されたセッション鍵で暗号化されます。対称暗号は高速なので、大量のデータも効率的に暗号化できます。

TLS 1.3での改善点

最新のTLS 1.3では、ハンドシェイクが簡素化され高速化されています。

ラウンドトリップが2回から1回に削減
より安全な暗号スイートのみサポート
0-RTT（Zero Round Trip Time）による再接続の高速化

まとめ

TLSの暗号化通信開始は、「お互いの身元確認」→「暗号化方式の合意」→「安全な鍵交換」→「通信開始」という段階的なプロセスです。公開鍵暗号で安全に共通の秘密鍵を共有し、その後は高速な対称暗号で実際の通信を暗号化することで、セキュリティと性能の両立を実現しています。

TLS通信における認証局との通信

基本的なTLS通信ではクライアントは認証局と直接通信しない

通常のTLS通信（HTTPS接続）では、以下の手順で進みます：

クライアント（ブラウザ）がサーバーに接続
サーバーが自身のSSL証明書を送信
クライアントが証明書の署名を検証
暗号化通信開始

この段階では、認証局サーバーと直接通信していません。証明書の検証は、クライアント側に事前にインストールされているルート証明書を使って行われます。

証明書の失効確認で認証局と通信する

しかし、証明書が「失効していないか」を確認する際に、認証局が提供するサーバーと通信することがあります。これには主に2つの方法があります。

CRL（証明書失効リスト）による確認

CRLは認証局が現在失効している全証明書のリストで、サーバ証明書に設定されています。各ウェブブラウザは、証明書の署名検証時にCRLをダウンロードし、該当の証明書がCRLに含まれていないかを照合します。

1. ブラウザが証明書を受信
2. 証明書に記載されたCRL配布ポイント（URL）にアクセス
3. 認証局サーバーからCRLファイルをダウンロード
4. 受信した証明書がCRLに含まれていないかチェック

OCSP（オンライン証明書ステータスプロトコル）による確認

より効率的な方法として、OCSPは、単一の証明書のステータスについて確認するためのhttpプロトコルです。ウェブブラウザはhttpのパケットに証明書ステータス確認要求（以下、OCSPリクエスト）を追加して、オンラインでOCSPサーバに要求します。

1. ブラウザが証明書を受信
2. 証明書に記載されたOCSPサーバーのURLを確認
3. OCSPサーバーに証明書のシリアル番号で問い合わせ
4. OCSPサーバーから失効状況の回答を受信

CRLはある程度大きなサイズのファイルをダウンロードしてチェックするという2段階の手順が必要なため一定程度の時間を要しますが、OCSPでは非常に短時間で結果を入手できます。

実際の通信の流れ

一般的なHTTPS接続の場合

ユーザー ←→ ウェブサーバー（通常のTLS通信）
    ↓
ユーザー ←→ 認証局のOCSP/CRLサーバー（失効確認）

詳細な手順

TLSハンドシェイク開始: ユーザーとウェブサーバー間
証明書受信: サーバーからSSL証明書を受信
署名検証: ローカルのルート証明書で検証
失効確認: 認証局が失効確認を行う対象となる証明書を発行する際、証明書の拡張領域である「認証機関アクセス情報(Authority Information Access, AIA)」に、OCSPレスポンダのURLを記載することができる
OCSPサーバーへ問い合わせ: 認証局のサーバーと通信
失効状況確認: 証明書が有効であることを確認
TLS通信継続: 暗号化通信を開始

OCSP Staplingによる最適化

現代では、この問題を解決する「OCSP Stapling」という仕組みが普及しています。

SSLサーバ証明書を利用するサーバーが、認証局が提供するOCSPサーバーの情報をキャッシュして、証明書とともにブラウザなどのクライアントに提供する方法をOCSP Staplingと呼びます。

従来の方法：
ユーザー → ウェブサーバー（証明書受信）
ユーザー → 認証局（OCSP確認）← 追加の通信が発生

OCSP Stapling：
ウェブサーバー → 認証局（事前にOCSP情報取得）
ユーザー → ウェブサーバー（証明書＋OCSP情報を一緒に受信）

ブラウザでの設定と現実

ブラウザの実装

多くのブラウザでは、証明書の失効確認が有効になっています。ただし、SSL通信を開始する際にOCSPサーバーに問い合わせ、有効であることを確認してからSSL通信を開始することができる一方で、OCSPサーバーへの接続が失敗した場合でも通信を継続することが多いです。

ユーザーが意識しない理由

高速処理: OCSP問い合わせは数百ミリ秒程度で完了
並行処理: TLS通信と並行して失効確認が実行される
キャッシュ機能: 一度確認した結果は一定時間キャッシュされる
OCSP Stapling: サーバー側で事前に確認済みの場合が多い

まとめ

TLS通信では、証明書の失効確認のために認証局のサーバーと通信することがあります。これは主に以下のタイミングで発生します：

CRLファイルのダウンロード時
OCSP問い合わせ時
証明書チェーンの中間CA証明書の確認時

ただし、この通信は通常のユーザーには意識されません。なぜなら、ブラウザが自動的に背景で処理し、OCSP Staplingなどの最適化技術により、追加の通信を最小限に抑える仕組みが整備されているからです。

現代のWebでは、セキュリティを保ちながらもユーザー体験を損なわないよう、これらの仕組みが透明に動作しています。