タグアーカイブ TLS

Cloudflareがオリジン接続でポスト量子認証をサポート開始

Cloudflareがオリジン接続でポスト量子認証をサポート開始

Cloudflareがオリジンサーバーとの接続に対するポスト量子(PQ)認証のサポートを開始した。Authenticated Origin Pulls(AOP)とCustom Origin Trust Store(COTS)の2製品で、格子ベースのデジタル署名アルゴリズムML-DSAを導入する。これにより、Cloudflareと顧客オリジン間の相互TLS接続を完全に量子耐性化できるようになった。

今回の対応は、Cloudflareが掲げる2029年の完全ポスト量子セキュリティ達成に向けたマイルストーンの第一歩だ。量子コンピュータによるなりすまし攻撃の脅威が現実味を増すなか、暗号化だけでなく認証のレベルでも対策を打てる段階に入ったことを意味する。

量子コンピュータに備える認証のアップグレード

量子コンピュータに備える認証のアップグレード

Harvest-Now/Decrypt-Laterだけでは足りない

これまで量子耐性の議論は「Harvest-Now/Decrypt-Later」と呼ばれる攻撃への対策が中心だった。攻撃者が現在の暗号化通信を蓄積しておき、将来の量子コンピュータで解読するというシナリオだ。Cloudflareも2022年から来訪者との接続、2023年からはオリジン接続でポスト量子暗号化をサポートし、広く使われてきた。

しかし、近年の量子コンピュータと暗号解読のブレークスルーにより、スケジュールが前倒しされている。問題は暗号化にとどまらない。量子コンピュータは古典的な認証情報も破ることができるため、攻撃者が正規のサーバーになりすます「なりすまし攻撃」の脅威が高まっている。そこで認証にもポスト量子の仕組みを導入する必要が出てきた。

オリジン接続だからこそ先行できる理由

訪れるユーザーとCloudflareの間の接続(コネクション1)では、Web PKIの制約があり、ポスト量子証明書の普及には時間がかかる。一方、Cloudflareと顧客オリジンサーバー間の接続(コネクション2)は、あらかじめ信頼関係が確立された閉じた環境だ。このため、公開インターネット向けの証明書基盤を待たずに、独自のPKIでML-DSA署名を導入できる。

また、Cloudflareがクライアント側になるため、接続プーリングによって多数のリクエストを少数の接続に集約できる。これにより、ポスト量子署名の処理負荷をならすことが可能だ。クラウドサービスならではの制御性を活かし、Web PKIが同様の対応をするよりも早く、実際に運用できる段階までこぎつけた。

従来のTLS接続(Before)
ユーザー Cloudflare オリジン
認証はRSA/ECDSAベース → 量子攻撃で危殆化の可能性
ポスト量子mTLS接続(After)
ユーザー Cloudflare オリジン
双方向でML-DSA署名を使用。オリジンはCloudflareのクライアント証明書を検証

この接続構成では、Cloudflareがクライアント証明書を提示し、オリジン側でそれを検証することで、なりすましを阻止する。両者とも量子耐性のある署名アルゴリズムだけを信頼するよう設定すれば、ダウングレード攻撃も防げる。

AOPとCOTSの設定手順

AOPとCOTSの設定手順

ポスト量子認証を有効にするには、Custom Origin Trust Store(COTS)にML-DSAのCA証明書をアップロードし、Authenticated Origin Pulls(AOP)にはクライアント証明書と秘密鍵を登録する。以下にCloudflare APIを使った手順を示す。すべての鍵生成にはOpenSSL 3.5.0以降が必要で、秘密鍵はFIPS 204 seed-only形式を利用する。

COTS:オリジン証明書チェーンのML-DSA化

COTSは、デフォルトの公開CAに代えて顧客が指定したCAだけを信頼する仕組みだ。ML-DSA対応により、オリジンに接続する際のサーバー証明書をポスト量子化できる。まず、ML-DSA-44のプライベートCAを作成し、そのCAでオリジンサーバー証明書に署名する。

# プライベートML-DSA-44 CAの作成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-ca.key

openssl req -new -x509 -key origin-ca.key \
  -out origin-ca.crt -days 10950 \
  -subj "/CN=Origin Server CA"

# オリジンサーバー証明書の生成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-server.key

openssl req -new -key origin-server.key \
  -out origin-server.csr \
  -subj "/CN=origin.example.com"

openssl x509 -req -in origin-server.csr \
  -CA origin-ca.crt -CAkey origin-ca.key -CAcreateserial \
  -out origin-server.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\nsubjectAltName=DNS:origin.example.com\n")

生成したCA証明書をCOTSにアップロードし、SSL/TLSモードをFull(strict)に設定する。これでCloudflareは、アップロードされたCAからチェーンする証明書を持つオリジンとのみ接続するようになる。

AOP:Cloudflare側のクライアント証明書

