HTTP/HTTPS のサムネイル

HTTP/HTTPS

⏱ 約 8 分 view 484 like 0 LOG_DATE:2025-10-14
目次 / TOC

HTTP は WWW でブラウザとサーバが HTML・画像・API レスポンスをやり取りするテキストベース通信プロトコル。トランスポートには TCP (HTTP/3 では QUIC = UDP) を使い、その上にリクエスト / レスポンス構造を載せる。HTTPS はこれを TLS で暗号化し、盗聴・改ざん・なりすましを同時に防ぐ。本稿はメッセージ構造・メソッド・ステータス・ヘッダ・Cookie・HTTP/1.x〜3 の進化・TLS ハンドシェイク・代表的なセキュリティ落とし穴までを通しで整理する。

01

HTTP の基本構造 #

HTTP は ステートレスなリクエスト・レスポンス型 のプロトコル。クライアントが要求を送り、サーバが応答を返す。この 1 往復を HTTP トランザクション と呼ぶ。サーバ側は基本的に過去のリクエストを覚えていない (= ステートレス)。状態を引き継ぐには Cookie / セッション / JWT などで補う。

通信内容はテキストベースの HTTP メッセージで、リクエスト行 / ステータス行 → ヘッダ → 空行 → ボディ の 4 ブロック構造。HTTP/2 以降はバイナリフレームに分割されるが、論理構造は変わらない。

