Le diverse implementazioni di SSL/TLS: storia, varianti e punti di forza

Quando si parla di sicurezza delle comunicazioni su Internet, i due acronimi che tornano più spesso sono SSL e TLS. Sono diventati così familiari da apparire persino nei browser con l’iconcina del lucchetto accanto all’indirizzo web, simbolo ormai universale di connessione sicura. Ma cosa sono davvero? E soprattutto, quali implementazioni esistono dietro le quinte, a garantire che i nostri dati non possano essere intercettati da occhi indiscreti?

Per capirlo, conviene fare un passo indietro. SSL (Secure Sockets Layer) nacque negli anni ’90 per iniziativa di Netscape, con l’obiettivo di creare un canale cifrato tra client e server, così da proteggere password, numeri di carte di credito e qualsiasi informazione privata scambiata sul web. Le prime versioni di SSL erano pionieristiche ma non prive di falle, tanto che a partire dalla fine degli anni ’90 si decise di proseguire con uno standard più robusto, chiamato TLS (Transport Layer Security). TLS può essere considerato il successore naturale di SSL, tanto che oggi, quando diciamo “SSL”, ci riferiamo quasi sempre a TLS, anche se i protocolli SSL originali sono da tempo considerati insicuri e deprecati.

TLS si basa su un insieme di primitive crittografiche: algoritmi di cifratura, funzioni di hash, curve ellittiche o RSA per lo scambio di chiavi, e protocolli di handshake per negoziare una sessione sicura. È uno strato che si pone sopra TCP e sotto le applicazioni: non importa se si tratti di HTTPS, IMAPS o SMTP con STARTTLS, tutto funziona secondo lo stesso principio, cioè stabilire un canale cifrato e autenticato tra due estremi della comunicazione.

Fin qui la teoria. Ma come avviene in pratica? Chi implementa tutto questo? Ecco che entrano in gioco le librerie software che concretizzano TLS, ovvero i motori crittografici usati da server web, sistemi operativi, browser e dispositivi embedded. Il panorama è molto vario e riflette esigenze diverse: performance, portabilità, sicurezza, semplicità d’uso, compatibilità con regolamenti locali. Alcune librerie sono nate come fork di progetti esistenti, altre come alternative radicali, altre ancora come risposte a vulnerabilità clamorose che hanno scosso la fiducia negli standard.

In questo articolo approfondiremo le implementazioni più importanti: OpenSSL, la madre di tutte, e i suoi fork più celebri come LibreSSL, BoringSSL e BabaSSL. Vedremo poi soluzioni nate indipendenti come WolfSSL, pensata per l’IoT, GnuTLS, espressione del mondo GNU, e NSS, la storica libreria di Mozilla. Ognuna di queste ha una storia, un contesto di utilizzo e dei punti di forza che l’hanno resa adatta a determinati scenari.

Come funziona a livello teorico SSL a grandi linee?

Immagina di dover parlare con un amico dall’altra parte di una stanza piena di persone curiose. Non vuoi che gli altri capiscano quello che dici, quindi ti serve un sistema per codificare i messaggi. Non puoi però semplicemente dirgli ad alta voce la “parola segreta”, perché qualcuno potrebbe sentirla e usarla contro di voi. Allora escogiti un metodo: scambiate prima alcune frasi in codice che vi permettono di arrivare entrambi, senza che gli altri se ne accorgano, a una chiave comune conosciuta solo da voi due. Una volta trovata questa chiave, da quel momento potete parlare liberamente: chiunque vi ascolti sentirà soltanto un insieme di suoni incomprensibili.

Questo è esattamente quello che fa SSL/TLS: stabilisce un canale sicuro tra due soggetti (tipicamente un browser e un server web) attraverso un processo iniziale di negoziazione chiamato handshake, e poi protegge lo scambio di dati con cifratura e verifiche di integrità.

L’handshake TLS spiegato passo per passo

Dietro le quinte, il protocollo segue una sequenza ben definita. Possiamo riassumerla in grandi fasi:

