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

Automatic Key Exchange: 450億件のコネクション（そして増加中）に対する、より高速でポスト量子セキュアなオリジンハンドシェイク

Cloudflareがオリジンサーバーとの新しいTLS 1.3コネクションを開くたびに、推測をしなければなりません。プロトコルでは、オリジンが自身の能力について何も伝えてくる前に、最初のパケットで鍵合意アルゴリズムをコミットする必要があります。推測が正しければ、ハンドシェイクは1回のラウンドトリップで完了します。間違っていれば、オリジンはHelloRetryRequestで応答し、やり直しとなり、コネクションは2回のラウンドトリップを要します。

長年、私たちの推測はインターネット上のすべてのオリジンに対して同じでした。X25519です。広くサポートされていますが、結果として、測定したオリジンコネクションの約30%で最適ではありませんでした。

本日、私たちはAutomatic Key Exchangeを発表します。これはAutomatic SSL/TLSの拡張機能で、推測を測定に置き換えます。各オリジンをプローブして、サポートしている鍵合意アルゴリズムと優先順位を学習し、最初の試行でそのアルゴリズムをリードさせます。オリジンが対応していれば、ポスト量子ハイブリッドのX25519MLKEM768を優先します。

オリジンコネクション全体へのAutomatic Key Exchangeの継続的なロールアウトにより、HelloRetryRequestsは約52%から3.7%に減少し、p90でのコネクションハンドシェイクレイテンシを150ミリ秒以上削減しました。さらに、継続的なロールアウトの一環として、何十万ものドメインが、誰も設定する必要がなかったポスト量子オリジンコネクションを持つようになり、その数は日々増加しています。

ミリ秒も重要ですが、後半の部分はさらに重要かもしれません。今この瞬間にも、攻撃者はまだ読めない暗号化されたトラフィックを記録しており、将来読めるようになることを賭けています（harvest-now, decrypt-laterとして知られる攻撃）。Cloudflareは、インターネットを2029年までに量子セキュアにするために競走しています。この年は、一部の業界専門家が古典的な暗号化アルゴリズムが破られる可能性があると見積もっている年です。その日には名前があります：Q-Day。その締め切りを満たすことは、何百万ものウェブサイトオペレーターがそれぞれ専門の暗号技術者になることに依存するわけにはいきません。それは自動でなければなりません。今日まで、ポスト量子コネクションを優先するには手動設定が必要でした。Cloudflare側から有効にするか、オリジンサーバーにそれを要求させるかのどちらかでした。間違いやすかったのです。しかし今日、それはただ…自動になりました！

TLS 1.3ハンドシェイク：鍵交換アルゴリズムの推測

すべてのセキュアなウェブコネクションはTLSハンドシェイクから始まります。これはサーバーを認証し、共有秘密鍵を導出します。以前のAutomatic SSL/TLSのブログ投稿でそのプロセスを詳細に説明しています。

Cloudflareはリバースプロキシとして機能するため、単一のセキュアなコネクションに見えるものは、実際には2つです。1つは訪問者とCloudflareの間、もう1つはCloudflareとオリジンサーバーの間です。各コネクションは独立して動作し、独自のハンドシェイク、IDチェック、暗号化鍵を持ちます。

［画像: BLOG-3300 2.png］

Automatic Key Exchangeは2番目のコネクションに影響します。Cloudflareがオリジンに接続するとき、CloudflareはTLSクライアントとして動作し、ハンドシェイクを開始する必要があります。ホスト名とサポートされている鍵合意アルゴリズムのリストを含むClientHelloメッセージを送信することでコネクションを開始します。

［画像: Normal TLS 1.3 handshake vs Unsupported Key Share (1) copy.png］

