HTTPS通信を支える3つの安全対策
🔒 はじめに
Web通信は、私たちが思っている以上に多くのリスクにさらされています。
もし通信が暗号化されていなければ、第三者に内容を盗み見られたり、途中で書き換えられたり、偽サイトに誘導されたりする危険があります。
こうした脅威を防ぐために登場したのが HTTPS（HTTP Secure）。
この記事では、HTTPSがどのようにして「盗聴」「改ざん」「なりすまし」を防いでいるのかを、できるだけ分かりやすく解説します。
🕵 1. 盗聴を防ぐ ― 通信の暗号化
🔍 問題
HTTP通信は平文（そのままの文字）で送られます。
そのため、ネットワークの途中にいる誰かが通信を覗くと、ユーザー名やパスワードなどの機密情報を簡単に盗めてしまいます。
🔙 昔：RSA方式（公開鍵暗号による鍵共有）
2000年代〜2010年代前半まで、HTTPSの通信ではRSA（公開鍵暗号）が広く使われていました。
この方式では、サーバーの公開鍵と秘密鍵がペアになっています。
🧩 仕組みの流れ
- サーバーが「公開鍵＋秘密鍵」を生成し、公開鍵を証明書としてクライアントに渡す。
- クライアントは「このサーバーの公開鍵で暗号化」した共通鍵を送信。
- サーバーが「自分の秘密鍵で復号」して共通鍵を取得。
- 以降の通信は、その共通鍵を使って**対称暗号（AESなど）**で暗号化。
⚠️ 問題点（RSAの限界）
• 前方秘匿性がない：
サーバーの秘密鍵が流出すると、過去の通信をすべて復号できてしまう。
• 負荷が重い：
RSAは大きな整数の計算（2048bit以上）が必要でCPU負担が高い。
➡ これらの問題を解決するために、現在主流の ECDHE方式 に移行しました。
🔒 現在：ECDHE方式（楕円曲線Diffie-Hellman鍵交換）
🔍 背景
TLS1.2以降、特にTLS1.3では「RSAによる鍵交換」は廃止され、
ECDHE（Ephemeral Elliptic Curve Diffie-Hellman） が標準方式になりました。
これは「公開鍵・秘密鍵を使って直接暗号化」するのではなく、
計算によって同じ共通鍵を導く方式です。
🧮 仕組みの流れ（簡略）
- サーバーとクライアントは、それぞれ一時的な秘密値を生成。
- クライアント：秘密値 a
- サーバー：秘密値 b - 双方が「公開値」を計算して交換。
- クライアント：A = aG
- サーバー：B = bG - 双方が自分の秘密値と相手の公開値から同じ共通鍵を計算。
- クライアント：K = aB = abG
- サーバー：K = bA = abG - 第三者はAとBを見てもa,bを知らないため、Kを導けない。
✏️ 2. 改ざんを防ぐ ― データの完全性検証
🔍 問題
通信の途中で悪意ある第三者が、送信データを勝手に書き換えてしまう危険があります。
例えば「振込先口座番号」や「金額」がすり替えられる、といったケースです。
🔑 解決策：HMAC（メッセージ認証コード）
TLSでは、送信データに「ハッシュ値（署名のような指紋）」を付けて送信します。
受信側は同じ方法でハッシュを再計算して、内容が一致するか確認します。
• 一致する → 改ざんされていない
• 一致しない → 改ざん検出 → 通信破棄
💡 ポイント
• HMACやAEAD（AES-GCMなど）で暗号化＋改ざん検知を同時に行う。
• 1ビットでも内容が変わると検出されるほど強力。
🎭 3. なりすましを防ぐ ― サーバーの正当性認証
🔍 問題
攻撃者が「本物そっくりの偽サイト（例：paypa1.com）」を作り、ユーザーを騙して個人情報を奪うことがあります。
🔑 解決策：デジタル証明書（SSL証明書）
HTTPSでは、サーバーが認証局（CA）から発行された「証明書」をブラウザに提示します。
この証明書は、CAの電子署名付きで「このサーバーは本物である」と保証するものです。
1. サーバーが証明書を提示
2. ブラウザがその署名をCAの公開鍵で検証
3. 問題なければ「安全なサイト」として通信開始
💡 ポイント
• 証明書の署名にはサーバーの秘密鍵が使われる。
• ブラウザはあらかじめCAの公開鍵を内蔵しており、信頼できる発行元かを自動で確認。
まとめ
HTTPSは「暗号化」「完全性」「認証」の三本柱で通信を守っている。
だからこそ、Webの世界では「HTTPS対応」が当たり前になっているのです。
Discussion