【実務・中級編】HTTP/2クリアテキスト通信(h2c)の仕様とセキュリティリスク – HTTPプロトコル・通信規格実践ガイド

はじめに：暗号化の鎧を脱ぎ捨てたHTTP/2、その「甘い罠」と実務的リスク

ネットワークエンジニアとして現場を渡り歩いていると、「なぜか社内システムのマイクロサービス間通信だけHTTP/2の恩恵を受けられない」「TLSのハンドシェイクオーバーヘッドを極限まで削ぎ落としたい」といった、泥臭くも切実な相談をよく受ける。

HTTP/2といえば、1つのTCPコネクション上で複数のリクエストとレスポンスを同時に多重化（マルチプレクシング）し、あの忌々しい「Head-of-Line Blocking（行頭ブロック）」を華麗に回避するモダンWebの旗手だ。当然、ブラウザの仕様やRFCの建前上、HTTPS（TLS）上で動く暗号化された世界（識別子：`h2`）が標準であり、正義とされている。

しかし、その裏で密かに存在感を放ち、そしてインフラエンジニアを夜も眠れなくさせている規格がある。それが、暗号化の鎧をあえて脱ぎ捨てたクリアテキスト版HTTP/2、「h2c（HTTP/2 Cleartext）」だ。

今回は、このh2cがどのようなメカニズムで立ち上がり、実務においていかに強烈なセキュリティリスクを孕んでいるのか、プロトコルの深淵を覗きながら紐解いていこう。

—

1. h2cの仕様と「アップグレード」のメカニズム

そもそも、なぜHTTPSが必須とされるHTTP/2において、クリアテキストの「h2c」が必要とされるのか。最大の理由は、「ロードバランサー（LB）やAPI Gatewayと、バックエンドのコンテナ群（マイクロサービス）の間でのオーバーヘッド削減」にある。

通常、パブリックなインターネット側はTLSで完全武装（h2）させ、プライベートな内部ネットワーク（VPC内など）では、暗号化/復号のCPU負荷を避けるために平文（h2c）で高速に通信させたい、というアーキテクトの欲望を満たすためにこの仕様が存在する。

では、クライアントとサーバーは、どうやって「暗号化なしでHTTP/2に切り替えようぜ」と合意するのだろうか？ここに、HTTP/1.1からHTTP/2へシームレスに移行するための巧妙な仕組みがある。

h2cを確立する2つのアプローチ

h2cの開始方法には、大きく分けて2つのアプローチ（モード）が用意されている。

1. Prior Knowledge（事前の知識）モード

最初から「このサーバーはh2cを喋れる」と分かっている場合、クライアントは接続直後からHTTP/2の接続プレフェース（Magic）を叩き込む。無駄なネゴシエーションがないため最速だが、平文でHTTP/2を話せないサーバーにこれをやると即座にコネクションが切断される。

2. Upgrade（HTTP/1.1からの昇格）モード

クライアントは最初は通常のHTTP/1.1でリクエストを投げ、「このコネクション、HTTP/2に格上げしない？」とサーバーに打診する。サーバーがそれを許可すれば、そのまま同じTCPコネクション上でHTTP/2のセッションが開始される。

実務でよく見かけるのは、後者の「Upgradeモード」のフローだ。実際のパケットのやり取りがどうなっているのか、その美しくも危ういシーケンスを見てみよう。

—

2. 通信フロー（シーケンス図）とプロトコルの挙動

HTTP/1.1のコネクションから、華麗にh2cへと変異（アップグレード）していくプロセスを時系列で追う。

パラメーターとヘッダーの裏側を覗く

このフローの中で、特に重要な役割を果たしているのが以下の3つのHTTP/1.1ヘッダーだ。

`Upgrade: h2c`
「HTTP/2のクリアテキストで話したいです」という強い意志表示。
`HTTP2-Settings`
HTTP/2の初期設定（最大同時ストリーム数やウィンドウサイズなど）をBase64urlエンコードしてサーバーに伝える。サーバー側はこれを元にHTTP/2のネゴシエーション環境を構築する。
`Connection: Upgrade, HTTP2-Settings`
プロキシサーバーやロードバランサーに対して、「このヘッダー（UpgradeとHTTP2-Settings）は次のホップに転送せず、ここで処理してくれ」と指示するHOP-by-HOPヘッダーの指定。