ハッピーパスでは、TLS 1.3はわずか1回のネットワークラウンドトリップで新しい暗号化コネクションを確立できます（上記の図の左側に示されています）。この場合、Cloudflareはサポートされている鍵合意アルゴリズムのリストと、1つ以上のクライアントキースhareを送信します。オリジンがその選択を受け入れると、応答し、ハンドシェイクが完了します。この予測的な鍵交換はTLS 1.3のイノベーションであり、TLS 1.2よりも高速である大きな理由です。

それ以外の場合、オリジンが別のオプションを優先する場合、HelloRetryRequest（HRR）を送信し、Cloudflareに再試行を求めます（上記の図の右側のフロー）。その後、Cloudflareはオリジンによって指定された鍵合意アルゴリズムに基づいて新しいクライアントキースhareを生成し、2回目のClientHelloを送信します。コネクションは依然として成功しますが、リトライによりCloudflareがコンテンツを取得できるようになる前に、完全なネットワークラウンドトリップが追加されます。これはマリオカートでショートカットを逃すようなものです。ゴールには到達しますが、ショートカットが節約するはずだった時間を失います。

どちらの場合も、クライアントキースhareを使用して、サーバーは共有鍵を生成します。その後、サーバーはサーバーキースhareを返します。これにより、クライアントも共有鍵を計算できます。この共有鍵は、AESなどの対称暗号化を使用して、コネクションの残りを保護するために使用されます。

安全な推測のコスト

長年、オリジンコネクション用の初期クライアントキースhareの推測は静的でした。他の鍵合意アルゴリズムのサポートを広告しながら、常にX25519を送信していました。これは安全な戦略でした。なぜなら、95%以上のオリジンがX25519をサポートしており、サポートしていないオリジンはコネクションを壊すことなくHelloRetryRequest（HRR）を発行できたからです。

しかし、X25519は量子コンピュータに対して脆弱です。2023年9月以降、オリジンにポスト量子鍵合意のサポートを広告してきました。最初はX25519Kyber768Draft00、そして今日ではX25519MLKEM768（アルゴリズムの標準化されたバージョン）です。重要なのは、サポートを広告することと、ClientHelloでキースhareをリードすることとは異なるということです。X25519MLKEM768キースhareは、X25519の32バイトと比較して1,216バイトであり、ClientHelloを単一のネットワークパケットを超えてしまいます。TLS標準はマルチパケットセグメントを許可していますが、一部のレガシーミドルボックスやオリジンサーバーは、複数のパケットに分割されたClientHelloメッセージを受信すると失敗することがあります。私たちの以前の研究では、スキャンされたオリジンの約0.34%が、最初にポスト量子キースhareを受信したときにTLSハンドシェイクを完了できませんでしたが、大多数のオリジンは依然として古典的なX25519に依存していました。

［画像: BLOG-3300 4.png］

そのため、オリジンコネクションの破損の可能性を防ぐために、HRRをセーフティバルブとして使用しました。ポスト量子サポートのみを広告し、古典的なX25519キースhareを送信し、HRRフローをサポートしないオリジンに対しては、顧客がX25519MLKEM768キースhareをリードすることに手動でオプトインするオプションがありました。2023年から今日にかけて、ポスト量子鍵合意アルゴリズムをサポートするオリジンの割合は0.5%から12.8%に増加し、ホスティングスタックがPQセーフアルゴリズムにアップグレードされるにつれて、この割合はさらに上昇すると予想されます。

安全ではありましたが、ポスト量子セキュアなコネクションへのアップグレードをリトライ経由でのみ行うというこのデフォルト設定は、2つの理由で不必要なレイテンシを追加しました。

• すべての最新のOpenSSL、BoringSSL、rustlsのビルドはX25519MLKEM768をサポートしていますが、古典的なX25519キースhareの扱いは異なります。ビルドによっては、明示的にポスト量子セキュアキースhareを優先するように設定されていない限り、一部の古いビルドはデフォルトで受け入れる可能性がありますが、新しいビルドはポスト量子コネクションを優先するためにすぐにHRRを発行します。
• 6%以上のオリジンは、X25519よりもP-256またはP-384を優先しており、初期クライアントキースhareの静的な選択により、純粋な古典的なコネクションであってもHRRラウンドトリップをトリガーします。

