Cloudflare AKEがオリジンのHelloRetryRequestsを52%から3.7%に削減

Cloudflareがオリジンサーバーに新しいTLS 1.3接続を開くたびに、推測をしなければなりません。プロトコルでは、オリジンが自身のサポート内容を何も伝えてくる前に、最初のパケットでキー合意アルゴリズムにコミットする必要があります。推測が正しければ、ハンドシェイクは1往復で完了します。間違っていれば、オリジンはHelloRetryRequestで応答し、最初からやり直しとなり、接続は2往復かかります。 長年、インターネット上のすべてのオリジンに対して、私たちの推測は同じでした：X25519。広くサポートされていますが、後になって測定したオリジン接続の約30%にとって最適ではないことが判明しました。 本日、Automatic Key Exchangeを発表します。これはAutomatic SSL/TLSの拡張機能であり、推測を測定に置き換えます。各オリジンをプローブして、どのキー合意アルゴリズムをサポートし、優先するかを学習し、最初の試行でそのアルゴリズムをリードさせます。オリジンがそれを話せる場合は、ポスト量子ハイブリッドX25519MLKEM768を優先します。オリジン接続全体でのAutomatic Key Exchangeの継続的なロールアウトにより、HelloRetryRequestsは約52%から3.7%に減少し、p90での接続ハンドシェイクレイテンシを150ms以上短縮しました。さらに、継続的なロールアウトの一環として、何十万ものドメインが、誰も設定する必要がなかったポスト量子オリジン接続を持つようになり、その数は日々増加しています。 ミリ秒は重要ですが、後半の部分はより重要かもしれません。今この瞬間にも、攻撃者は、将来読めるようになることを賭けて、現在読めない暗号化されたトラフィックを記録しています（harvest-now, decrypt-laterとして知られる攻撃）。Cloudflareは、一部の業界専門家が古典的な暗号アルゴリズムが侵害される可能性があると推定している2029年までに、インターネットを量子安全にするために急いでいます。その日には名前があります：Q-Day。その締め切りを満たすことは、何百万ものウェブサイト運営者がそれぞれ専門の暗号学者になることに依存することはできません。それは自動化されなければなりません。本日まで、ポスト量子接続を優先するには手動設定が必要でした。Cloudflare側からオンにするか、オリジンサーバーにそれを要求させるかのどちらかです。間違いやすかったのです。しかし今日、それはただ…自動になりました！ TLS 1.3ハンドシェイク：キー交換アルゴリズムの推測 すべての安全なウェブ接続はTLSハンドシェイクで始まります。これはサーバーを認証し、共有秘密鍵を導出します。以前のAutomatic SSL/TLSブログ投稿で、そのプロセスを詳細にカバーしています。 Cloudflareはリバースプロキシとして機能するため、単一の安全な接続に見えるものは実際には2つです。1つは訪問者とCloudflareの間、もう1つはCloudflareとオリジンサーバーの間です。各接続は独立して動作し、独自のハンドシェイク、IDチェック、および暗号化鍵を持っています。 Automatic Key Exchangeは2番目の接続に影響します。Cloudflareがオリジンに接続するとき、CloudflareはTLSクライアントとして機能し、ハンドシェイクを開始する必要があります。ホスト名とサポートされているキー合意アルゴリズムのリストを含むClientHelloメッセージを送信して接続を開始します。 ハッピーパスでは、TLS 1.3は1つのネットワーク往復で新しい暗号化接続を確立できます（上記の図の左側に示されています）。この場合、Cloudflareはサポートされているキー合意アルゴリズムのリスト、および1つ以上のクライアントキーシェアを含むClientHelloを送信します。オリジンがその選択を受け入れると、応答してハンドシェイクが完了します。この予測的なキー交換はTLS 1.3のイノベーションであり、TLS 1.2よりも高速である大きな理由の1つです。 そうでなければ、オリジンが異なるオプションを優先する場合、HelloRetryRequest（HRR）を送信し、Cloudflareに再試行するように要求します（上記の図の右側のフロー）。Cloudflareは次に2番目のClientHelloを送信し、オリジンによって指定されたキー合意アルゴリズムに基づいて新しいクライアントキーシェアを生成します。接続は依然として成功しますが、リトライによりCloudflareがコンテンツを取得する前に完全なネットワーク往復が追加されます。これはマリオカートでショートカットを逃すようなものです。ゴールには到達しますが、ショートカットが節約するはずだった時間を失います。 どちらの場合も、クライアントキーシェアを使用して、サーバーは共有鍵を生成します。次にサーバーは、クライアントも共有鍵を計算できるサーバーキーシェアを返します。この共有鍵は、AESなどの対称暗号を使用して、接続の残りを保護するために使用されます。 安全な推測のコスト 長年、TLS 1.3を使用したオリジン接続の初期クライアントキーシェアの推測は静的でした。他のキー合意アルゴリズムのサポートを広告しながら、常にX25519を送信していました。これは安全な戦略でした。なぜなら、95%以上のオリジンがX25519をサポートしており、サポートしていないオリジンは接続を壊すことなくHelloRetryRequest（HRR）を発行できたからです。 しかし、X25519は量子コンピュータに対して脆弱です。2023年9月以降、私たちはオリジンにポスト量子キー合意のサポートを広告してきました。最初はX25519Kyber768Draft00として、そして今日ではX25519MLKEM768（アルゴリズムの標準化されたバージョン）として広告しています。重要なのは、ポスト量子キーシェアをClientHelloでリードすることと、サポートを広告することの違いです。X25519MLKEM768キーシェアは32バイトのX25519と比較して1,216バイトであり、ClientHelloを単一のネットワークパケットを超えてしまいます。TLS標準はマルチパケットセグメントを許可していますが、一部のレガシーミドルボックスやオリジンサーバーは、複数のパケットに分割されたClientHelloメッセージを受信すると失敗する可能性があります。以前の研究では、スキャンされたオリジンの約0.34%が、最初にポスト量子キーシェアを受信したときにTLSハンドシェイクを完了できませんでしたが、オリジンの大部分は依然として古典的なX25519に依存していました。 そのため、オリジン接続の破損の可能性を防ぐために、HRRをセーフティバルブとして使用しました。ポスト量子サポートのみを広告し、古典的なX25519キーシェアを送信し、リトライを介してポスト量子交換を要求するよう、対応可能なオリジンに要求しました。HRRフローをサポートしないオリジンについては、顧客はX25519MLKEM768キーシェアでリードすることに手動でオプトインするオプションがありました。2023年から今日にかけて、ポスト量子キー交換アルゴリズムをサポートするオリジンの割合は0.5%から12.8%に増加し、ホスティングスタックがPQ安全アルゴリズムにアップグレードするにつれて、それがさらに増加すると予想しています。 安全でしたが、リトライを介してポスト量子安全接続にのみアップグレードするというこのデフォルト設定は、2つの理由で不要なレイテンシを追加しました。 すべての最新のOpenSSL、BoringSSL、およびrustlsのビルドはX25519MLKEM768をサポートしていますが、古典的なX25519キーシェアの処理方法が異なります。ビルドによっては、一部の古いビルドは、ポスト量子安全キーシェアを優先するように明示的に設定されていない限り、デフォルトで受け入れる場合がありますが、新しいビルドはポスト量子接続を優先するためにすぐにHRRを発行します。 オリジンの6%以上がX25519よりもP-256またはP-384を優先しており、初期クライアントキーシェアの静的な選択により、純粋に古典的な接続であってもHRR往復を引き起こします。 これらの無駄な往復を排除するために、Automatic SSL/TLSの一部としてオリジンサーバーをスキャンして、正確なキー合意機能をマッピングし始めました。これらのスキャン結果を使用して、サイト障害のリスクなしにポスト量子接続を最大化し、該当するドメインの接続を高速化しながら、オリジンごとに初期キーシェアを自動的に調整します。 Automatic SSL/TLSをポスト量子時代に拡張 Automatic SSL/TLSには、Automatic Key Exchangeが含まれるようになりました。何百万ものオリジン全体で、異なるキーシェアを推測することは運用リスクを伴います。なぜなら、個々のオリジンがどのように設定されているかについて、事前に知識がないからです。したがって、機能を推測するのではなく、直接測定し、すでにAutomatic SSL/TLSをサポートしているスキャンパイプラインを再利用します。 増え続けるオリジンに対して、これは追加の往復なしに、手動設定を必要とせずに、接続セットアップの最初の試行でポスト量子キー合意を提供します。 仕組みは次のとおりです。TLS 1.3対応の各オリジンに対して、いくつかの軽量TLSハンドシェイクを実行します。各ハンドシェイクは1つのキー合意グループのみを提供します：X25519、P-256、P-384、P-521、またはX25519MLKEM768。これらを組み合わせたプローブは、オリジンがサポートするアルゴリズムの完全なセットを教えてくれます。そしてbec