CloudflareのAutomatic Key ExchangeでオリジンTLS再試行が52%から3.7%に

CloudflareのAutomatic Key Exchangeは、各オリジンが対応・優先する鍵交換方式を先に測定し、初回のTLS 1.3 ClientHelloに適合しそうな鍵共有（key share）を載せる仕組みです。余分なHelloRetryRequestを避けることで、Cloudflareが調査したオリジン群では再試行が必要な接続の割合が約52%から3.7%に下がったと同社は報告しています。

鍵共有を予測して余分な1往復を省く

TLS 1.3では、クライアントが最初に提示した鍵共有方式をオリジンが利用できないと、サーバーはHelloRetryRequestを返し、別の方式での再送を求めます。Automatic Key Exchangeはオリジンを事前に調べ、対応する可能性が高い方式を最初から提示して、この往復を避けます。

Cloudflareによると、対象オリジンではp90のハンドシェイク遅延が150ミリ秒超短縮しました。対象はCloudflareからオリジンサーバーへの新規TLS 1.3接続であり、ブラウザーからCloudflareまでの区間や、keep-aliveで既存接続を再利用するリクエストには影響しません。数値はCloudflareによる製品計測で、独立したベンチマークではありません。

X25519MLKEM768を選ぶまで

オリジンが対応していれば、Cloudflareは標準化された耐量子ハイブリッド方式のX25519MLKEM768を優先し、非対応の場合は利用可能な従来方式を選びます。同社の調査対象では、耐量子TLS 1.3接続の99.2%が1往復で完了し、耐量子方式によるオリジン接続は1日約250億件から450億件へ増えました。

スキャン基盤が鍵交換方式の優先設定を割り当てたドメインは100万件を大きく超えています。初期対象では約64%がX25519、約33%がX25519MLKEM768、残る3%が別の従来曲線を選択しました。アクティブなオリジンは約24時間ごとに再調査され、変更は段階的に展開。接続失敗やHelloRetryRequestの増加が見つかればロールバックされます。

既定で有効、制限設定は慎重に

Automatic Key Exchangeは既存のCloudflareゾーンすべてで有効になっており、新規ゾーンでも既定で使われるため、多くの利用者に手動設定は不要です。Full、Full (strict)、Strict (SSL-Only Origin Pull)のいずれかを使用し、オリジンがTLS 1.3をネゴシエートする場合に適用されます。別の耐量子接続を使うCloudflare Tunnelは対象外です。

ダッシュボードには耐量子ハイブリッド方式やFIPS準拠を必須にするオプションもあります。ただし、X25519MLKEM768に対応しないオリジンへ耐量子ハイブリッドを強制すると、共通のアルゴリズムがなくなり、TLS 1.3接続が失敗する可能性があります。対応状況を確かめずに固定する設定ではありません。