これらの無駄なラウンドトリップを排除するために、Automatic SSL/TLSを強化する一環として、オリジンサーバーをスキャンして正確な鍵合意能力をマッピングし始めました。これらのスキャン結果を使用して、サイトのダウンタイムをリスクにさらすことなくポスト量子コネクションを最大化し、適用可能なドメインのコネクションを高速化しながら、オリジンごとに初期キースhareを自動的に調整します。

Automatic SSL/TLSをポスト量子時代へ拡張

Automatic SSL/TLSには、Automatic Key Exchangeが含まれるようになりました。何百万ものオリジン全体で、異なるキースhareを推測することは運用リスクを伴います。なぜなら、個々のオリジンがどのように設定されているかについて、事前に知識がないからです。そのため、能力を推測するのではなく、Automatic SSL/TLSを既に支えているスキャンパイプラインを再利用して、直接測定します。

増え続けるオリジンに対して、これは追加のラウンドトリップなしで、手動設定を必要とせずに、コネクションセットアップの最初の試行でポスト量子鍵合意を提供します。

仕組みは次のとおりです。

1. TLS 1.3対応の各オリジンに対して、X25519、P-256、P-384、P-521、またはX25519MLKEM768のいずれか1つの鍵合意グループのみを提供する、いくつかの軽量TLSハンドシェイクを実行します。これらのプローブを組み合わせることで、オリジンがサポートするアルゴリズムの完全なセットがわかります。アクティブスキャンは本番トラフィックパスの外側で行われるため、実際のトラフィックが依存する前に、オリジンとそれらを結ぶネットワークの両方が、より強力な鍵合意を持つコネクションを処理できることを確認します。

2. 単一のドメインは、異なる能力を持つ複数のオリジンに解決されることが多いサブドメインをフロントに持つことがあります。各サブドメインを個別に評価し、実際のトラフィック量で結果を重み付けします。これにより、ドメイン全体の優先順位がHTTPトラフィック量を反映し、休止中のサブドメインを最も忙しいエンドポイントと同等に重み付けしないようにします。たとえば、ほとんどのトラフィックがwwwおよびapiサブドメインにヒットする場合、それらのエンドポイントはドメイン全体の鍵交換の優先順位を大きく決定します。

3. オリジンがサポートする鍵合意グループの中から、ポスト量子ハイブリッド（X25519MLKEM768）を最初に、次にオリジンが受け入れる最も高速な古典的なアルゴリズム（X25519、P-256、P-384、またはP-521）にフォールバックするという厳格な優先順位を使用して、最も強力な候補を選択します。

4. オリジンが最適な鍵合意を優先することがわかったら、ロールアウトを開始します。新しい優先順位は、まずそのオリジンのトラフィックのごく一部に適用され、システムは実行中に失敗率とHelloRetryRequest（HRR）率を監視します。リトライがそのオリジンのベースラインを超えて上昇した場合、Automatic SSL/TLSが誤動作する可能性のある暗号化モードのアップグレードを元に戻すのと同じ方法で、変更を元に戻します。最悪の場合、ロールバックにより、追加のラウンドトリップレイテンシが発生しますが、ロールアウトフェーズの期間中にTLSコネクションが壊れることはありません。

5. オリジンの設定は時間とともに変化します。顧客が新しいロードバランサーに移行したり、TLSライブラリが定期リリースでポスト量子サポートをリリースしたり、オペレーターが古い鍵合意アルゴリズムのサポートを無効にしたりします。毎日すべてのオリジンを再スキャンするため、ポスト量子サポートを追加したサーバーや、使用していたカーブのサポートを停止したサーバーは、次のスキャンで新しい優先順位を取得します。

