Durante la Security Week 2025, abbiamo lanciato la prima soluzione Secure Web Gateway (SWG) e Zero Trust post-quantistica cloud native del settore, un passo importante verso la protezione del traffico di rete aziendale inviato dai dispositivi degli utenti finali alle reti pubbliche e private.
Ma questa è solo una parte dell'equazione. Per proteggere davvero il futuro delle reti aziendali, è necessario un Secure Access Service Edge (SASE) completo.
Oggi chiudiamo il cerchio: Cloudflare One è la prima piattaforma SASE a supportare la moderna crittografia post-quantistica (PQ) conforme agli standard nel nostro Secure Web Gateway e nei casi d'uso Zero Trust e Wide Area Network (WAN). Più specificamente, Cloudflare One ora offre ML-KEM ibrido (Module-Lattice-based Key-Encapsulation Mechanism) post-quantistico su tutti i principali on-ramp e off-ramp.
Per completare il quadro, abbiamo aggiunto il supporto per la crittografia post-quantistica al nostro Cloudflare IPsec (la nostra WAN-as-a-Service cloud native) e Cloudflare One Appliance (la nostra appliance WAN fisica o virtuale che stabilisce connessioni Cloudflare IPsec). Cloudflare IPsec utilizza il protocollo IPsec per stabilire tunnel crittografati dalla rete di un cliente alla rete globale di Cloudflare, mentre IP Anycast viene utilizzato per instradare automaticamente quel tunnel al datacenter Cloudflare più vicino. Cloudflare IPsec semplifica la configurazione e fornisce alta disponibilità; se un datacenter specifico non è più disponibile, il traffico viene reindirizzato automaticamente al datacenter integro più vicino. Cloudflare IPsec funziona sulla scala della nostra rete globale e supporta connessioni site-to-site su una WAN, nonché connessioni in uscita verso Internet.
L'upgrade di Cloudflare One Appliance è ora disponibile per tutti gli utenti a partire dalla versione dell'appliance 2026.2.0. L'upgrade Cloudflare IPsec è in versione beta chiusa ed è possibile richiedere l'accesso aggiungendo il proprio nome al nostro elenco di versioni beta chiuse.
La crittografia post-quantistica ora è davvero importante
Le minacce quantistiche non sono un problema del "prossimo decennio". Ecco perché oggi i nostri clienti danno la priorità alla crittografia post-quantistica (PQC):
La scadenza si avvicina. Alla fine del 2024, il National Institute of Standards and Technology (NIST) ha inviato un segnale chiaro (che è stato ripreso da altre agenzie): l'era della crittografia a chiave pubblica classica sta volgendo al termine. Il NIST ha fissato una scadenza nel 2030 per la dismissione di RSA ed Elliptic Curve Cryptography (ECC) e la transizione a PQC che non può essere interrotta dai potenti computer quantistici. Le organizzazioni che non hanno iniziato la migrazione rischiano di essere non conformi e vulnerabili con l'avvicinarsi della scadenza.
In passato, gli aggiornamenti si sono sempre rivelati complessi. Sebbene il 2030 possa sembrare lontano, l'upgrade degli algoritmi crittografici è notoriamente difficile. La storia ci ha dimostrato che l'obsolescenza della crittografia può richiedere decenni: abbiamo trovato esempi di MD5 che causa problemi 20 anni dopo la sua dismissione. Questa mancanza di agilità crittografica, ovvero la capacità di sostituire facilmente gli algoritmi crittografici, è un grave collo di bottiglia. Integrando la crittografia PQ direttamente in Cloudflare One, la nostra piattaforma SASE, forniamo agilità crittografica integrata, semplificando il modo in cui le organizzazioni offrono l'accesso remoto e la connettività site-to-site.
I dati potrebbero essere già a rischio. Infine, "Harvest Now, Decrypt Later" è una minaccia presente e persistente, in cui oggi gli aggressori raccolgono il traffico di rete sensibile e lo archiviano fino a quando i computer quantistici non diventano abbastanza potenti da decrittografarlo. Se i dati hanno una durata di conservazione superiore a qualche anno (ad es. informazioni finanziarie, dati sanitari, segreti di stato), sono già a rischio a meno che non siano protetti dalla crittografia PQ.
Le due migrazioni sul percorso verso la sicurezza quantistica: key agreement e firme digitali
La transizione del traffico di rete alla crittografia post-quantistica (PQC) richiede una revisione di due primitive crittografiche: key agreement e firme digitali.
Migrazione 1: definizione della chiave. Il key agreement consente a due parti di stabilire un segreto condiviso su un canale non sicuro; il segreto condiviso viene quindi utilizzato per crittografare il traffico di rete, con conseguente crittografia post-quantistica. Il settore è ampiamente convergente su ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) come protocollo standard di key agreement PQ.
ML-KEM è stato ampiamente adottato per l'uso in TLS, solitamente distribuito insieme al classico Elliptic Curve Diffie Hellman (ECDHE), in cui la chiave utilizzata per crittografare il traffico di rete viene derivata combinando gli output dei key agreement ML-KEM ed ECDHE. (Questo è anche noto come "ML-KEM ibrido"). Ben oltre il 60% del traffico TLS generato dall'uomo verso la rete di Cloudflare è attualmente protetto con ML-KEM ibrido. La transizione all'ML-KEM ibrido ha avuto successo perché:
Poiché ML-KEM viene eseguito in parallelo con l'ECDHE classico, non vi è alcuna riduzione in termini di sicurezza e conformità rispetto al classico approccio ECDHE.
Migrazione 2: firme digitali. Nel frattempo, le firme digitali e i certificati proteggono l'autenticità, impedendo agli avversari attivi di impersonare il server per il client. Purtroppo, le firme PQ sono attualmente di dimensioni maggiori rispetto ai classici algoritmi ECC, il che ha rallentato la loro adozione. Per fortuna, la migrazione alle firme PQ è meno urgente, perché le firme PQ sono progettate per bloccare gli avversari attivi armati di potenti computer quantistici, di cui non si è ancora certi dell'esistenza. Pertanto, mentre Cloudflare sta contribuendo attivamente alla standardizzazione e all'implementazione delle firme digitali PQ, l'attuale upgrade IPsec di Cloudflare si concentra sull'upgrade dello scambio di chiavi a ML-KEM ibrido.
La Cybersecurity & Infrastructure Security Agency (CISA) degli Stati Uniti ha riconosciuto la natura di queste due migrazioni nella sua pubblicazione di gennaio 2026, "Categorie di prodotti per le tecnologie che utilizzano gli standard di crittografia post-quantistica".
Esplorare nuove frontiere con IPsec
Per ottenere un SASE completamente protetto con crittografia post-quantistica, abbiamo effettuato l'upgrade dei nostri prodotti Cloudflare IPsec per supportare l'ML-KEM ibrido nel protocollo IPsec.
Il percorso della community IPSec verso la crittografia post-quantistica è stato molto diverso da quello di TLS. TLS è lo standard de facto per la crittografia del traffico Internet pubblico al livello 4, ad es. da un browser a una rete per la distribuzione di contenuti (CDN), quindi la sicurezza e l'interoperabilità dei fornitori sono in prima linea nella sua progettazione. Nel frattempo, IPsec è un protocollo di livello 3 che collega comunemente dispositivi realizzati dallo stesso fornitore (ad esempio due router), quindi l'interoperabilità è stata storicamente meno preoccupante. Tenendo presente questo, diamo un'occhiata al percorso di IPsec nel futuro quantistico.
Chiavi pre-condivise? Distribuzione delle chiavi quantistiche?
RFC 8784, pubblicato a maggio 2020, doveva essere l'aggiornamento post-quantistico di IPsec Internet Key Exchange v2 (IKEv2), utilizzato per stabilire le chiavi simmetriche utilizzate per crittografare il traffico di rete IPsec. RFC 8784 implica l'uso di chiavi pre-condivise di lunga durata (PSK) o di distribuzione di chiavi quantistiche (QKD). Nessuno di questi approcci è particolarmente praticabile.
RFC 8784 propone di combinare una PSK con una chiave derivata da Diffie Hellman Exchange (DHE), eseguendo essenzialmente PSK in ibrido con DHE. Questo approccio protegge dagli aggressori harvest-now-decrypt-later, ma non offre la forward secrecy contro gli avversari quantistici.
La forward secrecy è un requisito standard dei protocolli di key agreement. Garantisce che un sistema sia sicuro anche se la chiave a lungo termine trapela. L'approccio PSK in RFC 8784 è vulnerabile ad attacchi di tipo "harvest-now-decrypt-later", il quale ottiene anche una copia di una PSK di lunga durata e può quindi decrittografare il traffico in futuro (compromettendo il key agreement DHE) una volta che i potenti computer quantistici diventeranno disponibili.
Per risolvere questo problema di forward secrecy, RFC 8784 può invece essere utilizzato per combinare la chiave del classico DHE con una chiave appena generata derivata da un protocollo QKD.
QKD utilizza la meccanica quantistica per stabilire una chiave di crittografia segreta condivisa tra due parti. È importante sottolineare che, affinché QKD funzioni, le parti devono disporre di hardware specializzato o essere connesse tramite una connessione fisica dedicata. Questa è una limitazione significativa, che rende il QKD inutilizzabile per i casi d'uso comuni di Internet, come la connessione di un laptop a un server distante tramite Wi-Fi. Queste limitazioni sono anche il motivo per cui non abbiamo mai investito nel deployment di QKD per Cloudflare IPsec. Anche la National Security Agency (NSA) degli Stati Uniti, la BSI tedesca e il National Cyber Security Centre del Regno Unito hanno messo in guardia dal fare affidamento esclusivamente su QKD.
Ma che dire d'interoperabilità?
RFC 9370 è stato pubblicato a maggio 2023, specificando l'uso di un key agreement ibrido anziché PSK o QKD. Ma a differenza di TLS, che supporta solo l'utilizzo dell'ML-KEM post-quantistico in parallelo con il classico DHE, questo standard IPsec consente di utilizzare fino a sette diversi key agreement da eseguire contemporaneamente in parallelo con il classico Diffie-Hellman. Inoltre, non specifica i dettagli su quali dovrebbero essere questi key agreement, lasciando ai fornitori la scelta dei loro algoritmi e delle loro implementazioni. Palo Alto Networks, ad esempio, ha preso sul serio questo aspetto e ha integrato il supporto di oltre sette diverse suite di crittografia PQC nel suo Next Generation Firewall (NGFW), la maggior parte delle quali non interagisce con altri fornitori e alcune delle quali non sono ancora state standardizzate dal NIST.
Nel corso degli anni, TLS è andato nella direzione opposta, riducendo il numero di suite di crittografia registrate da centinaia in TLS 1.2, a circa cinque in TLS 1.3. Questa filosofia di riduzione del "ciphersuite bloat" è anche in linea con la SP 800 52 del NIST del 2019. La logica per ridurre il "ciphersuite bloat" include:
Miglioramento dell'interoperabilità tra fornitori e aree geografiche
Minore rischio di attacchi che sfruttano i downgrade a ciphersuite poco complesse
Minore rischio di problemi di sicurezza dovuti a configurazioni errate
Minore rischio di difetti di implementazione riducendo le dimensioni della base di codice
Questo è il motivo per cui inizialmente non abbiamo creato il supporto per RFC 9370.
Standard che sono finalmente sulla strada giusta
Questo è anche il motivo per cui siamo rimasti entusiasti quando la community IPsec ha presentato draft-ietf-ipsecme-ikev2-mlkem. Questa bozza Internet standardizza lo scambio PQ per IPsec nello stesso modo in cui lo scambio di chiavi PQ è stato ampiamente distribuito per TLS: ML-KEM ibrido. La nuova bozza colma le lacune in RFC 9370, specificando come eseguire ML-KEM come scambio di chiavi aggiuntivo in parallelo con il classico Diffie Hellman in IKEv2.
Ora che questa specifica è disponibile, abbiamo proseguito con il supporto dell'IPSec post-quantistico nei nostri prodotti Cloudflare IPsec.
Cloudflare IPsec diventa post-quantistico
Cloudflare IPsec è una soluzione WAN Network-as-a-Service che sostituisce le architetture di rete private legacy collegando datacenter, filiali e VPC cloud alla rete IP Anycast globale di Cloudflare.
Con Cloudflare IPsec, la rete di Cloudflare funge dal responder IKEv2, in attesa di richieste di connessione da un initiator IPsec, che è un dispositivo branch connector nella rete del cliente. Cloudflare IPsec supporta sessioni IPsec avviate da branch connector che includono la nostra Cloudflare One Appliance, insieme a branch connector da un insieme diversificato di fornitori, tra cui Cisco, Juniper, Palo Alto Networks, Fortinet, Aruba e altri.
Abbiamo implementato il supporto ML-KEM ibrido di produzione nel responder IKEv2 di Cloudflare IPsec, come specificato in draft-ietf-ipsecme-ikev2-mlkem. La bozza richiede un primo scambio di chiavi da eseguire utilizzando un classico scambio di chiavi Diffie Helman. La chiave derivata viene utilizzata per crittografare un secondo scambio di chiavi eseguito tramite ML-KEM. Infine, le chiavi derivate dai due scambi vengono combinate e il risultato viene utilizzato per proteggere il traffico del piano dati in modalità IPsec ESP (Encapsulating Security Payload). La modalità ESP utilizza la crittografia simmetrica ed è quindi già resistente alla crittografia quantistica senza ulteriori upgrade. Abbiamo testato la nostra implementazione rispetto all'initiator IPsec nell'implementazione di riferimento strongswan.
È possibile vedere la ciphersuite utilizzata nella negoziazione IKEv2 visualizzando i log IPsec di Cloudflare.
Abbiamo scelto di implementare l'ML-KEM ibrido piuttosto che l'ML-KEM "puro", ovvero solo ML-KEM senza DHE in esecuzione in parallelo, per due motivi. Innanzitutto, abbiamo utilizzato l'ML-KEM ibrido in tutti i nostri altri prodotti Cloudflare, poiché questo è l'approccio adottato nella community TLS. E in secondo luogo, fornisce una sicurezza "belt-and-suspenders": ML-KEM fornisce protezione contro gli attacchi quantistici harvest-now-decrypt-later, mentre DHE fornisce un algoritmo collaudato contro avversari non quantistici.
Un invito all'interoperabilità
Tutti i vantaggi di questa implementazione possono essere sfruttati solo tramite l'interoperabilità. Per questo motivo, stiamo invitando altri fornitori che stanno sviluppando il supporto per gli initiator IPsec nei loro branch connector, come da draft-ietf-ipsecme-ikev2-mlkem, a testare la nostra implementazione Cloudflare IPsec. I clienti di Cloudflare che desiderano testare l'interoperabilità con branch connector di terzi durante la nostra beta chiusa possono registrarsi qui. Prevediamo di sviluppare l'interoperabilità con altri fornitori e di renderla disponibile al pubblico man mano che un numero sempre maggiore di questi inizierà a supportare draft-ietf-ipsecme-ikev2-mlkem.
Hardware sicuro da un punto di vista quantistico: Cloudflare One Appliance
Molti dei nostri clienti acquistano il loro connettore di filiali (hardware o virtualizzato) da Cloudflare anziché da un fornitore di terzi. Ecco perché Cloudflare One Appliance, il nostro dispositivo plug-and-play che connette la tua rete locale a Cloudflare One, è stato sottoposto ad upgrade anche con la crittografia post-quantistica.
Cloudflare One Appliance non utilizza IKEv2 per il key agreement o la creazione di sessioni, optando invece per TLS. L'appliance avvia periodicamente un handshake TLS con l'edge di Cloudflare, condivide un segreto simmetrico sulla connessione TLS risultante, quindi inserisce tale segreto simmetrico nel livello ESP di IPsec, che quindi crittografa e autentica il traffico del piano dati IPsec. Questo design ci ha permesso di evitare di creare la logica dell'initiator IKEv2 e semplifica la manutenzione del connettore utilizzando le nostre librerie TLS esistenti.
Pertanto, l'upgrade di Cloudflare One Appliance alla crittografia PQ è stato solo una questione di effettuare l'upgrade di TLS 1.2 a TLS 1.3 con ML-KEM ibrido: un'operazione che abbiamo svolto molte volte su diversi prodotti Cloudflare.
Come posso attivarlo? E quanto costa?
Come sempre, questo upgrade a Cloudflare IPsec non comporta alcun costo aggiuntivo per i nostri clienti. Poiché crediamo che un Internet sicuro e privato debba essere accessibile a tutti, la nostra missione è includere PQC in tutti i nostri prodotti, senza hardware specializzato, a costo zero per i nostri clienti e utenti finali.
I clienti che utilizzano Cloudflare One Appliance hanno ottenuto questo upgrade a PQC nella versione 2026.2.0 (rilasciata l'11 febbraio 2026). L'upgrade viene eseguito automaticamente (senza richiedere l'intervento del cliente) in base alla finestra di interruzione configurata di ciascun dispositivo.
Per i clienti che utilizzano Cloudflare IPsec con l'appliance del branch connector di un altro fornitore, interagiremo con questi una volta che sarà disponibile un maggiore supporto per draft-ietf-ipsecme-ikev2-mlkem. Puoi anche contattarci direttamente per ottenere l'accesso alla versione beta chiusa e richiedere l'interoperabilità con il branch connector di un fornitore specifico.
Il quadro completo: SASE post-quantistico
La proposta di valore per un SASE post-quantistico è chiara: le organizzazioni possono ottenere una protezione end-to-end immediata per il proprio traffico di rete privata inviandolo su tunnel protetti dall'ML-KEM ibrido. Ciò protegge il traffico dagli attacchi harvest-now-decrypt-later, anche se non è ancora stato effettuato l'upgrade delle singole applicazioni nella rete aziendale a PQC.
Il diagramma sopra mostra come l'ML-KEM ibrido post-quantistico viene offerto in varie configurazioni di rete Cloudflare One. Include i seguenti on-ramp:
e i seguenti off-ramp:
Il diagramma seguente evidenzia una configurazione di rete di esempio che utilizza l'on-ramp di Cloudflare One Client per connettere un dispositivo a un server dietro un offramp di Cloudflare One Appliance. Il dispositivo dell'utente finale si connette alla rete Cloudflare (link 1) utilizzando MASQUE con ML-KEM ibrido. Il traffico transita quindi nella rete globale di Cloudflare su TLS 1.3 con ML-KEM ibrido (link 2). Il traffico lascia quindi la rete Cloudflare su un link Cloudflare IPsec post-quantistico (link 3) terminato su un'appliance Cloudflare One Appliance. Infine si connette a un server all'interno dell'ambiente del cliente. Il traffico è protetto dalla crittografia post-quantistica mentre transita sull'Internet pubblico, anche se il server stesso non supporta la crittografia post-quantistica.
Infine, facciamo notare che il traffico con on-ramp verso Cloudflare One e in uscita sull'Internet pubblico beneficia anch'esso della protezione post-quantistica di Cloudflare Gateway, il nostro Secure Web Gateway (SWG). Ecco un diagramma che mostra come funziona SWG:
Come discusso in un precedente post del blog, il nostro SWG può già supportare l'ML-KEM ibrido sul traffico da SWG al server di origine (purché l'origine supporti l'ML-KEM ibrido) e sul traffico dal client al SWG (se il client supporta l'ML-KEM ibrido, come nel caso della maggior parte dei browser moderni). È importante sottolineare che tutto il traffico che si collega all'SWG tramite un dispositivo su cui è installato Cloudflare One Client è comunque protetto con l'ML-KEM ibrido: anche se il browser web stesso non supporta ancora la crittografia post-quantistica. Ciò è dovuto al tunnel MASQUE post-quantistico che Cloudflare One Client stabilisce sulla rete globale di Cloudflare. Lo stesso vale per il traffico che si collega all'SWG tramite un tunnel IPsec Cloudflare post-quantistico.
Combinando tutto questo, Cloudflare One ora offre crittografia post-quantistica sui nostri TLS, MASQUE e on-ramp e off-ramp IPsec, e per il traffico di rete privato e al traffico che esce all'Internet pubblico tramite il nostro SWG.
Il futuro è sicuro da un punto di vista quantistico
Completando l'equazione SASE post-quantistica con Cloudflare IPsec e Cloudflare One Appliance, abbiamo esteso la crittografia post-quantistica a tutti i nostri principali on-ramp e off-ramp. Abbiamo scelto intenzionalmente la strada dell'interoperabilità e della semplicità: l'approccio dell'ML-KEM ibrido sostenuto da IETF e NIST, piuttosto che bloccare i nostri clienti in implementazioni proprietarie, "ciphersuite bloat" o upgrade hardware non necessari.
Questa è la promessa di Cloudflare One: una piattaforma SASE che non solo è più veloce e affidabile delle architetture legacy che sostituisce, ma che fornisce crittografia post-quantistica. Che tu stia proteggendo il browser di un worker remoto o un link a un datacenter multi-gigabit, ora puoi farlo con la sicurezza che i tuoi dati sono protetti da attacchi Harvest-now-decrypt-later e altre minacce future.
Iscriviti qui per ottenere una demo completa delle nostre funzionalità post-quantistiche sulla piattaforma SASE Cloudflare One, oppure registrati qui per entrare nell'elenco per la versione beta chiusa di Cloudflare IPsec. Siamo orgogliosi di guidare il settore in questa nuova era della crittografia e ti invitiamo a unirti a noi nella realizzazione di un Internet scalabile, conforme agli standard e post-quantistico.