Cloudflare's Post-Quantum Authentication to Origins
This article details Cloudflare's implementation of post-quantum (PQ) authentication for connections between its edge network and customer origin servers. It covers the architectural considerations and configuration steps for ML-DSA based authentication, highlighting the unique challenges and solutions for Cloudflare-to-origin connections compared to client-to-Cloudflare connections. The discussion includes control and data plane changes, emphasizing secure migration strategies against future quantum attacks.
Read original on Cloudflare BlogThe advent of quantum computing poses a significant threat to current cryptographic standards, necessitating a shift towards post-quantum cryptography. Cloudflare's initiative to implement post-quantum authentication aims to protect against harvest-now/decrypt-later attacks and impersonation attacks, where quantum computers could break classical credentials. This effort is part of a broader roadmap to achieve full post-quantum security.
Architectural Context: Two Connections
When a user accesses a website via Cloudflare, two primary TLS connections are established: visitor-to-Cloudflare (Connection 1) and Cloudflare-to-origin (Connection 2). While post-quantum encryption has been enabled for both, post-quantum authentication presents distinct challenges for each. The article focuses on Connection 2, where Cloudflare acts as the client, offering more control over deployment strategies.
Why Cloudflare-to-Origin is Different
- Client Control: Cloudflare is the client, allowing for techniques like connection pooling to amortize the overhead of post-quantum signatures.
- Custom PKI: A pre-existing trust relationship with customers enables using custom Public Key Infrastructures (PKIs) tailored to the use case, bypassing constraints of the public WebPKI.
- ML-DSA Adoption: These unique requirements allow for earlier adoption of ML-DSA (Module-Lattice-Based Digital Signature Algorithm) authentication.
Engineering Implementation: Control and Data Planes
Implementing post-quantum authentication involved modifications to both Cloudflare's control plane and data plane services. The control plane, responsible for managing TLS settings and certificate uploads, needed updates to parse and validate ML-DSA certificates. This initially required patching Go's standard libraries with Cloudflare's CIRCL library due to lack of native ML-DSA support, a temporary measure until Go 1.27's anticipated release. The data plane service, which establishes TLS connections, then utilizes these configurations for secure communication.
Mitigating Downgrade Attacks
Achieving full post-quantum security requires not only adding PQ mechanisms but also removing trust in quantum-vulnerable authentication mechanisms from the verifying party. This prevents on-path attackers from forging classical credentials and forcing a downgrade to less secure protocols.
Configuration for Post-Quantum Origin Connections
- Custom Origin Trust Store (COTS): Allows customers to upload ML-DSA CAs, enabling Cloudflare to trust origin server certificates chaining to these CAs when in Full (strict) SSL mode.
- Authenticated Origin Pulls (AOP): Supports uploading ML-DSA client certificates and private keys (FIPS 204 seed format) for mutual TLS (mTLS) authentication between Cloudflare and the origin server. This ensures only requests from Cloudflare are served.
ssl_certificate /etc/nginx/certs/mldsa44_origin.crt;
ssl_certificate_key /etc/nginx/private/mldsa44_origin.key;
ssl_client_certificate /etc/nginx/certs/mldsa44_cloudflare_ca.crt;
ssl_verify_client on;
ssl_verify_depth 2;