ほとんどの顧客にとって、設定するものは何もありません。オリジンがTLS 1.3に対応している場合、最も強力な鍵交換を自動的にネゴシエートします。たとえば、オリジンがX25519MLKEM768をサポートしている場合、Cloudflareはそれを優先し、追加のラウンドトリップレイテンシなしでポスト量子鍵合意を確立できます。

Automatic Key Exchangeの設定

Automatic Key Exchangeは、すべての既存および新規ドメインでデフォルトでアクティブになっており、ほとんどのセットアップでは手動操作は不要です。必要に応じて、CloudflareダッシュボードのSSL/TLS > Overview > Configure > Origin connection & post-quantum encryptionでこれらの設定を個別に管理できます。

Automatic Key Exchangeトグルが有効になっている場合、Cloudflareはオリジンを帯域外でスキャンし、動的に選択されたキースhareでリードします。無効にすると、スキャンが停止し、Cloudflareは固定/静的なデフォルトの鍵合意順序に戻ります。

［画像: BLOG-3300 5.png］

また、Automatic Key Exchangeの下に新しいCompliance requirements設定を導入しました。Cloudflareがオリジンコネクションに使用および広告を許可できる鍵合意をフィルタリングできます。設定すると、Automatic Key Exchangeとすべてのオリジン向きトラフィックは、これらのルールを厳密に遵守します。

• Post-quantum hybrid: ネゴシエーションをハイブリッドポスト量子鍵合意（X25519MLKEM768）にのみ制限し、古典的なアルゴリズムを完全に削除します。すべての成功したオリジンTLS 1.3コネクションは、ポスト量子セキュアであることが保証されます。
• Federal Information Processing Standards (FIPS): ネゴシエーションをFIPS準拠の鍵合意にのみ制限します。

両方のオプションを選択すると、同時に両方の基準を満たすアルゴリズムが必要になります。重複する鍵合意が存在しない場合、設定は拒否されます。詳細については、Automatic Key Exchangeドキュメントを参照してください。

［画像: BLOG-3300 6.png］

これらのオプションを選択することで、特定のアルゴリズムではなく、意図を設定します。これにより、コンプライアンス標準が進化したり、新しいポスト量子アルゴリズムが登場したりしても、設定は自動的に最新の状態に保たれます。

ただし、これらの要件は慎重に検討する価値があります。これらはオリジンに新しい暗号機能を与えるのではなく、Cloudflareがネゴシエートできるものを狭めるだけです。

重要な注意点：X25519MLKEM768をサポートしていないオリジンにポスト量子ハイブリッドを強制すると、相互にサポートされるアルゴリズムがなくなるため、すべてのTLS 1.3コネクションが失敗します。すべてのコネクションでポスト量子交換またはFIPSコンプライアンスを厳密に強制するポリシー義務がない限り、両方のオプションを選択せずに、Automatic Key Exchangeに最適なアルゴリズムを安全にネゴシエートさせてください。

インターネットをより安全に、より速く、共に

Automatic Key Exchangeは、オリジンがTLS 1.3に対応しているドメインで機能します（優先鍵合意方法の予測はTLS 1.3のみの機能であるため）。デフォルトで有効になっており、スキャンパイプラインは既に100万ドメイン以上に鍵交換の優先順位を割り当てており、残りのネットワーク全体で登録が続いています。

最初のコホートから、約64%が古典的なX25519を優先順位として維持しており、コネクションに変更はありませんでした。約33%は現在、X25519MLKEM768を優先順位としており、それらのオリジンへのトラフィックは、単一ラウンドトリップでharvest-now, decrypt-later量子攻撃から保護されています。残りの3%は、P-384、P-256、またはP-521のような、オリジンが優先する別の古典的なカーブを選択しました。

［画像: BLOG-3300 7.png］

毎日約9,000のドメインが、X25519以外の鍵合意方法を鍵合意の優先順位として設定しています。これらのほとんどすべてがポスト量子鍵交換を優先するようになり、残りはオリジンのTLS構成でよりよくサポートされている他の古典的なカーブを採用しています。

