OpenSSL 4.1: DTLS 1.3 va testato dove la rete fallisce

Il 23 ottobre 2026 è arrivato OpenSSL 4.1.0. Le novità non mancano: DTLS 1.3, GREASE, nuove accelerazioni crittografiche e qualche pezzo di passato finalmente tolto dalle configurazioni di build. È facile trasformare tutto questo nell’ennesimo elenco di funzioni, magari chiudendolo con il solito invito ad aggiornare. Peccato che, quando una libreria gestisce connessioni e sicurezza, la parte interessante cominci proprio dove finisce il changelog.

La nota ufficiale di rilascio contiene anche quattro problemi noti legati a DTLS 1.3. Non sono dettagli da nascondere sotto il tappeto: riguardano ritrasmissioni, gestione degli errori e handshake in condizioni che una rete reale può tranquillamente produrre. Ecco perché questa versione merita attenzione tecnica, non entusiasmo automatico.

DTLS 1.3: il protocollo è moderno, il trasporto resta imperfetto

DTLS serve a proteggere comunicazioni che mantengono la semantica dei datagrammi. A differenza del classico TLS usato sopra un trasporto affidabile, qui bisogna convivere con pacchetti che possono arrivare fuori ordine, duplicati o non arrivare affatto. La RFC 9147 descrive DTLS 1.3 come un adattamento di TLS 1.3 a questa realtà: protezione dei dati, gestione degli ACK, ritrasmissioni e accorgimenti per non confondere l’ordine di arrivo con lo stato della connessione.

OpenSSL 4.1.0 introduce il supporto a DTLS 1.3 e lo integra anche nella SSL listener API. È un avanzamento concreto per chi sviluppa software che usa comunicazioni a datagrammi, non un nuovo pulsante magico da accendere sul server web. L’applicazione deve utilizzare davvero quel percorso di protocollo, e il suo comportamento dipende anche da come gestisce timeout, socket non bloccanti, perdita di pacchetti e stati dell’handshake.

È una distinzione che vale ben oltre OpenSSL: una specifica può definire un comportamento corretto, ma è l’implementazione, insieme al codice che la usa, a decidere se quel comportamento sopravvive alle condizioni operative. Lo stesso errore di prospettiva si incontra quando si parla di HTTP/3 e QPACK senza considerare i limiti reali di memoria. Il protocollo non sostituisce il lavoro di progettazione dei confini e dei casi limite.

I quattro problemi noti sono quattro test che dovresti saper eseguire

La documentazione di OpenSSL 4.1.0 segnala quattro issue specifiche. Non equivalgono a quattro vulnerabilità CVE, né autorizzano a dichiarare insicura qualsiasi applicazione che usi OpenSSL. Indicano invece scenari nei quali la nuova implementazione DTLS 1.3 può comportarsi diversamente da quanto un’applicazione si aspetta.

1. KeyUpdate e ritrasmissioni che spariscono

Nella issue #32878, quando arriva un KeyUpdate, altri record post-handshake ancora in attesa di conferma vengono rimossi dal buffer di ritrasmissione. Se il primo invio si perde, messaggi come NewSessionTicket potrebbero non essere reinviati. Il problema non è soltanto una chiamata API: è il rapporto fra stato crittografico e affidabilità della consegna.

2. Un errore permanente che sembra un’attesa normale

La #33277 descrive un errore permanente di ricezione su un listener DTLS che può essere riportato come SSL_ERROR_WANT_READ. Per un’applicazione che usa polling, la differenza è enorme: un errore irreversibile può sembrare una condizione temporanea. Il risultato potenziale non è un crash spettacolare, ma un processo che continua ad aspettare qualcosa che non arriverà.

3. Un errore temporaneo interpretato come fatale

La #33278 mostra il caso opposto: un fallimento di scrittura recuperabile su una connessione non bloccante accettata dal listener può essere segnalato come SSL_ERROR_SYSCALL anziché SSL_ERROR_WANT_WRITE. Se il chiamante considera il primo valore fatale, può chiudere una connessione ancora utilizzabile. Non basta che il codice controlli il valore di ritorno: deve interpretarlo nel contesto corretto.

4. Handshake interrotto dopo perdita di pacchetti

La #33242 riguarda server DTLS 1.3 che possono interrompere l’handshake con un alert unexpected_message quando il client conferma parte del primo gruppo di messaggi del server prima di inviare la propria risposta. È uno scenario che può verificarsi con perdita di pacchetti o durante la preparazione della risposta di autenticazione. Un test fatto soltanto su localhost, con latenza minima e traffico pulito, rischia di non intercettarlo.

Il punto non è drammatizzare quattro issue note. È chiedersi se l’applicazione abbia test di integrazione che riproducono davvero questi stati. Se non li ha, il numero di versione aggiornato racconta soltanto metà della storia.

La compatibilità non si dimostra quando tutto funziona. Si dimostra quando il trasporto perde dati, le API restituiscono errori ambigui e il software deve comunque prendere una decisione corretta.

GREASE: mettere alla prova l’estensibilità prima che diventi un problema

