目次

インターネットを流れるデータはデフォルトでは平文だ。HTTPはHyperText Transfer Protocolの略であり、設計当初はセキュリティよりも相互運用性が優先されていた。しかし現代のWebではパスワード、クレジットカード番号、個人情報といった機密データが常にやり取りされる。HTTPSは暗号化によってこれらの通信を保護する仕組みだが、その内部でどのような処理が行われているかを理解することは、セキュリティ上の判断を正確に行うために不可欠だ。

HTTP通信の危険性

HTTPは通信内容をそのまま送受信する。同一ネットワーク上（カフェのWi-Fiなど）に攻撃者がいる場合、パケットキャプチャツールを使えばHTTP通信のリクエスト・レスポンスを丸ごと読み取ることができる。これを**盗聴（Eavesdropping）**という。

さらに深刻なのが**中間者攻撃（Man-in-the-Middle Attack、MitM）**だ。攻撃者がクライアントとサーバーの通信経路に割り込み、送受信されるデータを改ざんする。悪意のあるスクリプトをHTMLに挿入したり、フォームの送信先を変更したりすることが可能になる。

HTTPSはこれらの攻撃に対して、暗号化（盗聴対策）、認証（相手の正当性確認）、整合性（改ざん検出）の3要素を提供する。

TLSとは何か

TLS（Transport Layer Security）はHTTPの下層で動作する暗号化プロトコルだ。HTTPSはHTTP over TLSの略であり、HTTPの通信をTLSが暗号化している。かつてはSSL（Secure Sockets Layer）と呼ばれていたが、現在の実装はほぼすべてTLS 1.2またはTLS 1.3だ。

TLSは対称暗号と**非対称暗号（公開鍵暗号）**の2種類を組み合わせて使う。それぞれの特性を理解することがTLSの仕組みを把握する鍵となる。

対称暗号

暗号化と復号に同じ鍵を使う方式だ。AES（Advanced Encryption Standard）が代表例で、計算コストが低く大量のデータを高速に処理できる。欠点は「同じ鍵を送受信者が事前に共有しておく必要がある」点だ。鍵の配送が問題になる。

非対称暗号（公開鍵暗号）

公開鍵と秘密鍵のペアを使う方式だ。RSAやECDHE（楕円曲線ディフィー・ヘルマン鍵交換）が代表例だ。公開鍵で暗号化したデータは対応する秘密鍵でのみ復号できる。計算コストが高いため、大量のデータ暗号化には向かない。

TLSはこの2種類を組み合わせる。非対称暗号で「対称暗号に使う共通鍵」を安全に交換し、以降の通信は対称暗号で処理するというアプローチだ。

TLSハンドシェイクの流れ

ブラウザがHTTPSサイトに接続する際、最初に「TLSハンドシェイク」と呼ばれるプロセスが実行される。TLS 1.3の場合、以下の手順で行われる。

1. Client Hello

クライアントがサーバーに対して接続要求を送る。このメッセージには以下の情報が含まれる。

  • クライアントが対応するTLSのバージョン
  • クライアントが利用できる暗号スイートの一覧
  • 乱数値（Client Random）
  • 鍵交換のための公開パラメータ

2. Server Hello

サーバーがクライアントへ応答する。

  • 選択したTLSバージョンと暗号スイート
  • 乱数値（Server Random）
  • サーバーの公開鍵

3. サーバー証明書の送信

サーバーはX.509形式のデジタル証明書を送る。この証明書にはサーバーの公開鍵と、認証局（CA）による署名が含まれる。

4. 鍵交換と共通鍵の生成

ECDHE（楕円曲線ディフィー・ヘルマン鍵交換）を使う場合、クライアントとサーバーはそれぞれの公開パラメータを交換し、数学的な計算によって同一の共通鍵（セッション鍵）を生成する。重要なのは、この鍵が通信路上を直接流れることなく、双方が独立して同じ値を計算できる点だ。

5. Finished / セッション開始

共通鍵が確立されると、以降の通信はAES-GCMなどの対称暗号で暗号化される。TLS 1.3ではハンドシェイクが1-RTT（1往復）で完了するよう最適化されている。

デジタル証明書と認証局

TLSハンドシェイクで重要な役割を果たすのがデジタル証明書だ。証明書は「このドメインの公開鍵は正当なものである」という事実を第三者機関が保証する仕組みだ。

証明書を発行するのが**認証局（Certificate Authority、CA）**だ。ブラウザやOSには、信頼できるCAのリスト（ルートCA証明書）が事前にインストールされている。

証明書の信頼性は**証明書チェーン（Chain of Trust）**によって確保される。

ルートCA証明書（ブラウザ/OSに組み込み済み）
    ↓ 署名
中間CA証明書
    ↓ 署名
サーバー証明書（ドメイン名と公開鍵を含む）

ブラウザはサーバー証明書を受け取ると、証明書チェーンを辿って最終的にルートCAの署名を検証する。この検証が成功すれば、証明書が改ざんされていないことと、信頼できる機関が発行したことが確認できる。

証明書には有効期限があり、通常は1〜2年だ。また証明書が漏洩した場合に無効化するための仕組みとして、CRL（Certificate Revocation List）やOCSP（Online Certificate Status Protocol）がある。

HSTSによる強制HTTPS化

HTTPSが正しく設定されていても、ユーザーが http:// でアクセスすることでHTTPリクエストが発生してしまう可能性がある。これを防ぐのが**HSTS（HTTP Strict Transport Security）**だ。

サーバーがHTTPSレスポンスに以下のヘッダーを付与すると、ブラウザはそのドメインへの通信を一定期間（max-ageで指定）強制的にHTTPSで行うようになる。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

preload を指定し、HSTS Preloadリストに登録されたドメインは、ブラウザが出荷時点からHTTPS接続を強制するため、最初の接続からHTTPが使われることがなくなる。

混在コンテンツ問題

HTTPSページ内でHTTPのリソース（画像・スクリプト・スタイルシートなど）を読み込む「混在コンテンツ（Mixed Content）」は深刻なセキュリティ問題を引き起こす。ページ自体は暗号化されていても、HTTPで読み込まれるリソースは盗聴・改ざんのリスクにさらされる。

現代のブラウザはスクリプトやスタイルシートのような「アクティブな混在コンテンツ」をデフォルトでブロックし、画像などの「パッシブな混在コンテンツ」については警告を表示する。

まとめ

HTTPは通信内容が平文のため、盗聴・改ざん・中間者攻撃に対して無防備だ。HTTPSはTLSによってこれらの脅威に対応する。TLSハンドシェイクでは非対称暗号を使って共通鍵を安全に交換し、以降の通信は高速な対称暗号で処理する。デジタル証明書と認証局の仕組みによって、接続先の正当性が検証される。HSTSを設定することで最初のHTTPリクエストも排除できる。現代のWebでHTTPSは必須の前提であり、その仕組みを理解することはセキュリティ設計の基礎となる。

#HTTPS #TLS #セキュリティ #暗号化

免責事項 — 掲載情報は執筆時点のものです。料金・機能は変更される場合があります。最新情報は各公式サイトをご確認ください。