Oltre il gonfiore post-quantistico: strategie di ingegneria per contenere gli handshake TLS

Nel mio post precedente abbiamo visto come lo scambio di chiavi post-quantistico influisce sulle prestazioni. La risposta breve? L’utilizzo della CPU cambia poco, ma la dimensione dell’handshake TLS aumenta in modo significativo. Passare dal classico X25519 all’ibrido X25519MLKEM768 aggiunge circa 1,2 KB all’handshake TLS nella direzione critica. Quando inevitabilmente aggiungeremo anche le firme post-quantistiche (come ML-DSA), le catene di certificati supereranno facilmente la finestra di congestione iniziale di TCP (14,5 KB), imponendo round trip aggiuntivi (RTT) e introducendo una latenza di rete reale.

La Web PKI si sta già orientando verso i Merkle Tree Certificates (MTC), progettati principalmente per risolvere proprio questo problema delle firme post-quantistiche molto lunghe. Tuttavia, non tutti i sistemi potranno usare gli MTC, quindi in questo post ho voluto esplorare cos’altro possiamo fare. E in realtà le possibilità sono parecchie.

Abbiamo due leve ingegneristiche principali: una è ridurre la dimensione fisica dell’handshake TLS, l’altra è ridurre la frequenza con cui avviene un handshake completo.

Ecco uno sguardo pratico a come ottimizzare entrambe, e a che punto è il settore nella standardizzazione di queste soluzioni. La parte migliore è che potrai beneficiare di queste ottimizzazioni già oggi, anche con la crittografia tradizionale (RSA e/o curve ellittiche).

Per quanto riguarda l’handshake TLS, abbiamo diverse opzioni:

• Rimuovere i certificati radice dalle catene: Uno degli errori di configurazione più comuni è trasmettere il certificato della CA radice insieme ai certificati intermedi. I client conservano già le radici di fiducia localmente; inviarle in rete non ha alcuna utilità e spreca banda preziosa.
• Adottare la compressione dei certificati (RFC 8879): La RFC 8879 consente agli endpoint di negoziare algoritmi di compressione standard (Brotli, zlib o zstd) per i dati dei certificati. In pratica, comprime le catene di certificati più voluminose dal 30% al 50%. Sebbene il supporto nei browser moderni sia frammentato (Chrome supporta Brotli; Firefox supporta Brotli, zlib e zstd; Safari supporta zlib), OpenSSL li supporta tutti e tre, quindi questa tecnica dovrebbe portare qualche risparmio. Purtroppo la compressione funziona solo sul testo contenuto nei certificati. Per come sono progettate, firme e chiavi pubbliche si comprimono male.
• Modernizzare le chiavi pubbliche (ECC invece di RSA): Se non hai ancora abbandonato i vecchi certificati RSA, fallo. Passare da RSA-2048 a ECDSA riduce immediatamente la dimensione di chiavi pubbliche e firme, producendo certificati più leggeri ancora prima dell’arrivo della PQC.
• Raw Public Keys (RFC 7250): Per la comunicazione machine-to-machine, le API o gli ambienti con risorse limitate in cui gli endpoint si fidano già della chiave pubblica del server o la memorizzano tramite un canale separato, la RFC 7250 consente di evitare del tutto la trasmissione delle CA intermedie e degli involucri dei certificati.

L’IETF ha esplorato diversi altri meccanismi di compressione e riduzione, anche se l’adozione varia enormemente:

• TLS Cached Info (RFC 7924): Pensato per consentire ai client di segnalare i certificati in cache ed evitarne la ritrasmissione. Questa RFC è stata pubblicata a maggio 2026, ma non è ancora ampiamente supportata da librerie e user agent. Forse il supporto migliorerà quando inizieremo a migrare alla crittografia post-quantistica.
• Abridged Compression for WebPKI Certificates (draft-ietf-tls-cert-abridge): Usa dizionari statici pre-distribuiti per comprimere le strutture dei certificati. Sebbene sia stato adottato dal TLS Working Group, da allora è scaduto e sembra abbandonato.

In TLS esistono due tipi di handshake: completi e abbreviati (ripresi). Questi ultimi non trasportano alcun certificato, il che rappresenta un risparmio significativo:

• Ripresa della sessione: La ripresa della sessione consente ai client che ritornano di autenticarsi tramite una chiave simmetrica pre-condivisa, saltando completamente l’oneroso scambio di chiavi asimmetrico e il trasferimento dei certificati.
• TLS 1.3 0-RTT (Early Data): Per i visitatori abituali, 0-RTT consente ai dati applicativi di viaggiare già nel primissimo invio di pacchetti insieme all’handshake di ripresa, eliminando del tutto i ritardi di round trip dell’handshake. Questa tecnica non offre una forward secrecy completa e va usata solo quando il primo invio dello user agent non contiene informazioni sensibili.

L’handshake più veloce è quello che non devi mai fare. Eliminare gli scambi asimmetrici evita la crescente penalità di dimensione delle chiavi post-quantistiche.

• Ottimizzare i keep-alive: Non lasciare che le connessioni TCP o TLS inattive si chiudano prematuramente. Estendere i timeout di keep-alive a livello applicativo e TCP sui proxy edge (ad es. NGINX, HAProxy, Envoy) mantiene i socket attivi per il traffico client a raffica o sequenziale.
• Adottare HTTP/2 e HTTP/3 (QUIC): Grazie al multiplexing di più richieste HTTP su un’unica connessione sottostante, i protocolli moderni eliminano la dispendiosa abitudine di aprire sessioni TLS parallele per risorse che risiedono sulla stessa origine.

Quando si ottimizzano le prestazioni TLS, la discussione si concentra quasi sempre sul traffico in ingresso (frontend), cioè su come i client si connettono ai tuoi server edge. Ma per le moderne architetture a microservizi, le reti aziendali e le applicazioni cloud-native, il traffico in uscita (egress) rappresenta un’enorme penalità di latenza nascosta.

Ogni volta che un servizio interno avvia una chiamata API in uscita, recupera una dipendenza di terze parti o comunica tra cluster in più regioni, innesca un nuovo handshake TLS.

Quando si aggiunge l’overhead post-quantistico a queste mesh di microservizi interne, la latenza accumulata cresce rapidamente. Per mitigare il problema sul lato egress:

• Adottare forward proxy con connection pooling: Collocare un forward proxy in uscita (o un sidecar di service mesh come Envoy) tra i microservizi interni e gli endpoint esterni consente di consolidare e raggruppare le connessioni. Invece di far avviare a ogni thread applicativo effimero il proprio handshake TLS post-quantistico verso un endpoint esterno, il forward proxy mantiene un pool di connessioni TLS persistenti e di lunga durata.
• Keep-alive e ripresa della sessione in uscita: Come per i proxy frontend, una configurazione spinta della ripresa della sessione e dei keep-alive sull’infrastruttura proxy in uscita garantisce che le applicazioni interne beneficino di connessioni già attive e a bassa latenza.

Ottimizzando sia la distribuzione frontend sia l’infrastruttura egress, proteggi i tuoi utenti finali e la tua architettura interna dall’inevitabile inflazione di byte della crittografia post-quantistica.