Skip to content

CLOUDFLARE

Read original ↗

Post-quantum authentication to origins is now supported

Summary

Cloudflare announces that its Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS) products now support post-quantum authentication via ML-DSA (FIPS 204) — all three parameter sets (ML-DSA-44, ML-DSA-65, ML-DSA-87). This is the first milestone of Cloudflare's 2029 PQ-security roadmap: fully post-quantum secure mutually authenticated TLS connections between Cloudflare and customer origin servers. ML-DSA-44 is the recommended default for most applications (NIST category 2 security, most performant).

This deployment is possible ahead of WebPKI because the Cloudflare-to-origin connection has unique properties: Cloudflare is the TLS client (enabling connection pooling to amortize handshake overhead), a pre-existing trust relationship exists (Cloudflare account), and the connection need not rely on public CA infrastructure.

Key takeaways

  1. First PQ-roadmap milestone delivered — Cloudflare's April 2026 roadmap named "Mid-2026: ML-DSA Cloudflare→origin" as the first checkpoint. This post marks delivery of that milestone.

  2. Two-product support — COTS lets customers upload ML-DSA CAs so Cloudflare trusts PQ-signed origin server certificates; per-zone and per-hostname AOP lets customers upload ML-DSA client certificates and private keys (FIPS 204 seed format) so Cloudflare presents them to authenticate itself to the origin.

  3. Downgrade avoidance is necessary, not just PQ enablement — If the origin still trusts classical CAs / client certs, an on-path attacker with a CRQC can forge classical credentials. The fix: remove trust in quantum-vulnerable authentication mechanisms on the verifying party. (Source: Chromium Security team's four-stage plan referenced.)

  4. Connection pooling makes drop-in PQ signatures palatable — Cloudflare fans in requests from across the network to a smaller set of connections to each origin, amortizing handshake overhead over many requests. This makes the larger ML-DSA signature/key sizes (vs Ed25519/RSA) acceptable for the Cloudflare→origin hop without needing Merkle Tree Certificates.

  5. Control plane: Go + CIRCL — The SSL/TLS control plane service (HA setup across critical DCs, pushes config to Quicksilver global KV store) needed ML-DSA X.509 parsing. Go's stdlib didn't support ML-DSA yet, so Cloudflare implemented it in their CIRCL library (github.com/cloudflare/circl PR #559). Go 1.27 (expected August 2026) will include native ML-DSA support, allowing CIRCL dependency removal.

  6. Data plane: Pingora Origin + BoringSSL — The Pingora Origin service (Rust, handles all origin connections) uses BoringSSL for TLS. PQ authentication support landed in BoringSSL in April 2026. Cloudflare had snoozed its BoringSSL update for four years, maintaining an internal fork — the PQ auth requirement motivated the long-overdue update.

  7. BoringSSL update incident (June 10, 2026) — The four-year BoringSSL jump included a KeyUsage enforcement commit that deemed some customers' certificates (with technically invalid KeyUsage for RSA) as invalid, causing an incident. Cloudflare rolled back, then patched to retain support for non-compliant RSA certificates. Classic case of "the Internet is not RFC compliant."

  8. AOP is free on all plans — Post-quantum mutual TLS to origins is available on all Cloudflare plan levels (COTS requires Advanced Certificate Manager). This continues the default-on security upgrade posture.

  9. OpenSSL 3.5.0+ required for key generation — Private keys must be in FIPS 204 seed-only encoding, which is the only format Cloudflare accepts on upload.

  10. Ecosystem readiness growing — Go 1.27 (August 2026) will bring native ML-DSA to Go services. TLS libraries broadly adding ML-DSA support. The post-quantum authentication ecosystem is converging on ML-DSA as the deployable algorithm, consistent with the July 9 survey.

Architectural details

Two-connection model

  • Connection 1 (visitor → Cloudflare): PQ encryption since 2022 (>65% of human traffic). PQ authentication via MTC targeting 2027.
  • Connection 2 (Cloudflare → origin): PQ encryption since
  • PQ authentication via ML-DSA now live (this post).

The Cloudflare→origin connection is architecturally distinct from visitor→Cloudflare in three ways:

  1. Cloudflare is the TLS client — connection pooling fans in many requests to fewer connections, amortizing per-handshake PQ-signature cost.
  2. Pre-existing trust relationship (Cloudflare account) — no public-CA constraint; custom PKI is acceptable.
  3. No WebPKI/CT overhead — no intermediate certificate chains, no Certificate Transparency logs.

Configuration levels

Product PQ support Requirements
COTS (server auth) ML-DSA-44/65/87 CA upload Advanced Certificate Manager + Full (strict) SSL
AOP per-zone ML-DSA-44/65/87 client cert + seed-format key Free (all plans) + Full SSL mode
AOP per-hostname Same as per-zone Free (all plans) + Full SSL mode
AOP global Not yet (more involved change) Future

Control plane architecture

The service managing SSL/TLS product configuration runs in a HA setup across critical data centers. It handles settings updates and pushes them to Cloudflare's globally-distributed KV store (Quicksilver) for data-plane consumption. ML-DSA cert parsing required adding functionality to CIRCL since Go's X.509/TLS libraries lack native ML-DSA support (until Go 1.27, expected August 2026).

Data plane architecture

Pingora Origin handles all Cloudflare→origin connections. It uses BoringSSL for TLS. The BoringSSL update to bring in PQ authentication support was the first in four years (Cloudflare had maintained an internal fork for that period). The update bundled thousands of commits, including a KeyUsage enforcement change that caused a production incident on June 10, 2026.

Operational numbers

  • All three FIPS 204 parameter sets supported: ML-DSA-44 (recommended), ML-DSA-65, ML-DSA-87.
  • Four-year BoringSSL update gap — the longest Cloudflare had gone without updating BoringSSL in Pingora Origin.
  • >65% of human traffic to Cloudflare already PQ-encrypted (Connection 1, since 2022).
  • X25519MLKEM768 recommended as the key agreement group on origin TLS configuration for fully PQ-secure connections.
  • PQ authentication on AOP available for free on all Cloudflare plan levels.

Caveats

  • Global-level AOP not yet PQ-enabled (described as "a more involved change that will be prioritized at a later date").
  • Private key format: only FIPS 204 seed-only encoding accepted; requires OpenSSL 3.5.0+.
  • BoringSSL update risk: the four-year update gap means any future BoringSSL update carries similar aggregated-change risk.
  • WebPKI-dependent customers cannot use this yet — they must wait for MTC (Mid-2027 target).
  • No production performance numbers disclosed (latency impact of ML-DSA verification on the handshake path).
  • Origin server support required: origin TLS stack must support ML-DSA certificates (e.g., OpenSSL 3.5.0+ or a library with FIPS 204 support).

Source

Last updated · 602 distilled / 1,824 read