1. ClientHello: il client (es. il browser) invia un messaggio al server con l’elenco delle versioni di TLS che supporta, le suite crittografiche disponibili (insiemi di algoritmi), e un numero casuale (nonce) che servirà nella generazione delle chiavi.

2. ServerHello: il server risponde scegliendo una versione di TLS e una suite crittografica compatibili con quelle proposte dal client. Invia a sua volta un nonce e, soprattutto, il certificato digitale X.509 che prova la sua identità.

3. Verifica del certificato: il client controlla che il certificato sia valido, firmato da una Certification Authority riconosciuta e non revocato. È il passo che ci dice: “Sì, sto davvero parlando con example.com e non con un impostore”.

4. Scambio delle chiavi: qui entra in gioco la crittografia asimmetrica. Con RSA, ECDHE o altri algoritmi, client e server collaborano per generare una chiave di sessione simmetrica. La cosa importante è che questa chiave non viene mai trasmessa in chiaro: viene derivata da calcoli matematici basati sui nonce scambiati e su parametri crittografici.

5. Conferma: una volta derivata la chiave, client e server si mandano messaggi cifrati per dimostrare di avere la stessa chiave.

6. Sessione sicura: da qui in avanti, tutti i dati viaggiano cifrati con algoritmi simmetrici (per esempio AES o ChaCha20), molto più veloci da calcolare.

I pilastri teorici: riservatezza, integrità, autenticità

SSL/TLS non è solo un protocollo di cifratura, ma un insieme di garanzie.

• Riservatezza: grazie alla crittografia simmetrica, solo le due parti in comunicazione possono leggere i dati.

• Integrità: ogni messaggio è accompagnato da un codice (MAC o HMAC, a seconda della versione) che permette di rilevare se è stato modificato.

• Autenticità: i certificati digitali permettono di essere ragionevolmente sicuri dell’identità del server (e talvolta del client).

Dal semplice al tecnico: simmetrica e asimmetrica

Uno degli aspetti chiave è la combinazione di crittografia asimmetrica e simmetrica.

• La crittografia asimmetrica (RSA, Diffie-Hellman, curve ellittiche) viene usata all’inizio, perché permette a due soggetti di stabilire una chiave comune senza doverla trasmettere in chiaro. È molto sicura, ma anche lenta.

• Una volta stabilita la chiave di sessione, subentra la crittografia simmetrica, dove entrambi usano la stessa chiave per cifrare e decifrare i dati. È molto più veloce, quindi perfetta per gestire grandi quantità di traffico.

Questo equilibrio tra le due tipologie di crittografia è ciò che rende TLS sia sicuro che efficiente.

Le versioni e l’evoluzione di TLS

Nel corso del tempo, il protocollo ha subito vari aggiornamenti. SSL 2.0 e SSL 3.0 oggi sono considerati insicuri. Le versioni di TLS hanno progressivamente migliorato la sicurezza:

• TLS 1.0 e 1.1 sono ormai deprecati.

• TLS 1.2 è ancora molto diffuso, stabile e considerato sicuro.

• TLS 1.3, la versione più recente, ha semplificato molto l’handshake, eliminato algoritmi deboli e migliorato la velocità. Ora l’instaurazione di una sessione sicura richiede meno scambi di messaggi, riducendo la latenza.

Una visione d’insieme

In conclusione, a livello teorico SSL/TLS è come un rito di presentazione e accordo tra due interlocutori: prima ci si riconosce, poi si decide insieme come comunicare, quindi si procede a scambiarsi messaggi al sicuro dagli sguardi esterni. Nel concreto, questo avviene grazie a sofisticati meccanismi di crittografia, certificati digitali e codici di integrità, che lavorano in modo trasparente per l’utente.

La magia del protocollo è proprio questa: dietro un semplice lucchetto verde nel browser c’è un sistema complesso, fatto di matematica e standard condivisi, che permette ogni giorno a miliardi di persone di navigare, fare acquisti, scambiarsi messaggi e lavorare in rete con un livello di sicurezza che, fino a qualche decennio fa, sarebbe stato impensabile.