前述したように、Automatic Key Exchangeが登場する前は、ほとんどすべてのポスト量子オリジンハンドシェイクでHelloRetryRequest（HRR）が必要でした。これは、静的な初期推測が古典的なX25519をデフォルトとしていたためです。その結果、ポスト量子コネクションはTLSハンドシェイクを完了する前に、必須の2回目のラウンドトリップを支払っていました。

［画像: BLOG-3300 8.png］

HRRなしで完了したポスト量子オリジンTLS 1.3トラフィックの割合は、0%から99.2%に上昇しました。

ロールアウトが進行中であるため、現在スキャンされているオリジンのコホートのポスト量子対応オリジンでは、そのレイテンシペナルティは事実上なくなっています。現在スキャンされているオリジンのコホートにおいて、ポスト量子TLS 1.3コネクションの99.2%が、1回のラウンドトリップで完了しています。追加のラウンドトリップを排除することに加えて、そのコホート全体で、ポスト量子オリジンからのトラフィックが約250億コネクションから1日あたり450億コネクションへと増加していることがわかります。その成長の大部分は、Automatic Key Exchangeがスキャンされたオリジンに対して古典的なコネクションをポスト量子優先順位にアップグレードしたことによるものです。

多くのオリジンは、1つをもう一方より優先することなく、複数の鍵合意アルゴリズムをサポートしています。たとえば、ポスト量子鍵合意をサポートするオリジンは、古典的な（X25519）キースhareを受け入れることができ、拒否したりHRRを発行したりしません。したがって、受動的な観察では、オリジンの完全な能力を明らかにすることはできません。アクティブなプローブにより、Automatic Key Exchangeは、オリジンからのトラフィックにポスト量子サポートが現れなかった何千ものオリジンを発見することができました。

［画像: BLOG-3300 9.png］

スキャナーがそのようなオリジンを発見し、クライアントキースhareの優先順位を更新すると、ポスト量子コネクションはすぐにこれらのオリジンへのトラフィックの大部分を占めるようになりました。他の古典的な鍵合意アルゴリズムは、ポスト量子と古典的なバックエンドの混合を持つマルチオリジンセットアップによって主に駆動される、アップグレードされたドメインでははるかに小さいシェアを占めています。
Automatic Key Exchangeは、ポスト量子採用を推進する以上のことを行います。また、オリジンを優先する古典的なカーブ（X25519以外）とペアリングするのに役立ち、すべてスキャンされたオリジン全体でHRR率を低下させます。

［画像: BLOG-3300 10.png］

Automatic Key Exchangeを有効にする前は、スキャンされたドメインのオリジンコネクションの約52%がHRRを必要としていました。その率はわずか3.7%に低下しました。HRRを回避することは、TLSコネクションセットアップから完全なラウンドトリップを削除し、スキャンされたオリジンに対してp90レイテンシを150ミリ秒以上削減します。これは、新しいTLS 1.3コネクションをオリジンに必要とする可能性のある動的リクエストやCDNキャッシュミスに特に役立ち、最終的にユーザーへのレイテンシを削減します。既存のキープアライブコネクションで送信されるリクエストは、新しいハンドシェイクを必要としないため、影響を受けません。

サーバーはポスト量子対応ですか？

サーバーがポスト量子鍵合意をサポートしているかどうかを確認するためのさまざまなツールがあります。Cloudflare Radarを通じて、これらのツールの1つを提供しています。サーバーのホスト名またはIPアドレスを入力すると、ポスト量子TLS鍵交換をサポートしているかどうかを確認します。Cloudflareによってプロキシされているホスト名を入力した場合、RadarはオリジンサーバーではなくCloudflareへのコネクションを確認することに注意してください。

［画像: BLOG-3300 11.png］