オリジンサーバーがCloudflareからの接続だけを受け付けるようにするには、AOPでクライアント証明書を設定する。ML-DSA証明書とseed形式の秘密鍵をAPI経由で登録すれば、Cloudflareがオリジンに対して自らの身元を証明するようになる。

# AOP用CAとクライアント証明書の作成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-ca.key

openssl req -new -x509 -key aop-ca.key \
  -out aop-ca.crt -days 10950 \
  -subj "/CN=Authenticated Origin Pull CA"

openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-client.key

openssl req -new -key aop-client.key \
  -out aop-client.csr \
  -subj "/CN=cloudflare-aop-client"

openssl x509 -req -in aop-client.csr \
  -CA aop-ca.crt -CAkey aop-ca.key -CAcreateserial \
  -out aop-client.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\n")

AOPはゾーン単位またはホスト名単位で有効化できる。グローバル設定のML-DSA対応は、より大規模な変更が必要なため後日対応予定だ。

ダウングレード対策と接続確認

ポスト量子署名を導入しても、検証側が従来のRSAやECDSAを引き続き信頼していれば、経路上の攻撃者によるダウングレード攻撃を受ける可能性が残る。完全な量子耐性を確保するには、オリジン側で量子脆弱な認証方式を無効化し、ML-DSAのみを信頼する設定にしなければならない。

設定後は、openssl s_clientで署名タイプを確認したり、nginxのログにクライアント証明書のシリアル番号を出力させたりして、CloudflareがML-DSA証明書を提示していることを検証する。鍵合意でもX25519MLKEM768がネゴシエートされていることをあわせて確認したい。

STEP 1 ML-DSA鍵と証明書をOpenSSLで生成
STEP 2 CA証明書をCOTSに、クライアント証明書をAOPにアップロード
STEP 3 オリジンサーバーでnginxのssl_verify_clientをonに設定
STEP 4 Full(strict)で接続し、ログでML-DSA署名を確認

これらの手順を踏むことで、Cloudflareとオリジン間の通信が暗号化と認証の両面でポスト量子化される。

実装の舞台裏と教訓

実装の舞台裏と教訓

制御プレーンはGoの壁をCIRCLで突破

CloudflareのSSL/TLS設定を管理するサービスはGoで書かれている。ML-DSA対応にあたり、Goの標準ライブラリがまだ同アルゴリズムをサポートしていないという課題があった。そこでCloudflareは自社の暗号ライブラリCIRCLに必要な機能を実装し、標準ライブラリの不足を補った。

ただし、このアドホックな対応は一時的なもので、2026年8月にリリース予定のGo 1.27ではML-DSAがネイティブサポートされる。バージョンアップのみで多くのサービスがポスト量子認証に対応できるようになるため、エコシステム全体にとっての追い風となる見込みだ。

BoringSSL更新の遅れとインシデント

データプレーン側では、プロキシフレームワークPingoraのオリジン接続サービスがBoringSSLに依存している。同ライブラリには4年間ものアップデートが行われておらず、Cloudflareは内部フォークをメンテナンスして機能を追加していた。ML-DSAサポートがBoringSSL本体に取り込まれたことを機に、ついにアップデートを決断した。

しかし、4年分の変更にはKeyUsageルールの厳格化が含まれており、一部の顧客証明書がRFC準拠でないと判定されてしまった。慎重にテストを重ねたにもかかわらず、2026年6月10日に小規模な接続障害が発生し、ロールバックを余儀なくされた。その後、RSA証明書向けの緩和パッチを当てて再開し、現在は安定稼働している。長期間アップデートを控えることのリスクを改めて浮き彫りにした出来事だったといえる。

完全ポスト量子化へのロードマップ

完全ポスト量子化へのロードマップ

Cloudflareは2029年の完全ポスト量子セキュリティ達成を目標に掲げている。今回のAOP/COTS対応は最初のマイルストーンに過ぎない。ユーザーとCloudflare間の認証については、IETFで策定が進むMerkle Tree Certificates(MTC)による高速なポスト量子証明書の実験を経て、2027年をめどに初期展開を予定している。

Go 1.27の登場やブラウザベンダーの取り組みが進むにつれ、ポスト量子認証は急速に普及すると予想される。ひとまず、オリジンとの相互接続でML-DSAによる完全な量子耐性を確保できるようになったことは、インフラを預かる技術者にとって心強い前進だ。Cloudflareの製品別ポスト量子対応状況は、公式ドキュメントで継続的に更新されているため、導入の際は参照してほしい。

この記事のポイント

  • CloudflareがAOPとCOTSでML-DSA署名をサポートし、オリジン接続の相互TLSをポスト量子化
  • 量子コンピュータによるなりすまし攻撃に備え、暗号化だけでなく認証の強化が急務に
  • OpenSSL 3.5.0+で鍵生成し、API経由で証明書をアップロード。ダウングレード防止には従来署名の信頼解除が必須
  • Go 1.27のネイティブML-DSAサポートなど、エコシステム整備が加速中