OpenSSL: la pietra angolare della crittografia open source

Non si può parlare di SSL/TLS senza citare OpenSSL, la libreria più diffusa e longeva. Nata alla fine degli anni ’90 come evoluzione di SSLeay, è diventata lo standard de facto per tutto il mondo open source e non solo. Apache HTTP Server, Nginx, Postfix, MySQL, praticamente ogni software che richieda comunicazioni cifrate si appoggia o si è appoggiato a OpenSSL.

Il suo punto di forza principale è sempre stata la completezza. OpenSSL fornisce non solo l’implementazione del protocollo TLS, ma anche un’enorme collezione di primitive crittografiche: RSA, DSA, DH, curve ellittiche, AES, ChaCha20, SHA, HMAC, cifrari legacy e molto altro. È una sorta di coltellino svizzero che va ben oltre TLS e che si usa per generare certificati X.509, gestire PKI, verificare firme digitali, costruire VPN o sistemi di cifratura dei file.

La sua diffusione è dovuta anche alla licenza Apache-style, che ne ha favorito l’integrazione sia in software libero che in soluzioni proprietarie. Tuttavia, questa stessa ubiquità ha reso dolorosamente evidente quanto fosse critico il suo ruolo quando nel 2014 esplose la vulnerabilità Heartbleed, una falla nell’implementazione dell’estensione TLS heartbeat che permetteva di leggere la memoria dei server. Heartbleed scosse il mondo IT, rivelando che un’infrastruttura così cruciale era mantenuta da pochissimi sviluppatori, con fondi limitati e codice non sempre facile da mantenere.

Da allora il progetto ha vissuto una fase di rinnovamento, con più finanziamenti, audit di sicurezza e rilasci più regolari. Oggi OpenSSL è ancora la libreria di riferimento per compatibilità e supporto, ma quella crisi aprì la strada a vari fork che cercavano di offrire alternative più sicure o più leggere.

LibreSSL: la risposta di OpenBSD dopo Heartbleed

Proprio come reazione a Heartbleed nacque LibreSSL, un fork portato avanti dal team di OpenBSD. La filosofia dietro questo progetto è stata molto chiara: fare pulizia. OpenSSL era cresciuto in maniera caotica, con molto codice legacy, API considerate insicure e compatibilità mantenute per sistemi ormai obsoleti. Gli sviluppatori di OpenBSD decisero quindi di eliminare funzioni non più necessarie, semplificare le API e concentrarsi su sicurezza e leggibilità.

LibreSSL si distingue dunque per la sua attenzione al rigore del codice. L’approccio di OpenBSD è sempre stato noto per la sua cultura di “secure by default”, ed è lo stesso spirito che anima questa libreria. Non a caso, in molti punti il codice è stato riscritto, portato a standard moderni di C e ripulito da funzioni pericolose come quelle che non controllano correttamente i buffer.

Il limite principale di LibreSSL è la compatibilità. Essendo più minimalista, non sempre riesce a stare al passo con tutte le API richieste da software che si aspettano l’universo di funzioni di OpenSSL. Questo ne ha frenato la diffusione al di fuori del mondo *BSD e di alcune distribuzioni Linux. Rimane però un riferimento per chi vuole un’implementazione sobria e focalizzata sulla sicurezza del codice, più che sulla compatibilità assoluta.

BoringSSL: l’implementazione di Google per Chrome e Android

Un altro fork nato da esigenze precise è BoringSSL, mantenuto da Google. In questo caso il problema non era tanto Heartbleed quanto la necessità di avere un codice SSL/TLS su misura per le enormi piattaforme di Google, come Chrome, Android, gRPC e i servizi cloud.