サーバーがこれを受理すると、`101 Switching Protocols` という懐かしいHTTPステータスコードを返し、その瞬間にテキストベースの世界から、HTTP/2の厳格なバイナリフレーム（Binary Framing）の世界へと突入する。

—

3. なぜ「h2c」は危険なのか？セキュリティリスクの正体

「社内ネットワーク（VPC内）だから盗聴されるリスクは低い」「パフォーマンスが正義だ」と安易にh2cを採用すると、セキュリティ監査で痛い目をみる。あるいは、悪意ある攻撃者に足元をすくわれる。

h2cが抱える最大のセキュリティリスク、それは「暗号化の欠如」と「ダウングレード攻撃への脆弱性」だ。

1. 平文通信ゆえの盗聴と改ざん（Sniffing & Tampering）

h2cは名前の通りCleartext（平文）である。つまり、パケットキャプチャツール（Wiresharkやtcpdumpなど）を叩けば、ヘッダーもボディも丸見えだ。Authorizationヘッダーに含まれるベアラートークンやセッションCookieが、社内LANのどこかのスイッチングハブでミラーリングやARPスプーフィングによって容易に抜き取られるリスクと常に隣り合わせとなる。

2. HTTP/1.1の脆弱性を引き継ぐ「h2c Smuggling（HTTPリクエストスマグリング）」

ここがネットワークエンジニアとしての腕の見せ所であり、最も警戒すべきポイントだ。
フロントにTLS終端を行うリバースプロキシ（NginxやEnvoyなど）を置き、バックエンドへの転送にh2cを使っているシステムを想像してほしい。

悪意ある攻撃者が、フロントのプロキシに対して巧妙に細工したHTTP/1.1の`Upgrade`リクエストを送りつける。プロキシがこれを適切にサニタイズせず、あるいはバックエンドとの通信でh2cへの切り替え処理に不備がある場合、フロントとバックエンドの間で解釈のズレ（Ambiguity）が生じ、裏側のプライベートなAPIへ不正なリクエストが直撃する「h2cスマグリング」が成立してしまう。

結果として、セキュリティ境界（WAFや認証レイヤー）をいとも簡単にバイパスされ、内部の機密データが抜かれる最悪のシナリオに繋がるのだ。

—

4. モダンブラウザの冷たい現実（サポート状況）

「ブラウザから直接h2cのサーバーにアクセスして高速化したい！」と考えているWebフロントエンドエンジニアがいたら、今すぐその夢から覚めさせてあげてほしい。

主要なモダンブラウザ（Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge）は、暗号化されていないHTTP/2（h2c）のサポートを完全に拒絶（あるいは最初から非搭載）している。

なぜブラウザはh2cを実装しないのか？
理由の9割以上は「セキュリティ（Mixed Contentポリシーや安全でないネットワークの排除）」、そして残りの1割は「仕様の複雑化を防ぐため」だ。
W3CおよびIETFの潮流としても、Webの完全暗号化（Always-On TLS）がデフォルトであり、平文のHTTP/2をブラウザが解釈するメリットよりもリスクの方が圧倒的に高いと判断されている。

したがって、h2cが活躍できる舞台は、ブラウザからエンドユーザーへの通信ではなく、サーバー間（Microservices / Service Mesh）の通信、あるいは開発・デバッグ環境に限定される。

—

5. 実践：h2cの動作確認とデバッグ手法

机上の空論はここまでにして、実際に手を動かしてh2cの挙動を確認してみよう。開発環境でのテストや、バックエンドAPIの疎通確認で役立つTipsだ。

今回は、Pythonの軽量なHTTP/2ライブラリを用いたテストサーバーの構築と、`curl`コマンドによる検証手順を紹介する。

サーバー側の実装例（Python + `h2` ライブラリ）

まずは、h2c（Prior Knowledgeモード）を受け付ける最小限のTCPサーバーをPythonで書いてみる。標準ライブラリのソケットを拡張し、HTTP/2のフレームを直接さばく骨太なコードだ。