アルゴリズムサポートの検証に加えて、ツールにポスト量子TLS実装バグを確認する機能を追加しました。結果がネガティブな場合、失敗の理由を特徴づけようとします。失敗は、マルチパケットペイロードをドロップしたり、TCPセグメントに分割されたClientHelloを再アセンブルできなかったりするレガシーミドルボックス、ファイアウォール、またはサーバーバッファに起因することがよくあります。あるいは、オリジンはTLS 1.3で要求されているようにHelloRetryRequestを送信する代わりに、認識されないキースhareでギブアップするか、送信した後にハンドシェイクを完了できません。

Radarは、ネットワークパスがポスト量子トラフィックをクリーンに処理できるかどうかを明確に示します。Automatic Key Exchangeは、これらのチェックに失敗したオリジンを持つドメインを切り替えることはないため、それらをクリアすることがアップグレードを可能にします。

オリジンがまだポスト量子鍵合意をサポートしていない場合は？

オリジンがまだポスト量子暗号化をサポートしていない場合でも、良いニュースは、Auto Key Exchangeを有効にすると依然として有益であるということです。Automatic Key Exchangeはオリジンがサポートするものを検出します。X25519MLKEM768が利用できない場合、Cloudflareは互換性のある古典的な鍵合意の使用を継続し、オリジンがそれを優先することを知ることで、不要なHelloRetryRequestラウンドトリップを回避できます。

ただし、Automatic Key Exchangeは、オリジンサーバーが既に鍵合意アルゴリズムをサポートしている場合にのみ、ポスト量子コネクションを優先できます。現在、ネットワーク全体で個々のオリジンの12%以上がポスト量子暗号化をサポートしています。TLSサーバー実装におけるポスト量子セキュアアルゴリズムのサポートは増加しており、BoringSSL、OpenSSL、およびrustlsの最近のバージョンにはサポートが含まれています。エンタープライズオリジンのスタック、クラウドロードバランサー、および組み込みTLSターミネーターは、独自のタイムラインでアップグレードしています。

ドメインのオリジン向きコネクションに対してポスト量子保護機能を追加したい場合は、2つのオプションがあります。

• Cloudflare Tunnelを使用できます。cloudflaredとCloudflare間のコネクションは既にポスト量子鍵合意を使用しています。これは、パブリックオリジンエンドポイントのTLSソフトウェアを変更できない場合に最も簡単なオプションです。

［画像: BLOG-3300 12.png］

• TLSエンドポイントをアップグレードできます。多くの現在のフレームワークとTLSライブラリは、デフォルトでX25519MLKEM768を有効にしています。ただし、サーバーのTLS構成で許可されるカーブを手動で設定していた場合、それらのレガシー設定が新しいデフォルトを上書きする可能性があります。ロードバランサー、WAFアプライアンス、その他のミドルボックスなど、オリジンとCloudflareの間に位置するすべてのデバイスを監査して、X25519MLKEM768がすべてで有効になっていることを確認することが重要です。マネージドホスティングサービスを利用している場合は、プロバイダーにX25519MLKEM768をサポートしているかどうかを尋ねてください（多くはサポートしています）。

サポートされているソフトウェア、設定例、および検証手順については、Cloudflareとオリジン間のポスト量子暗号化を参照してください。

次のステップ

Cloudflareでは、2024年から公開で Automatic SSL/TLSを構築してきました。Automatic Key Exchangeは、長い道のりの2番目のステップであり、最後ではありません。その時点からロードマップに載っているものについては公開しており、出荷時に更新を提供し続けます。現在取り組んでいるいくつかの具体的な事項があります。

オリジンごとの優先順位の粒度

現在、Automatic SSL/TLSはドメインレベルで決定を下します。1つのオリジンサーバーの動作がドメイン全体を遅らせる可能性があります。単一ドメインがサービスを提供する複数のオリジン間で鍵合意（およびSSL/TLS暗号化モード）が異なるように、サブドメインごと/オリジンごとの粒度に取り組んでいます。

