Centocinquanta millisecondi sul p90: è la latenza che Cloudflare dichiara di avere eliminato sui nuovi handshake verso gli origin già analizzati. Il risultato non arriva da un plugin WordPress o da una cache più aggressiva. Arriva da una scelta fatta nel primo pacchetto TLS, prima che il server abbia risposto. Per chi gestisce un sito dietro Cloudflare, la novità dell’8 settembre 2026 trasforma la crittografia post-quantum da progetto teorico a controllo concreto dell’infrastruttura.

Cloudflare chiama il sistema Automatic Key Exchange. Il servizio sonda gli origin, impara quale scambio di chiavi preferiscono e usa subito quello corretto nelle connessioni successive. Se l’origin supporta X25519MLKEM768, la connessione tra edge e server può usare uno scambio ibrido: X25519 mantiene la protezione classica, ML-KEM aggiunge la componente resistente agli attacchi quantistici.

La conseguenza operativa è semplice: non devi installare niente dentro WordPress. Devi capire quale tratto della connessione è già protetto, verificare il tuo origin e rimuovere eventuali incompatibilità. Forzare l’algoritmo senza questa verifica può invece interrompere tutte le connessioni TLS 1.3 verso il server.

Il numero nuovo: 45 miliardi di connessioni al giorno

Nel campione già sottoposto a scansione, Cloudflare ha assegnato X25519MLKEM768 come preferenza a circa il 33% dei domini. Il 64% è rimasto su X25519 e il 3% su altre curve classiche. La quota di handshake post-quantum completati senza HelloRetryRequest è passata dallo 0% al 99,2%. Il traffico post-quantum verso gli origin è salito da circa 25 a 45 miliardi di connessioni al giorno.

Il punto non è il volume globale. È il meccanismo. In TLS 1.3 il client propone una key share nel primo ClientHello. Se propone X25519 ma l’origin preferisce l’ibrido X25519+ML-KEM, il server chiede un nuovo tentativo. Quel HelloRetryRequest aggiunge un round trip. Cloudflare dichiara che il tasso complessivo di questi retry, sui domini analizzati, è sceso dal 52% al 3,7%.

Un sito WordPress con molte pagine in cache non vedrà 150 millisecondi in meno su ogni visita: le connessioni keep-alive non rifanno l’handshake e le risposte servite direttamente dall’edge non raggiungono l’origin. Il beneficio emerge soprattutto su cache miss, richieste dinamiche e nuove connessioni edge-origin. Va misurato lì, non su uno screenshot isolato di PageSpeed.

Le tre tratte TLS che non devi confondere

Una richiesta a un WordPress dietro CDN attraversa almeno tre contesti distinti. La documentazione Cloudflare sulla crittografia post-quantum li separa in modo netto:

  1. dal browser del visitatore all’edge Cloudflare;
  2. all’interno della rete Cloudflare;
  3. dall’edge Cloudflare al server origin che esegue WordPress.

Il primo tratto usa lo scambio ibrido solo se anche il browser lo supporta. Il terzo dipende dal server, dalla libreria TLS e dagli apparati presenti prima dell’origin. Vedere il lucchetto nel browser dimostra che HTTPS funziona, non che l’intero percorso usa ML-KEM.

C’è poi una seconda distinzione. Lo scambio di chiavi protegge la confidenzialità della sessione. La firma autentica le parti. Cloudflare supporta ML-KEM per il key agreement e, in configurazioni origin specifiche, ML-DSA per le firme. Attivare il primo non rende automaticamente post-quantum anche il certificato che autentica il server.

Questa mappa evita l’errore più comune: testare il dominio pubblico, vedere X25519MLKEM768 e concludere che anche l’origin è pronto. Se il DNS è proxied, quel test raggiunge l’edge. Per controllare il server devi usare il suo hostname o IP origin autorizzato, senza pubblicarlo e senza aggirare le regole di accesso.

Perché WordPress non c’entra, ma il tuo hosting sì

WordPress genera HTML e risponde tramite PHP. La negoziazione TLS termina prima, di solito su Nginx, Apache, LiteSpeed, un load balancer o il proxy del provider. Un aggiornamento di WordPress non aggiunge il supporto a ML-KEM. Un plugin di sicurezza non può correggere una libreria TLS vecchia o un firewall che scarta un ClientHello più grande.

