Un sito web è pronto per il post-quantistico, per la parte che oggi conta di più, quando il suo server è in grado di concordare le chiavi di sessione tramite uno scambio di chiavi ibrido post-quantistico. L'opzione più diffusa è X25519MLKEM768, che combina il classico X25519 con ML-KEM-768, il meccanismo di incapsulamento delle chiavi standardizzato dal NIST nel FIPS 203. È registrato dalla IANA come gruppo TLS 0x11EC ed è l'unico gruppo post-quantistico che la IANA indica come raccomandato.
Perché partire dallo scambio di chiavi? A causa degli attacchi harvest now, decrypt later (raccogli ora, decifra dopo): un attaccante può registrare oggi il traffico cifrato e decifrarlo quando esisterà un computer quantistico di grandi dimensioni. Solo lo scambio di chiavi protegge il traffico registrato. Anche certificati e firme contano, ma una firma deve essere contraffatta in tempo reale, quindi la loro migrazione può avvenire in un secondo momento.
Metodo 1: una scansione online
Il modo più rapido è inserire il dominio nello scanner PQC Status. Propone al server ogni gruppo post-quantistico standardizzato, uno alla volta, e indica quali vengono accettati, quale gruppo ottiene effettivamente un browser moderno, le versioni TLS e le suite di cifratura, oltre alla catena di certificati. Richiede pochi secondi e nessun accesso al server.
Metodo 2: un comando OpenSSL
Con OpenSSL 3.5 o successivo (verificalo con openssl version), proponi solo il gruppo ibrido. Se il server lo supporta, l'handshake riesce; altrimenti fallisce:
openssl s_client -connect example.com:443 -servername example.com \
-groups X25519MLKEM768 -brief </dev/nullUn server pronto per il post-quantistico risponde con una riga come questa:
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768Un server che supporta solo gruppi classici termina l'handshake con un alert, tipicamente ssl/tls alert handshake failure (alert numero 40). Nota che s_client termina con stato 0 in entrambi i casi: leggi l'output, non il codice di uscita.
Per testare gli altri gruppi ibridi, sostituisci il nome del gruppo con SecP256r1MLKEM768 o SecP384r1MLKEM1024. Quest'ultimo è l'opzione di livello 5 che l'ANSSI preferisce ove possibile.
Metodo 3: il browser
Le versioni attuali di Chrome, Edge e Firefox propongono X25519MLKEM768 per impostazione predefinita. Nei browser basati su Chromium, apri gli strumenti per sviluppatori, vai al pannello Security e guarda i dettagli della connessione: la riga dello scambio di chiavi indica il gruppo negoziato. Mostra ciò che ha ottenuto il tuo browser, utile per un controllo rapido ma dipendente dalla versione del browser.
Interpretare correttamente il risultato
Una CDN può nascondere l'origine
Se il tuo sito è dietro Cloudflare, Fastly, CloudFront o un'altra CDN, ogni test esterno vede l'edge, non il tuo server. Molte CDN abilitano per impostazione predefinita lo scambio di chiavi ibrido sull'edge, quindi il sito sembra pronto. La connessione dalla CDN al tuo server di origine è un collegamento TLS distinto che potrebbe usare ancora solo lo scambio di chiavi classico. Testa direttamente l'origine, da una macchina autorizzata a raggiungerla, con il comando OpenSSL indicato sopra.
TLS 1.3 è un prerequisito
Lo scambio di chiavi ibrido esiste solo in TLS 1.3. Un server limitato a TLS 1.2 non può essere pronto per il post-quantistico, qualunque sia il suo certificato. Anche il memorandum OMB M-26-15 degli Stati Uniti richiede TLS 1.3 per i sistemi federali entro gennaio 2030.
Oggi i certificati classici sono normali
Il tuo certificato usa quasi certamente RSA o ECDSA. È previsto: le autorità di certificazione pubbliche non rilasciano ancora certificati post-quantistici per il web. Registra l'algoritmo del certificato nel tuo inventario, ma non considerarlo un ostacolo per la fase dello scambio di chiavi.
Le vecchie bozze di Kyber non contano
Alcune prime implementazioni usavano X25519Kyber768Draft00, una versione pre-standard dell'algoritmo. È obsoleta: i server dovrebbero passare ai gruppi ML-KEM standardizzati.
Cosa fare se la risposta è no
- Verifica la libreria TLS: OpenSSL 3.5 o successivo, o una libreria equivalente con supporto a ML-KEM.
- Abilita il gruppo ibrido nel tuo web server o load balancer, mantenendo X25519 come fallback. La nostra guida per abilitare ML-KEM su nginx, Apache, HAProxy e Caddy riporta le direttive esatte.
- Ripeti il test, poi aggiungi il risultato con la data al tuo inventario crittografico.