CloudflareがTLS再試行を52%から3.7%へ激減、p90を150ms短縮

• 事実と背景：Cloudflareが鍵合意アルゴリズムを事前測定する新機能を導入し、リトライ発生率を52%から3.7%へ大幅削減した。
• 技術的変革：PQCハイブリッド鍵共有を初回から提示可能とし、不要な1RTT発生を防いでp90遅延を150ms以上短縮した。
• 現場への影響：ゾーン単位の強制設定による接続全損リスクに留意しつつ、BoringSSL等による自社オリジンの対応確認が求められる。

深夜のオンコールやインフラの性能調査で、CDNエッジと自社オリジンサーバー間のレイテンシが想定より1往復（1RTT）分だけ不気味に膨らんでいる現象に頭を抱えた経験はないだろうか。TCPコネクションは正常、ルーティングも問題ない。それでも発生する数百ミリ秒のオーバーヘッドの正体こそ、TLS 1.3ハンドシェイクにおける鍵合意の不一致、すなわち「HelloRetryRequest（HRR）」である。

TLS 1.3は接続確立を1RTTで完了させる極めてアグレッシブなプロトコルだ。しかし、この高速化は「クライアントが最初のClientHelloパケットで、サーバーが好む鍵合意アルゴリズムを言い当てる」という危うい前提の上に成り立っている。推測が的中すれば1RTTで暗号化通信が始まるが、外れればサーバーからHelloRetryRequestが返され、クライアントは鍵共有を作り直して2回目のClientHelloを送らなければならない。これによってハンドシェイクは丸々2RTTを消費し、特に大陸間通信やモバイル回線、クラウド間のバックホールでは致命的なレイテンシ悪化を招く。

これまでCloudflareは「インターネット上の95%以上のオリジンがサポートしている」という統計的合理性を盾に、すべてのオリジンに対して古典的楕円曲線暗号であるX25519の鍵共有を一律で投げつけるという静的な決め打ちを行ってきた。しかし、実測データが暴き出した現実は惨憺たるものだった。実にオリジン接続の約30%においてこの推測は最適解ではなく、さらに6%以上のオリジンはX25519よりもP-256やP-384を明確に優先していたのだ。つまり、数百万ものWebサイトが、古典暗号同士のハンドシェイクであるにもかかわらず、Cloudflareの画一的な推測のせいで毎日無駄なHRRと1RTTのペナルティを払い続けていたのである。我々インフラエンジニアがどれほどNginxやGoのチューニングに心血を注ごうと、プロキシの手前で無邪気に1RTTが浪費されていたという事実は、背筋が寒くなるような設計上の盲点だったと言わざるを得ない。

事態をさらに複雑化させていたのが、耐量子計算機暗号（PQC）への移行期特有の物理的制約だ。米国国立標準技術研究所（NIST）の標準化に準拠したハイブリッド鍵合意「X25519MLKEM768」は、将来の量子コンピュータによる「今盗聴して後で解読する（Harvest Now, Decrypt Later）」攻撃を防ぐ決定打と目されている。しかし、このアルゴリズムには現場を悩ませる巨大な代償があった。従来のX25519の鍵共有がわずか32バイトであるのに対し、X25519MLKEM768の鍵共有は1,216バイトに達する。

暗号強度の向上に伴うこの肥大化は、ClientHello全体のサイズを一気に押し上げ、一般的なネットワークのMTU（約1,500バイト）をあっさり突き破ってしまう。規格上、TLSハンドシェイクのパケット分割は許容されている。だが現実のインターネットには、TCPセグメントが分割されただけでパケットをドロップしたりコネクションを切断したりするレガシーなファイアウォールやミドルボックス、古いロードバランサが跋扈している。Cloudflareの過去の調査でも、初手でPQC鍵共有を送信した場合、スキャン対象オリジンの約0.34%がハンドシェイクそのものを完了できずに沈黙することが判明していた。

この通信破壊を回避するため、Cloudflareは2023年9月以降、極めて保守的な「安全弁」アーキテクチャを採用していた。すなわち、ClientHelloではPQCのサポートを広告しつつも、最初に送る鍵共有は古典的なX25519（32バイト）にとどめ、PQCで通信したいオリジン側にはHelloRetryRequestを発行させて強制的に2回目の往復でX25519MLKEM768を要求させるという設計だ。この安全策によって通信断こそ防げたものの、ポスト量子暗号を真面目に導入した先進的なオリジンほど、例外なく追加の1RTTを支払わされるという皮肉な逆転現象（PQCペナルティ）が固定化されていたのである。

今回投入された「Automatic Key Exchange」は、プロダクション通信の外部でオリジンを能動的にプロービングし、各サーバーがサポートおよび優先するアルゴリズムを事前に学習する。安全が確認されたオリジンに対してのみ初手からX25519MLKEM768を投げ込むことで、PQCトラフィックにおけるHRRなしのハンドシェイク完了率は0%から99.2%へと垂直立ち上がりを記録した。長年エンジニアを苦しめてきた「セキュリティを上げるとレイテンシが死ぬ」という呪縛を、力技のプロービングと動的ルーティングで見事に粉砕したと言える。

しかし、手放しで賞賛してダッシュボードのスイッチを放置するわけにはいかない。今回のアップデートには、油断すると本番サービスを即座に沈没させかねない運用上の地雷が潜んでいる。最大の懸念は、新設された「Compliance requirements（コンプライアンス要件）」設定の挙動だ。

この設定には「ポスト量子ハイブリッドのみ」や「FIPS準拠アルゴリズムのみ」といった排他的フィルタリングが用意されている。注意しなければならないのは、この機能はオリジン側に新たな暗号能力を授けるものではなく、Cloudflare側が交渉できる選択肢を一方的に狭めるだけの機能だという点だ。もしオリジンサーバーがX25519MLKEM768に対応していない状態で安易に「ポスト量子ハイブリッドのみ」を強制すれば、双方で合意可能なアルゴリズムが完全に消失し、そのオリジンへのTLS 1.3接続はすべて即座にエラーとなって遮断される。さらに現行仕様では、設定の適用単位がオリジン単位ではなく「ゾーン（ドメイン）単位」に縛られている点も危険極まりない。クラスタ内に1台でも古いOpenSSLスタックを引きずったレガシーなバックエンドが残っていれば、ゾーン全体を巻き込んだ障害へと発展しかねないのだ。

また、従来の自動化スクリプトで利用されていた「Origin Post-Quantum Encryption API」が実質的なno-op（何もしない関数）へとサイレントに変更され、将来的な廃止が予告された点もインフラ自動化パイプラインを持つ現場は見逃してはならない。我々エンジニアが明日から取るべき実務的な処方箋は極めて明快だ。まずBoringSSLのbssl clientコマンド等を用いて、自社オリジンがポート443でX25519MLKEM768を正しくネゴシエーションできているかを実測・確認すること。そして、オリジン間通信のKeep-Alive接続プールを徹底的に監視・再利用し、そもそも新規TLSハンドシェイク自体の発生頻度を最小化しておくことだ。

暗号の世代交代は、もはや遠い学術界のイベントではない。鍵交換のPQC化に成功した先には、ML-DSA等によるサーバー証明書の認証署名自体の完全移行という、さらに巨大なパケットサイズと計算コストを伴う第2の壁が待ち受けている。業界が「Q-Day（量子コンピュータによる暗号崩壊）」へ突き進む中、あなたの管理するインフラは、1RTTのペナルティや巨大パケットの分断に耐えうるだけの柔軟性を備えているだろうか。それとも、見えないネットワーク機器のブラックボックスの中で、人知れずパケットをドロップさせ続けるのだろうか。