L’ibrido post-quantum occupa più spazio. Cloudflare spiega che un ClientHello con ML-KEM viene normalmente diviso su due pacchetti, mentre quello classico con X25519 entra quasi sempre in uno. Apparati datati, buffer troppo piccoli o middlebox irrigiditi su un comportamento storico possono non riassemblarlo correttamente.

È un problema di filiera simile a quello descritto nella guida sui router con backdoor e controlli di supply chain: il CMS può essere aggiornato, ma la sicurezza effettiva dipende anche dai componenti davanti e dietro di lui. Qui i componenti da censire sono terminatore TLS, firewall, bilanciatore, pannello hosting e versione della libreria crittografica.

Prima di chiedere “WordPress è post-quantum?”, chiedi quindi al provider dove termina TLS e quale software gestisce la connessione. È la domanda che produce una risposta verificabile.

Audit in 30 minuti: la sequenza corretta

1. Disegna il percorso reale

Annota dominio pubblico, proxy Cloudflare, eventuale load balancer, hostname origin e server web. Segna dove sono installati i certificati e chi gestisce ogni tratto. Se non conosci l’origin, fermati qui e chiedilo all’hosting: fare prove su un indirizzo ipotizzato produce solo falsi positivi.

2. Controlla TLS 1.3

Automatic Key Exchange riguarda gli origin che parlano TLS 1.3. Verifica che la modalità SSL/TLS di Cloudflare non sia Off o Flexible. Per un sito professionale la base resta Full (strict), con certificato valido sull’origin. Questa scelta non prova la compatibilità post-quantum, ma elimina una configurazione debole prima di aggiungere complessità.

3. Verifica il tratto browser-edge

Usa il controllo del browser offerto da Cloudflare Radar con un browser aggiornato. Il risultato riguarda il dispositivo e l’edge. Ripeti il test sui browser realmente usati dal team, soprattutto se ci sono postazioni gestite con versioni bloccate o proxy aziendali.

4. Verifica l’origin separatamente

La guida Cloudflare per il tratto edge-origin propone bssl di BoringSSL:

bssl client -connect origin.example.com:443 -curves X25519MLKEM768

L’output deve indicare X25519MLKEM768 come curva ECDHE negoziata. Esegui il comando solo verso un origin che amministri e preserva il nome server corretto quando l’hosting usa SNI. Se l’origin non è esposto pubblicamente, esegui il test dalla rete autorizzata o chiedi al provider una prova equivalente.

5. Controlla gli apparati intermedi

Un test negativo non significa per forza che il server non conosca ML-KEM. Può essere un firewall che scarta il ClientHello su più segmenti. Ripeti il controllo prima e dopo ciascun livello, se la tua architettura lo consente, oppure apri un ticket con un dato preciso: “TLS 1.3 funziona con X25519, fallisce con X25519MLKEM768”.

Automatic Key Exchange: cosa lasciare automatico

Automatic Key Exchange è attivo per le zone esistenti e viene abilitato per default su quelle nuove. Quando l’origin supporta sia X25519 sia X25519MLKEM768, Cloudflare preferisce l’opzione ibrida. Se non la supporta, continua a proporre un algoritmo compatibile e può comunque ridurre i retry imparando la curva classica preferita dal server.

La vecchia API “Origin Post-Quantum Encryption” resta visibile, ma secondo la documentazione le sue richieste non modificano più il comportamento del key agreement. Costruire oggi un’automazione che la chiama significa automatizzare un no-op destinato alla deprecazione.

Non forzare l’ibrido su un origin non verificato. Cloudflare avverte che, se manca un algoritmo in comune, tutte le connessioni TLS 1.3 falliscono. La scelta sensata per una PMI è lasciare che lo scanner apprenda la compatibilità, risolvere gli errori dell’origin e forzare solo quando esiste un requisito di conformità documentato.

Questa è la mia take: l’automazione qui vale più della configurazione manuale. Non perché sia infallibile, ma perché la compatibilità TLS cambia quando l’hosting aggiorna librerie, bilanciatori o firewall. Una scansione ricorrente intercetta quel cambiamento meglio di una spunta impostata una volta e dimenticata.

Quando serve Cloudflare Tunnel