BoringSSL non ha mai avuto l’ambizione di diventare una libreria universale come OpenSSL. Al contrario, Google lo ha sempre presentato come un progetto interno, ottimizzato per le proprie necessità e non raccomandato per uso generico. L’obiettivo era ridurre la complessità, eliminare funzioni legacy e avere un ciclo di sviluppo più rapido, in linea con il ritmo delle patch di sicurezza necessarie a proteggere miliardi di utenti.

I suoi punti di forza sono quindi la velocità di sviluppo, l’attenzione alla sicurezza memory-safe (anche se resta scritto in C, sono state introdotte molte mitigazioni) e l’integrazione con l’ecosistema Google. Da BoringSSL derivano anche librerie secondarie come AWS-LC, il fork mantenuto da Amazon Web Services.

La sua limitazione principale, anche in questo caso, è la compatibilità. BoringSSL non espone tutte le API di OpenSSL e non è pensato per sostituirlo in maniera trasparente. Per questo non è mai diventato una scelta standard per terzi, ma ha avuto un’enorme influenza nel mostrare che librerie più snelle sono possibili e desiderabili in certi contesti.

WolfSSL: la scelta ideale per l’IoT e i sistemi embedded

Se OpenSSL è il gigante generalista, WolfSSL rappresenta la specializzazione. Nata come CyaSSL e poi rinominata, questa libreria si rivolge esplicitamente al mondo dei sistemi embedded e dell’Internet of Things. I microcontrollori, i router, i dispositivi industriali o medicali hanno risorse limitate: memoria ridotta, CPU poco potenti, requisiti di latenza stringenti. In questi scenari, una libreria enorme come OpenSSL è spesso inadeguata.

WolfSSL è scritta in C portabile, con un’attenzione maniacale alla leggerezza. La dimensione binaria è piccola, i moduli sono configurabili in base alle necessità e le ottimizzazioni hardware sono sfruttate per ridurre i consumi. Non a caso supporta un’ampia gamma di architetture e ambienti RTOS.

Un altro punto di forza è la certificazione. WolfSSL è stata validata in vari standard come FIPS 140-2 e DO-178C per applicazioni avioniche, rendendola appetibile per settori dove la compliance è fondamentale. Questo l’ha resa popolare tra produttori di dispositivi embedded che devono garantire non solo sicurezza tecnica ma anche rispetto di normative.

Il suo limite, invece, è che non sempre offre la stessa estensione di algoritmi legacy o API che si trovano in OpenSSL. È pensata per chi cerca efficienza e portabilità, più che per chi deve mantenere la compatibilità universale.

GnuTLS: l’alternativa del mondo GNU

Nel panorama open source non poteva mancare una soluzione a marchio GNU: GnuTLS. Questa libreria è nata con lo scopo di fornire un’implementazione TLS compatibile con le linee guida del progetto GNU e della Free Software Foundation. All’epoca, OpenSSL aveva una licenza considerata non del tutto compatibile con la GPL, e GnuTLS voleva essere la risposta pienamente “libera”.

Il suo punto di forza principale è la integrazione nel mondo GNU/Linux. Molti software che rientrano nella sfera GNU hanno preferito adottare GnuTLS proprio per motivi di licenza e coerenza filosofica. Nel tempo, però, il progetto si è distinto anche per alcune caratteristiche tecniche, come l’adozione tempestiva di protocolli moderni e una forte attenzione alla configurabilità.

GnuTLS, rispetto ad OpenSSL, ha spesso avuto meno diffusione nel mondo enterprise, ma ha un ruolo cruciale nell’ecosistema del software libero. È molto usata da applicazioni che si vogliono distaccare dal colosso OpenSSL e adottare una libreria coerente con i principi GNU. Anche in termini di API, risulta a volte più semplice e diretta, sebbene meno universale.

NSS: la storica libreria di Mozilla

Un’altra implementazione che merita attenzione è NSS (Network Security Services), sviluppata originariamente da Netscape e oggi mantenuta da Mozilla e da Red Hat. È stata per anni il cuore crittografico di Firefox, ma non solo: viene utilizzata anche in soluzioni enterprise, in sistemi di posta e in vari prodotti Red Hat.