import socket
import h2.connection
import h2.events

def handle_client(sock):
# HTTP/2 コネクションのインスタンスをサーバーとして初期化
conn = h2.connection.H2Connection(client_side=False)
conn.initiate_connection()

sock.sendall(conn.data_to_send())

while True:
data = sock.recv(65535)
if not data:
break

# 受信したバイナリデータをHTTP/2ステートマシンに流し込む
events = conn.receive_data(data)
for event in events:
if isinstance(event, h2.events.RequestReceived):
stream_id = event.stream_id
headers = event.headers
print(f”[DEBUG] リクエスト受信 (Stream ID: {stream_id})”)
for name, value in headers:
print(f” {name.decode()}: {value.decode()}”)

# レスポンスヘッダーの送信
response_headers = [
(‘:status’, ‘200’),
(‘content-type’, ‘text/plain; charset=utf-8’),
(‘server’, ‘h2c-test-server/1.0’)
]
conn.send_headers(stream_id=stream_id, headers=response_headers)

# レスポンスボディの送信
conn.send_data(stream_id=stream_id, data=b”Hello from h2c backend!\n”, end_stream=True)

# 送信すべきデータがあればフラッシュ
out = conn.data_to_send()
if out:
sock.sendall(out)

sock.close()

def run_server():
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server.bind((‘127.0.0.1’, 8080))
server.listen(5)
print(“[INFO] h2c テストサーバーが 127.0.0.1:8080 で起動しました…”)

try:
while True:
sock, addr = server.accept()
print(f”[INFO] 接続確立: {addr}”)
handle_client(sock)
except KeyboardInterrupt:
print(“\n[INFO] サーバーを停止します。”)
server.close()

if __name__ == ‘__main__’:
run_server()

クライアント側の検証（`curl` コマンド）

次に、上で立ち上げたh2cサーバーに対して、`curl`コマンドを使ってリクエストを飛ばしてみよう。
最新の`curl`はHTTP/2を標準サポートしているが、明示的にクリアテキストを指定する必要がある。

Prior Knowledgeモード（暗号化なしHTTP/2）でリクエストを送信
curl –http2-prior-knowledge http://127.0.0.1:8080/

実行結果のイメージ：

Hello from h2c backend!

もしサーバー側がHTTP/2に対応しておらず、単なるHTTP/1.1サーバーだった場合は、`curl`は以下のようなエラーを吐いて即座に音を上げる。

curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

このエラーメッセージを見たら、「あ、サーバーがh2cを理解していない、あるいはTLSを要求しているな」と直感的にデバッグできるようになれば、あなたも立派なプロトコルスペシャリストだ。

—

6. まとめとインフラ設計への教訓

ここまで、HTTP/2クリアテキスト通信（h2c）の仕様、通信フロー、そして実務上のリスクについてディープに解説してきた。

最後に、シニアネットワークエンジニアとして現場の設計者たちに伝えたい教訓を記す。

1. パブリックインターネット側では絶対に使わない

ブラウザが拒絶するのはもちろん、盗聴やスマグリングの温床になるため、エンドユーザー向けの通信経路にh2cを選択する理由はゼロである。

2. ゼロトラスト時代の内部ネットワーク（East-West通信）における再考

「社内だから安全」という神話はすでに崩壊している。マイクロサービス間であっても、可能であればmTLS（相互TLS）を導入し、暗号化をデフォルトとすべきだ。どうしてもレイテンシーやCPU負荷の観点でh2cを採用せざるを得ない場合は、信頼された閉域網（完全な物理/論理分離環境）に限定し、アクセス制御を厳重に掛けよう。

3. プロキシの設定ミスに細心の注意を払う

NginxやEnvoyなどのリバースプロキシでバックエンドへh2cフォワードを行う際は、HTTP/1.1のUpgradeヘッダーの伝播やサニタイズが正しく行われているか、セキュリティテストを必ず通すこと。

プロトコルの裏側にある「パケットの息吹」を感じ取れるようになると、インフラやAPIの設計は劇的に面白くなる。ぜひ、今日の知見を日々のアーキテクチャ設計やトラブルシューティングに役立ててほしい。