OpenSSL rappresenta da oltre due decenni una delle librerie crittografiche più diffuse al mondo, integrata in server Web, sistemi operativi e applicazioni aziendali. L’evoluzione del progetto non segue soltanto esigenze in termini di funzionalità, ma riflette anche cambiamenti profondi nella gestione della sicurezza e nella governance del codice. Il rilascio di OpenSSL 4.0 segna una discontinuità netta rispetto alla linea 3.x: non si tratta di un semplice aggiornamento incrementale, ma di una revisione piuttosto ampia che introduce nuove astrazioni, ridefinisce alcune API storiche e affronta limiti emersi negli anni, soprattutto in termini di modularità e manutenzione.
Guardando indietro, la serie 1.1.x aveva già eliminato l’accesso diretto a molte strutture dati; con la versione 3.0 di OpenSSL fu introdotto il concetto di provider, moduli software che implementano in modo separato gli algoritmi crittografici (come cifratura, hashing e firme digitali), permettendo una gestione più flessibile e modulare delle funzionalità di sicurezza.
Con OpenSSL 4.0 il codice presenta un’attenzione ancora più evidente sul tema della separazione tra interfacce pubbliche e implementazioni interne. La pressione normativa e le esigenze di certificazione impongono accortezze ancora maggiori.
Cos’è OpenSSL e come funziona
OpenSSL è una libreria software open source ampiamente utilizzata per implementare protocolli di sicurezza come SSL e TLS, fondamentali per proteggere le comunicazioni su Internet tramite crittografia.
È integrata in una quantità enorme di applicazioni e servizi – server Web come Apache HTTP Server, Nginx e IIS, sistemi di posta, VPN, database e strumenti di rete – al punto che si stima sia presente, direttamente o indirettamente, in milioni di sistemi e dispositivi.
È inoltre nativamente inclusa nella maggior parte delle distribuzioni Linux e in macOS (anche se Apple utilizza proprie librerie come Secure Transport), mentre su Windows non è parte integrante del sistema ma è spesso installata o incorporata da applicazioni di terze parti.
Per verificare se un software utilizza OpenSSL si possono analizzare le dipendenze del programma (ad esempio con strumenti come ldd su Linux o controllando le librerie caricate), oppure interrogare direttamente il binario con comandi come openssl version, se disponibile.
Quanto al passaggio alla versione 4.0, non è automaticamente indispensabile procedere in tal senso. Per uno sviluppatore, l’aggiornamento diventa necessario soprattutto quando introduce miglioramenti di sicurezza rilevanti o quando le versioni precedenti non ricevono più aggiornamenti, mentre in contesti stabili può essere valutato con attenzione per evitare problemi di compatibilità con le applicazioni esistenti.
Basti ricordare che nel corso degli anni OpenSSL è stato anche al centro di vulnerabilità su larga scala, tra cui la nota Heartbleed, che ha esposto dati sensibili da milioni di server dimostrando quanto una singola libreria possa avere un impatto globale sulla sicurezza. Abbiamo infatti inserito Heartbleed tra le 8 vulnerabilità di sicurezza più pericolose in assoluto.
Architettura rivista e modello a provider
Il nocciolo della nuova versione di OpenSSL resta il modello a provider, già introdotto con la release 3.0 e ora ulteriormente consolidato. Gli algoritmi crittografici non risiedono più direttamente nel core della libreria: sono esposti tramite moduli caricabili dinamicamente.
Non solo. La selezione degli algoritmi avviene tramite proprietà e query string, piuttosto che tramite chiamate dirette a funzioni specifiche. Da un lato, questa impostazione introduce maggiore flessibilità, dall’altro – soprattutto negli ambienti più complessi – una policy mal definita può portare all’uso involontario di algoritmi ormai accantonati o non conformi.
Una delle decisioni più impattanti riguarda la rimozione progressiva delle API storiche. Molte funzioni considerate legacy sono definitivamente eliminate o marcate come non supportate. Chi oggi mantiene ancora codice sviluppato su OpenSSL 1.1.x o precedenti dovrà intervenire in modo significativo: non si tratta di semplici modifiche perché con la nuova major release cambia proprio il modello con cui si accede alla crittografia.
Un aspetto meno visibile in superficie ma assolutamente fondamentale riguarda l’isolamento dei componenti crittografici. La nuova struttura consente di caricare provider separati, anche firmati e verificati, riducendo la superficie di attacco. Il concetto si avvicina a quello di un plugin sicuro: il core definisce le interfacce, mentre l’implementazione può essere validata indipendentemente.
Nuovi meccanismi di configurazione
OpenSSL 4.0 introduce un sistema di configurazione più flessibile, basato su file e proprietà a runtime. Il file openssl.cnf assume un ruolo centrale: definisce quali provider caricare, con quali priorità e sotto quali condizioni.
Un amministratore può decidere di abilitare solo determinati algoritmi, disabilitarne altri o imporre vincoli specifici: il risultato è un controllo molto più granulare che però richiede una maggiore attenzione.
Con OpenSSL 4.0 risulta sempre più importante documentare e versionare le configurazioni: non basta aggiornare la libreria; serve una gestione rigorosa delle policy crittografiche.
Utilizzare OpenSSL da terminale: operazioni pratiche per cifratura, certificati e diagnostica TLS
Dalla finestra del terminale, OpenSSL può essere utilizzato direttamente da amministratori e utenti per una vasta gamma di operazioni legate alla sicurezza: dalla generazione di chiavi crittografiche alla creazione di certificati digitali, fino al debug delle connessioni TLS. Si tratta di uno strumento estremamente potente perché consente di interagire “a basso livello” con i meccanismi di cifratura normalmente gestiti in modo trasparente da software come Apache HTTP Server o Nginx.
Generazione di chiavi private e richieste CSR
Un caso molto comune è la generazione di una chiave privata e di una richiesta di certificato (CSR, Certificate Signing Request), utile per ottenere un certificato SSL/TLS da un’Autorità di certificazione:
openssl genpkey -algorithm RSA -out chiave_privata.pem -pkeyopt rsa_keygen_bits:2048
openssl req -new -key chiave_privata.pem -out richiesta.csr
Nel primo comando si crea una chiave privata RSA a 2048 bit, mentre nel secondo si genera una CSR, ovvero una richiesta formale che contiene le informazioni del nome di dominio e dell’organizzazione da certificare.
Verifica di certificati esistenti e connessioni TLS
OpenSSL può anche essere usato per ispezionare un certificato già esistente, ad esempio per verificarne la validità e i dettagli tecnici:
openssl x509 -in certificato.pem -text -noout
Un altro utilizzo molto pratico è il test delle connessioni TLS verso un server remoto, utile per la risoluzione di eventuali problemi:
openssl s_client -connect esempio.com:443
Cifratura di file e hashing
OpenSSL può essere impiegato anche per operazioni di cifratura diretta di file, ad esempio per proteggere dati personali o riservati:
openssl enc -aes-256-cbc -salt -in file.txt -out file.enc
Qui il file è cifrato con l’algoritmo AES a 256 bit in modalità CBC; OpenSSL richiede una password da usare usata per derivare la chiave di cifratura. Per decifrare:
openssl enc -d -aes-256-cbc -in file.enc -out file_decifrato.txt
Infine, è possibile calcolare hash crittografici, utili per verificare l’integrità dei file:
openssl dgst -sha256 file.txt
Questo produce un digest SHA-256, spesso utilizzato per confrontare file e rilevare modifiche non autorizzate.
Gli esempi che abbiamo presentato mostrano come OpenSSL non sia solo una libreria “invisibile”, ma anche uno strumento operativo completo, fondamentale per attività quotidiane di sicurezza, diagnostica e gestione delle infrastrutture crittografiche.
Osservazioni critiche e limiti
OpenSSL 4.0 non è un aggiornamento da applicare alla leggera. Richiede pianificazione, test approfonditi e una revisione del modo in cui si gestisce la crittografia nelle applicazioni. Il modello a provider offre vantaggi reali in termini di sicurezza e flessibilità; allo stesso tempo introduce complessità che non si possono ignorare.
Non tutto, infatti, convince completamente. L’introduzione di astrazioni più articolate migliora la modularità, ma rende la libreria meno immediata. Chi lavora con OpenSSL da anni potrebbe percepire una perdita di controllo diretto.