NSS si distingue perché non si limita a TLS: include una PKI completa, con gestione di certificati, librerie per S/MIME, strumenti per firme digitali e autenticazione. È pensata come uno stack di sicurezza più ampio, con particolare attenzione all’integrazione nei browser e nei sistemi operativi.

La sua forza è quindi la maturità e la solidità. Essendo stata usata in Firefox e in contesti di grande diffusione, ha ricevuto un’enorme attenzione in termini di sicurezza e correzione di bug. Inoltre, il suo supporto esteso alla gestione di certificati la rende adatta in scenari complessi di autenticazione enterprise.

Il rovescio della medaglia è che, fuori dal contesto Mozilla e Red Hat, ha perso terreno rispetto a OpenSSL e ai suoi fork. Rimane comunque un pilastro storico, che ha contribuito a far evolvere lo standard TLS nei browser e che continua a essere mantenuto con cura.

BabaSSL, ora Tongsuo: la variante cinese con algoritmi nazionali

Un’implementazione meno nota in Occidente ma di grande rilevanza in Asia è oggi conosciuta come Tongsuo, evoluzione di quello che in precedenza era chiamato BabaSSL. Si tratta di un fork di OpenSSL sviluppato in Cina con un obiettivo ben preciso: integrare in maniera nativa gli standard crittografici nazionali obbligatori, come SM2, SM3 e SM4. A differenza del resto del mondo, dove la crittografia si affida soprattutto ad AES, RSA o alle curve NIST, in Cina la legge impone l’uso di un set di algoritmi locali, e Tongsuo rappresenta la risposta tecnica a questa esigenza.

Tongsuo è dunque la scelta ideale per chi deve operare nel rispetto delle normative locali, e per questo è adottato in diversi prodotti e servizi cinesi. Oltre a supportare NTLS (National TLS), l’equivalente “nazionale” del protocollo TLS, mantiene comunque compatibilità con i protocolli internazionali, rendendolo idoneo anche a scenari misti in cui occorra comunicare sia con client globali che con client conformi agli standard cinesi.

Il suo principale punto di forza è quindi la compliance normativa. In un mercato vasto come quello cinese, avere una libreria che implementa in modo nativo gli algoritmi nazionali è essenziale per garantire interoperabilità e conformità legale. Allo stesso tempo, questo stesso orientamento ne limita la diffusione al di fuori della Cina: in contesti occidentali, infatti, pochi hanno reale necessità di utilizzare algoritmi come SM2 o NTLS, motivo per cui Tongsuo resta una libreria molto specializzata e di nicchia.

Conclusioni: quale scegliere?

Come abbiamo visto, non esiste una sola implementazione di TLS, ma un intero ecosistema di librerie nate per rispondere a esigenze diverse. OpenSSL resta la più universale, quella che assicura la massima compatibilità. LibreSSL è un simbolo di rigore e pulizia del codice, anche se meno diffuso. BoringSSL dimostra l’approccio pragmatico di Google, focalizzato sui propri servizi. WolfSSL apre le porte dell’IoT e dei sistemi embedded. GnuTLS rimane la bandiera del mondo GNU. NSS continua a garantire sicurezza a browser e soluzioni enterprise. BabaSSL, infine, rappresenta l’adattamento agli standard nazionali cinesi.

Quello che emerge chiaramente è che la crittografia e la sicurezza non sono mai statiche. L’evoluzione delle librerie SSL/TLS riflette tanto la storia di Internet quanto la tensione costante tra compatibilità, performance, compliance e sicurezza. Ogni implementazione racconta una parte di questa storia, e la scelta dipende dal contesto: un data center globale, un dispositivo IoT, un browser, un mercato nazionale.

In definitiva, la ricchezza di alternative è un segno di vitalità: significa che TLS, cuore della sicurezza del web, continua a evolversi e a trovare risposte mirate alle sfide di un mondo digitale sempre più complesso e diversificato.