オンデマンドスキャン

オリジンのTLSスタックをアップグレードしたばかりの場合、Automatic SSL/TLSによる次のスケジュールスキャンを待つ必要はありません。当初は、オリジンでの変更に対応するのに十分なスキャンを行いたかったのですが、同じセキュリティ情報しか返さないオリジンに過度の負担をかけないように、あまり多くは行いたくありませんでした。ダッシュボードまたはAPIからオンデマンド再スキャンをトリガーするオプションを構築しているため、オリジンアップグレード後に、システムが追いつくのを待つのではなく、すぐに優れた鍵合意に移行できます。

オンデマンドスキャンをトリガーすることに加えて、これは診断ツールとしてCloudflareダッシュボードに直接表示されます。これにより、オンデマンドで独自のオリジンサーバーの動作をテストし、どの鍵合意を正常にネゴシエートできるかを正確に確認し、失敗の理由を特徴づけることができます（外部Cloudflare Radarスキャンツールと同様）。

自動ポスト量子オリジン認証

ポスト量子鍵合意は、今日のトラフィックが将来の量子コンピュータによって復号化されるのを防ぎます。これは、攻撃者が証明書を偽造してオリジンをなりすますことを防ぐものではありません。そのギャップを埋めるにはポスト量子認証が必要です。これは、Authenticated Origin PullsとCustom Origin Trust StoreがML-DSA証明書のサポートを得た際に、オリジンコネクションに今年初めに導入されました。

ここには対処すべき重要な問題があります：ダウングレード。オリジンサーバーが古典的なRSA/ECDSA証明書と新しいポスト量子ML-DSA証明書の両方をサポートしていると想像してください。これにより、レガシークライアントが壊れるのを防ぎます。Q-Dayでは、Cloudflareとオリジン間のアクティブな攻撃者がTLSハンドシェイクを傍受し、ポスト量子オファーをサイレントにドロップする可能性があります。Cloudflareは古典的な応答のみを見て、レガシーRSA/ECDSA証明書の検証にフォールバックしますが、これは攻撃者が量子コンピュータを使用して偽造できます。

広範なWebPKIでこれを防ぐことは複雑です。提案されているパスの1つは、証明書発行局（CA）が古典的な証明書にポスト量子署名を付けて、レガシーサーバーがまだPQをサポートしていないことを証明することを含みます。これはパブリックWebの可能性のある方向ですが、時間と調整が必要です。より迅速な方法（可能であれば！）は、古典的な証明書を完全に信頼しないことです。

そしてオリジンコネクションについては、それが可能です！Cloudflareは、オリジンがポスト量子認証（ML-DSA証明書、および将来のMerkle Tree Certificates）をサポートしていることを検出するために、Automatic SSL/TLSスキャンを拡張する予定です。スキャナーがそのようなオリジンを特定すると、Cloudflareは厳密なポスト量子保護を望む顧客に対して、古典的なフォールバックを自動的に無効にすることができ、アップグレードされていないエンドポイントを中断することなくダウングレードのリスクを排除します。

チェックアウト

Cloudflareでは、インターネット上の強力なセキュリティは無料で、自動で、デフォルトで有効であるべきだと信じています。Universal SSLは、ブラウザからCloudflareへのコネクションで暗号化をデフォルトで実現しました。Automatic SSL/TLSは、Cloudflareからオリジンへのコネクションでも同様のことを行っており、現在はポスト量子鍵合意にまでその作業を拡張しています。

今日のオリジンの暗号化レベルを確認したい場合は、ダッシュボードのSSL/TLSセクションを確認してください。オリジンのポスト量子準備状況を直接検証したい場合は、Cloudflare Radarでサーバースタックを更新する必要があるかどうかを確認できます。オリジンが既にポスト量子をサポートしている場合は、Automatic Key ExchangeがCloudflareにそれを通知するため、より高速かつ安全にオリジンに接続します。