Se l’hosting non supporta ancora ML-KEM sull’endpoint pubblico, Cloudflare indica Tunnel come alternativa. cloudflared apre una connessione in uscita dall’ambiente origin verso la rete Cloudflare e usa uno scambio di chiavi post-quantum su quel tunnel. L’origin non richiede un IP pubblico esposto.

Non è una modifica da applicare solo per ottenere un badge. Cambia rete, osservabilità e procedura di emergenza. Prima di adottarla devi provare almeno avvio automatico del tunnel, failover, accesso amministrativo fuori banda e ripristino dopo il reboot. Il test è simile a quello di un backup che deve essere anche ripristinabile: la configurazione esistente non basta, serve una prova del percorso di ritorno.

Cloudflare precisa inoltre che Tunnel usa il key agreement post-quantum, ma non ancora firme post-quantum per l’autenticazione di quel tratto. È un miglioramento della confidenzialità, non la chiusura di ogni voce della migrazione crittografica.

Le firme ML-DSA sono un progetto separato

Per la connessione edge-origin, Cloudflare documenta firme ML-DSA tramite Authenticated Origin Pulls e Custom Origin Trust Store. Le due funzioni possono essere usate insieme: Cloudflare presenta un certificato client all’origin e valida una CA configurata dal cliente. Servono una libreria TLS compatibile, per esempio OpenSSL 3.5 o successivo, e un origin che negozi TLS 1.3.

Authenticated Origin Pulls impedisce inoltre che un visitatore raggiunga direttamente l’origin aggirando il WAF, purché il server sia configurato per accettare solo le richieste autenticate. Non funziona con modalità Off o Flexible e non è compatibile con Cloudflare Tunnel.

Per un WordPress su hosting condiviso, questa parte può dipendere interamente dal provider. Per un VPS gestito internamente, va trattata come modifica infrastrutturale: staging, certificati, rollback e monitoraggio degli errori TLS. Non improvvisarla durante una finestra di traffico.

Cosa misurare dopo la verifica

Non usare il punteggio Lighthouse come prova crittografica. Registra invece quattro dati:

  • algoritmo negoziato sul tratto browser-edge;
  • algoritmo negoziato sul tratto edge-origin;
  • tasso di errori TLS e timeout verso l’origin;
  • latenza delle richieste dinamiche e dei cache miss, confrontata sul p50 e sul p90.

Se hai Logpush o Log Explorer, Cloudflare espone ClientTLSKeyExchangeGroup per misurare l’adozione post-quantum del traffico in ingresso alla zona. Quel campo parla dei client. Per l’origin servono i test separati e la telemetria del server.

Conserva il risultato nell’inventario tecnico insieme a scadenze certificate, versione PHP, server web e responsabile del rinnovo. Lo stesso principio vale per un audit del fingerprinting su WordPress: il controllo utile è ripetibile, attribuito e produce un dato confrontabile. Una prova fatta una volta non è governance.

Decisione operativa per tre scenari

WordPress gestito dietro Cloudflare

Verifica TLS 1.3, modalità Full (strict) e supporto dell’origin. Lascia Automatic Key Exchange in automatico. Se il test fallisce, apri un ticket al provider con algoritmo e percorso esatti. Non installare plugin.

VPS o server amministrato dal tuo team

Inventaria libreria TLS e terminatore, prova X25519MLKEM768 in staging, controlla firewall e bilanciatori, poi monitora errori e latenza. Valuta AOP e firme ML-DSA come progetto successivo, con rollback.

Dati che devono restare segreti per molti anni

Dai priorità alla migrazione. Il rischio “harvest now, decrypt later” riguarda dati intercettati oggi e decifrati in futuro. NIST ha standardizzato ML-KEM in FIPS 203 nell’agosto 2024 e invita le organizzazioni ad avviare la migrazione. Classifica quindi i dati per durata di riservatezza, non solo per probabilità di un computer quantistico domani mattina.

Chiusura operativa

Per la maggior parte dei siti WordPress la mossa corretta non è “attivare il post-quantum”. È verificare le tre tratte, lasciare Automatic Key Exchange libero di scegliere, aggiornare l’origin quando il test fallisce e misurare gli errori dopo ogni cambiamento.

La crittografia post-quantum non si gestisce dal pannello dei plugin. Si gestisce nell’inventario dell’infrastruttura. Se domani cambi hosting, CDN o load balancer, ripeti il test: la protezione appartiene al percorso, non al dominio scritto nel browser.

Fonti