L’altra novità significativa è il supporto a GREASE, descritto nella RFC 8701. L’idea è semplice e piuttosto intelligente: introdurre intenzionalmente valori riservati, non significativi, in determinati punti di estensione del protocollo TLS. Un peer conforme deve saper ignorare ciò che non riconosce. Se invece si rompe davanti a un valore sconosciuto, il difetto emerge prima che una futura estensione reale venga distribuita su larga scala.

Non è un meccanismo che cifra meglio i dati, né una cura universale per la sicurezza TLS. È un modo per contrastare la rigidità delle implementazioni: sistemi che funzionano soltanto perché tutti gli altri continuano a comportarsi esattamente come ieri. È la stessa ragione per cui testare un protocollo soltanto con gli input che conosci già può produrre una rassicurante, e inutile, sensazione di solidità.

DTLS 1.3 e GREASE affrontano problemi diversi, ma suggeriscono la stessa disciplina: non confondere la compatibilità osservata in un ambiente favorevole con la robustezza dell’intero sistema. In un caso devi saper gestire datagrammi e stati incompleti; nell’altro devi tollerare valori previsti dal meccanismo di estensione anche quando non ne conosci il significato.

Le accelerazioni crittografiche non sono un benchmark della tua applicazione

OpenSSL 4.1.0 introduce ottimizzazioni per operazioni NTT di ML-DSA e ML-KEM su ppc64le, per ML-DSA su x86_64, per SHAKE x4 con AVX-512 nel percorso ML-DSA e per la decifratura AES-CBC con AVX-512 e VAES su x86_64. Sono miglioramenti implementativi documentati, non una promessa di accelerazione identica per qualsiasi server e qualsiasi carico.

Una misura microbenchmark può mostrare un guadagno nella singola primitiva. Il tempo di risposta di un servizio dipende però anche da I/O, handshake, dimensioni dei messaggi, algoritmi effettivamente negoziati, hardware disponibile e quantità di lavoro crittografico rispetto al resto della richiesta. Senza misurare il percorso realmente usato, affermare che l’aggiornamento renderà più veloce il servizio sarebbe un salto logico, non un risultato tecnico.

Nel changelog ci sono anche dettagli meno vistosi: vengono rimossi i target Windows-on-Itanium e Windows CE, spariscono le opzioni no-ecdsa e no-ecdh perché non disabilitavano davvero le implementazioni, e l’utility tsget passa a Net::Curl::Easy. Per chi mantiene build personalizzate o automazioni legacy, questi dettagli possono contare più di un grafico con una barra più lunga.

Come valutare l’upgrade senza affidarsi alla fortuna

La decisione sensata non è “aggiornare sempre” o “non aggiornare mai”. È capire quale superficie dell’applicazione stai cambiando. Per un servizio che non usa DTLS 1.3, i problemi noti del nuovo percorso non hanno lo stesso peso operativo che avrebbero per un’applicazione costruita attorno a datagrammi e listener non bloccanti. Anche questo è risk assessment, non prudenza generica.

• Mappa le dipendenze: identifica quale versione OpenSSL usa davvero il processo in esecuzione, non soltanto quella installata sul sistema. Il principio è simile a quello discusso a proposito di patch installate e runtime effettivamente attivo.
• Verifica il percorso interessato: TLS e DTLS non sono intercambiabili; controlla se la tua applicazione usa DTLS 1.3, listener API, socket non bloccanti e funzioni toccate dal rilascio.
• Simula una rete imperfetta: perdita, riordino e duplicazione dei datagrammi, timeout, ritrasmissioni, KeyUpdate e handshake con risposte ritardate. Verifica che gli errori temporanei e permanenti non vengano confusi.
• Controlla build e compatibilità: opzioni rimosse, target non più supportati e dipendenze degli strumenti ausiliari prima di distribuire l’aggiornamento.
• Misura e conserva un rollback: raccogli metriche di successo degli handshake, errori e latenza sul tuo hardware; distribuisci gradualmente dove possibile e prepara una procedura di ritorno alla versione precedente.

La copertura tecnica di Phoronix mette giustamente in evidenza le nuove ottimizzazioni AVX-512. Ma il criterio per mettere in produzione una libreria crittografica non può fermarsi alla velocità di un algoritmo: deve includere i casi in cui il sistema comunica male, riceve errori inattesi o perde pezzi del proprio stato.

La release è stabile. La tua integrazione deve ancora dimostrarlo.

OpenSSL 4.1.0 è una feature release reale, con novità importanti. Non è corretto presentarla come una semplice patch di sicurezza, né come una release da evitare a prescindere per la presenza di problemi noti. Il valore del changelog sta anche nella trasparenza con cui permette a chi sviluppa di capire dove cercare i rischi.

Se c’è una lezione da portarsi a casa, è questa: le nuove capacità di protocollo hanno senso quando esistono test che dimostrano il loro comportamento sotto stress. DTLS 1.3 porta avanti lo standard; GREASE ricorda perché l’estensibilità va esercitata; le ottimizzazioni hardware possono migliorare alcuni percorsi. Ma nessuna di queste tre cose sostituisce la responsabilità di capire che cosa accade quando il mondo reale smette di collaborare.