リクエストの中身を読む
GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html,*/* Cookie: session=abc123 # ↑ 空行で区切ってボディ (GET なので無し)
  • リクエストライン — メソッド (GET) / パス (/index.html) / プロトコルバージョン (HTTP/1.1)
  • ヘッダ — 名前: 値 の形式で複数行。Host / User-Agent / Accept / Cookie / Authorization など
  • 空行 — ヘッダとボディの境界
  • ボディ — POST / PUT などで送るデータ本体 (フォーム / JSON)
レスポンスの中身を読む
HTTP/1.1 200 OK Date: Sun, 17 May 2026 00:00:00 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 1234 Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax # ↓ 空行のあとボディ <html> ... </html>

自分で送ってみる — メソッドとパスを入れて送信すると、サーバがステータスコード付きでレスポンスを返す流れを再現できる。/admin は 403、存在しないパスは 404、/old は 301 を返す。

02

HTTP メソッド #

メソッド 用途 ボディ 冪等性
GET リソース取得 なし あり
POST 新規作成 / 任意処理 あり なし
PUT リソース全体置換 あり あり
PATCH リソース部分更新 あり なし
DELETE リソース削除 任意 あり
HEAD ヘッダのみ取得 (GET のメタ情報版) なし あり
OPTIONS サポートメソッド問い合わせ (CORS プリフライトで多用) なし あり
▸ 冪等性とリトライ設計

冪等性 (idempotency) があるメソッドは「同じリクエストを何度送っても結果が変わらない」性質を持ち、ネットワーク失敗時に安全にリトライできる。POST は冪等でないため、二重送信防止 (Idempotency Key ヘッダや UI 側でのボタン無効化) の設計が必要になる。

03

ステータスコード #

3 桁の数字で、先頭の数字が大分類を示す。

系統 意味 代表例
1xx 情報 100 Continue / 101 Switching Protocols
2xx 成功 200 OK / 201 Created / 204 No Content
3xx リダイレクト 301 Moved Permanently / 302 Found / 304 Not Modified
4xx クライアント側エラー 400 Bad Request / 401 Unauthorized / 403 Forbidden / 404 Not Found / 429 Too Many Requests
5xx サーバ側エラー 500 Internal Server Error / 502 Bad Gateway / 503 Service Unavailable / 504 Gateway Timeout
▸ 401 と 403 は混同しやすい

401 Unauthorized は「認証していない」 (= ログインしろ)。403 Forbidden は「認証はしているが権限がない」 (= ログインしてもダメ)。API 設計では権限不足を 404 で返して存在自体を隠す流派もある。

04

重要な HTTP ヘッダ #

セキュリティ・パフォーマンスに直結するヘッダを列挙する。

リクエスト側:

  • Host — 仮想ホスト識別。1 つの IP で複数ドメインを区別する
  • User-Agent — クライアント識別。WAF や bot 検知の判定材料
  • Cookie — 過去にサーバから Set-Cookie で受け取った値を毎回送信
  • Authorization — Basic / Bearer <token> などの認証情報
  • Referer — 直前のページ URL (タイポではない、仕様で定着)

レスポンス側:

  • Set-Cookie — クライアントにクッキーを発行
  • Content-Type — MIME タイプ (例: application/json; charset=UTF-8)
  • Cache-Control — キャッシュ動作の指定 (no-store / max-age=3600)
  • Strict-Transport-Security (HSTS) — 強制的に HTTPS で接続させる
  • Content-Security-Policy (CSP) — スクリプト読み込み元を制限し、XSS を抑制
  • X-Frame-Options / CSP: frame-ancestors — クリックジャッキング対策
05

Cookie とセッション #

HTTP はステートレスなので、ログイン状態などを維持するには Cookie を使う。Set-Cookie で発行し、クライアントは以降のリクエストの Cookie ヘッダで送り返す。

セッションハイジャックを防ぐため、現代では以下の属性を必ず付与する。

属性 意味
Secure HTTPS でのみ送信。HTTP 経由では送らない
HttpOnly JavaScript の document.cookie から読み取れない。XSS で盗まれにくい
SameSite=Lax / Strict 別オリジンからのリクエストでは送信しない。CSRF 対策
Expires / Max-Age セッション Cookie か永続 Cookie かを制御
現代的に安全な Set-Cookie の例
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax; Max-Age=3600; Path=/ # Secure → HTTPS のみ送信 # HttpOnly → JS から読めない (XSS 緩和) # SameSite=Lax → CSRF 緩和 (別オリジンから自動送信されない)
06

HTTP のバージョン進化 #

バージョン 年 特徴
HTTP/1.0 1996 リクエストごとに TCP 接続を張る (重い)
HTTP/1.1 1997 Keep-Alive で接続再利用、パイプライン (実用化は限定的)
HTTP/2 2015 バイナリフレーム、多重化 で 1 接続で並列リクエスト、ヘッダ圧縮 (HPACK)
HTTP/3 2022 QUIC (UDP ベース) でハンドシェイクを最小化、パケットロス時の HoL ブロッキング解消
▸ Head-of-Line ブロッキングの 2 段階解消

HTTP/1.1 ではリクエストが順番待ちで詰まる。HTTP/2 は多重化でアプリ層の HoL を緩和したが、TCP の順序保証で 1 パケット欠損が後続全部を止める TCP 層 HoL が残った。HTTP/3 は QUIC が UDP 上にストリーム独立した多重化を実装することで、トランスポート層の HoL ブロッキングも解消する。

07

HTTPS と TLS ハンドシェイク #

HTTPS = HTTP + TLS (Transport Layer Security)。TLS は次の 3 つを同時に達成する。

  1. 暗号化 — 通信内容を第三者から見えなくする (機密性)
  2. 改ざん検知 — メッセージ認証コードで内容の改ざんを検知 (完全性)
  3. サーバ認証 — 証明書でサーバが本物だと確認 (真正性)

TLS 1.3 のハンドシェイクは 4 段階で完結する。

1. Client Hello
クライアントが対応する暗号スイート一覧と乱数を送る。
2. Server Hello
サーバが暗号スイートを選び、証明書と公開鍵を返す。
3. 鍵交換
Diffie-Hellman 鍵共有で セッション鍵 を双方で生成 (盗聴者には解読不能)。
4. Finished
ハンドシェイク完了。以降は AES-GCM などの対称暗号で通信。

TLS 1.2 までは 2 往復必要だったが、TLS 1.3 では 1 往復 (1-RTT)、再接続なら 0-RTT で済む。

サーバ証明書は 認証局 (CA) が発行する。クライアントは OS / ブラウザに同梱されたルート CA の公開鍵で証明書チェーン (サーバ証明書 → 中間 CA → ルート CA) を検証し、信頼できる場合のみ TLS 接続を完成させる。

種別 検証内容 例
DV (Domain Validation) ドメイン所有のみ確認 Let's Encrypt など無料発行
OV (Organization Validation) 組織実在性も確認 主要商用 CA
EV (Extended Validation) より厳格な実在性確認 旧緑バー表示は現在廃止
08

セキュリティ上の落とし穴 #

サーバ管理者・開発者の観点で注意したい代表例。

  • MITM (中間者攻撃) — 公衆 Wi-Fi などで攻撃者が経路に割り込み、リクエストを盗聴・改ざん。HTTPS と正しい証明書検証で防ぐ
  • SSL Stripping — HTTPS リダイレクトを攻撃者がブロックし、HTTP に降格させて盗聴。HSTS (Strict-Transport-Security) を返すことで以降ブラウザが HTTPS を強制
  • HSTS Preload — Chrome / Firefox 等が同梱するプリロードリストにドメインを登録すると、初回アクセスから HTTPS 強制
  • Mixed Content — HTTPS ページが HTTP リソース (画像 / スクリプト) を読み込むと TLS の保護が崩れる。upgrade-insecure-requests CSP ディレクティブで自動 HTTPS 化
  • Cookie 属性の不備 — Secure / HttpOnly / SameSite を付け忘れるとセッションハイジャック / XSS / CSRF のリスク
  • 証明書ピン留めの罠 — 厳格にピン留めしすぎると CA 更新時に通信不能。HPKP (HTTP Public Key Pinning) は廃止された
  • TLS 実装のバグ — Heartbleed (CVE-2014-0160) 等。OpenSSL を最新に保つことが防御の前提
▸ Burp Suite / mitmproxy の使い方と限界

ペネトレーションテストでは Burp Suite や mitmproxy で TLS 通信を 手元のローカル CA で復号して中身を確認する手法が定番。これは「証明書検証を一時的に緩める」操作で、本番運用では絶対に行わないこと。検証用 VM / 隔離環境でのみ使い、終わったらローカル CA をシステムから削除する。

𝕏 ポスト B! はてブ