La storia completa delle versioni di SSL e TLS: Dal 1994 a oggi

Per oltre tre decenni, i protocolli SSL e TLS hanno protetto miliardi di transazioni online. Quello che è iniziato come un ambizioso progetto di sicurezza di Netscape nel 1994 si è evoluto nei sofisticati standard di crittografia di oggi. La storia dell’SSL comprende sei versioni principali del protocollo, innumerevoli miglioramenti della sicurezza e un cambiamento fondamentale nel modo di concepire la sicurezza del web.

Capire le versioni di SSL/TLS non significa solo sapere quali protocolli sono deprecati. Si tratta di capire come ogni vulnerabilità, attacco e innovazione abbia dato forma al panorama attuale in cui TLS 1.3 protegge il 95% del traffico web crittografato.

---

Indice dei contenuti

1. La nascita del protocollo SSL di Netscape
2. SSL 3.0 – Una riprogettazione completa del protocollo
3. TLS 1.0 – L’era della standardizzazione IETF
4. TLS 1.1 e TLS 1.2 – Miglioramenti incrementali della sicurezza
5. TLS 1.3 – Lo standard di sicurezza moderno
6. I malintesi più comuni sul versioning SSL/TLS
7. Il ruolo delle autorità di certificazione nell’evoluzione di SSL/TLS
8. Pietre miliari del settore che hanno influenzato l’adozione di HTTPS
9. Le principali vulnerabilità di sicurezza che hanno guidato l’evoluzione dei protocolli
10. Il futuro dei protocolli SSL/TLS

---

---

La nascita del protocollo SSL di Netscape

SSL 1.0 – Il primo tentativo non rilasciato (1994)

Taher Elgamal, scienziato capo di Netscape, ha progettato il Secure Sockets Layer originale nel 1994. Ma l’SSL 1.0 non vide mai la luce. I ricercatori di sicurezza di Netscape scoprirono delle falle critiche prima del rilascio pubblico, vulnerabilità sufficientemente gravi da far saltare l’intera versione.

La lezione era chiara: i protocolli crittografici devono essere sottoposti a una revisione approfondita prima di essere implementati. Questa battuta d’arresto, per quanto frustrante, stabilì un modello di test rigoroso che avrebbe definito il futuro sviluppo di SSL e TLS.

SSL 2.0 – Il primo rilascio pubblico (1995)

Quando è nato l’SSL? La risposta è il febbraio 1995, quando Netscape ha fornito SSL 2.0 in bundle con Navigator 1.1. Questa versione di SSL introdusse concetti fondamentali utilizzati ancora oggi: l’handshake SSL. SSL handshake , i certificati digitaliX.509 e l’autenticazione del server.

Ma SSL 2.0 aveva dei problemi. Si basava su MD5 per l’autenticazione dei messaggi, utilizzava la stessa chiave per la crittografia e l’autenticazione e mancava di protezione per l’handshake stesso. Gli aggressori potevano passare a una crittografia più debole a 40 bit senza che nessuna delle parti se ne accorgesse.

L’IETF ha ufficialmente deprecato SSL 2.0 nel marzo 2011 tramite l’RFC 6176. A quel punto, la maggior parte dei server era già passata ad altro.

---

SSL 3.0 – Una riprogettazione completa del protocollo

Grandi miglioramenti rispetto a SSL 2.0 (1996)

Paul Kocher, Phil Karlton e Alan Freier hanno riscritto completamente il protocollo SSL per la versione 3.0, rilasciata nel novembre 1996. Hanno separato il livello di trasporto dei dati dal livello dei messaggi, hanno aggiunto il supporto per lo scambio di chiavi Diffie-Hellman e le suite di cifratura Fortezza e hanno implementato una corretta codifica a 128 bit.

SSL 3.0 ha introdotto anche la compressione dei record e una negoziazione più flessibile delle suite di cifratura. L’IETF l’ha successivamente documentato nell’RFC 6101, riconoscendone l’importanza storica. Per quasi due decenni, SSL 3.0 è stato un’opzione di ripiego per i sistemi tradizionali.

La vulnerabilità POODLE e la deprecazione di SSL 3.0

Nell’ottobre 2014, il team di sicurezza di Google ha scoperto POODLE (Padding Oracle on Downgraded Legacy Encryption). L’attacco sfruttava il modo in cui SSL 3.0 gestiva il padding in modalità cipher block chaining (CBC). Gli aggressori potevano decriptare i cookie HTTP sicuri costringendo i browser a passare da TLS a SSL 3.0.

L’IETF ha risposto rapidamente, deprecando SSL 3.0 nel giugno 2015 tramite la RFC 7568. Questo ha segnato la fine dell’era SSL. Quando si chiede quale sia l’ultima versione di SSL, la risposta è SSL 3.0, perché SSL stesso non è mai stato aggiornato. Il testimone è passato a Sicurezza del livello di trasporto.

---

TLS 1.0 – L’era della standardizzazione IETF

Transizione da SSL a TLS (1999)

Alla fine degli anni ’90, l’IETF voleva standardizzare i protocolli di sicurezza di Internet. Tim Dierks e Christopher Allen guidarono gli sforzi per trasformare SSL in uno standard aperto. Microsoft e Netscape negoziarono il nome: TransportLayer Security fu il compromesso che rimase.

TLS 1.0, pubblicato come RFC 2246 nel gennaio 1999, era essenzialmente SSL 3.1 con un nuovo nome. Le differenze erano minime ma abbastanza significative da rompere la compatibilità. Non si potevano mischiare client SSL 3.0 e server TLS 1.0 senza un’attenta implementazione.

Le principali differenze rispetto a SSL 3.0

TLS 1.0 ha aggiornato la crittografia sottostante. Ha sostituito il codice di autenticazione dei messaggi (MAC) personalizzato di SSL con HMAC, standardizzato dai crittografi. La funzione di derivazione della chiave è stata modificata per prevenire alcuni attacchi teorici. Il sistema di allerta è stato ampliato con codici di errore più specifici.

TLS 1.0 richiedeva anche il supporto per le suite di cifratura DSS/DH, offrendo alle implementazioni una maggiore flessibilità. Questi cambiamenti sembrano piccoli, ma riflettono il passaggio dallo sviluppo proprietario alla standardizzazione guidata dalla comunità. L’IETF ora controllava l’evoluzione del protocollo.

---

TLS 1.1 e TLS 1.2 – Miglioramenti incrementali della sicurezza

Protezione di TLS 1.1 contro gli attacchi CBC (2006)

Rilasciato nell’aprile 2006 tramite la RFC 4346, TLS 1.1 risolveva specifiche vulnerabilità CBC. Il cambiamento più importante? I vettori di inizializzazione (IV) espliciti hanno sostituito quelli impliciti. Questo impediva agli aggressori di prevedere l’IV e di sfruttare il cipher block chaining.

TLS 1.1 ha anche migliorato la gestione degli errori per i record imbottiti. Invece di rivelare errori specifici di imbottitura, restituiva un avviso generico bad_record_mac. Queste modifiche proteggevano da BEAST (Browser Exploit Against SSL/TLS), scoperto anni dopo nel 2011.

Vennero istituiti i registri dei parametri IANA, rendendo più organizzata la gestione delle suite di cifratura. Ma l’adozione è stata lenta. Molte organizzazioni saltarono completamente TLS 1.1, aspettando i miglioramenti più sostanziali di TLS 1.2.

TLS 1.2 Flessibilità migliorata (2008)

Quando è stato rilasciato TLS 1.2? Ad agosto 2008, tramite RFC 5246. Questo aggiornamento ha portato i cambiamenti più significativi da SSL 3.0. Il protocollo è passato da combinazioni MD5/SHA-1 codificate a funzioni pseudorandom (PRF) specificate dalla suite di cifratura. SHA-256 è diventato il nuovo standard.

TLS 1.2 ha introdotto le modalità di cifratura autenticata con dati aggiuntivi (AEAD), tra cui AES-GCM e ChaCha20-Poly1305. Ha dato alle implementazioni flessibilità nella scelta degli algoritmi di hash e firma. Questa adattabilità si è rivelata fondamentale con l’evoluzione degli standard crittografici.

Il protocollo è tuttora ampiamente diffuso. Circa il 95,8% dei siti web supporta ancora TLS 1.2, spesso affiancato da TLS 1.3. Nel marzo 2021, l’IETF ha deprecato congiuntamente TLS 1.0 e 1.1 tramite la RFC 8996, rendendo TLS 1.2 lo standard minimo accettabile.

---

---

TLS 1.3 – Lo standard di sicurezza moderno

Cinque anni di sviluppo (2018)

TLS 1.3 ha impiegato un decennio per arrivare. L’IETF ha pubblicato l’RFC 8446 nell’agosto 2018 dopo 28 bozze e un’ampia collaborazione. Semplicità e prestazioni hanno guidato la riprogettazione. Il gruppo di lavoro ha eliminato le funzioni obsolete, semplificato l’handshake ed eliminato intere classi di vulnerabilità.

Google, Mozilla, Microsoft e Apple hanno rapidamente aggiunto il supporto. Entro il 2019, tutti i principali browser erano in grado di negoziare connessioni TLS 1.3. Cloudflare e altri fornitori di CDN lo hanno attivato per impostazione predefinita. L’ultima versione di TLS non ha solo migliorato la sicurezza, ma ha reso le connessioni criptate più veloci.

Miglioramenti rivoluzionari per la sicurezza

TLS 1.3 ha rimosso tutto ciò che è stato rotto o indebolito. Le suite di cifratura SHA-1, MD5, RC4, DES e 3DES? Sparite. Scambio di chiavi statico RSA e Diffie-Hellman? Eliminati. Il protocollo ora richiede perfetta segretezza in avanti utilizzando Diffie-Hellman effimero per tutte le connessioni.

L’handshake è cambiato radicalmente. Ogni messaggio dopo ServerHello viene crittografato, nascondendo la negoziazione da occhi indiscreti. La funzione di derivazione delle chiavi è passata all’HMAC-based Extract-and-Expand (HKDF), che offre migliori garanzie crittografiche.

TLS 1.3 ha introdotto anche la modalità 0-RTT (zero round-trip time). I client possono inviare dati crittografati nel primo messaggio ai server precedentemente contattati, eliminando la latenza dell’handshake. La macchina a stati semplificata ha reso le implementazioni meno soggette a errori. L’ECC è entrato a far parte delle specifiche di base con nuovi algoritmi di firma come RSA-PSS.

Adozione e coesistenza attuali

Qual è l’ultima versione di TLS? TLS 1.3 detiene questo titolo. Ma TLS 1.2 non è destinato a scomparire presto. Le organizzazioni hanno bisogno di tempo per aggiornare i server, testare la compatibilità e aggiornare il software dei clienti. La maggior parte dei siti attenti alla sicurezza ora supporta entrambi, lasciando che i clienti scelgano la migliore opzione disponibile.

La coesistenza funziona bene. I server negoziano la versione più alta supportata reciprocamente. I clienti che non sono in grado di gestire TLS 1.3 ritornano a TLS 1.2. Questo approccio di migrazione graduale evita i disastri di compatibilità che hanno afflitto le transizioni precedenti.

---

I malintesi più comuni sul versioning SSL/TLS

Perché non c’è TLS 2.0

Qual è la data di rilascio di TLS 2.0? Non ce n’è uno. TLS 2.0 non esiste e non esisterà mai. L’IETF utilizza un sistema di versioni incrementali: TLS 1.0, 1.1, 1.2, 1.3. La prossima versione, se arriverà, sarà TLS 1.4 o forse TLS 2.0, ma saltare direttamente a “TLS 2.0” dopo SSL 3.0 avrebbe causato una grande confusione.

Spesso ci si aspetta che i protocolli utilizzino numeri di versione maggiori (come un software che passa dalla versione 1 alla versione 2). Ma i protocolli crittografici si evolvono in modo più conservativo, con ogni versione che si basa su quella precedente.

Terminologia SSL vs TLS

Se chiedi un “certificato SSL” otterrai un certificato che funziona con TLS 1.2 e TLS 1.3. Il settore utilizza ancora “SSL” nel marketing perché è un termine familiare. Anche se la versione attuale dell’SSL è tecnicamente inesistente (l’SSL è terminato con la versione 3.0), il termine è rimasto.

Le autorità di certificazione come DigiCert e Sectigo vendono “certificati SSL” che utilizzano esclusivamente i protocolli TLS. È confuso ma innocuo. Ricorda solo che quando qualcuno parlerà di SSL nel 2026, quasi sicuramente intenderà TLS.

---

Il ruolo delle autorità di certificazione nell’evoluzione di SSL/TLS

Sviluppo dei tipi di convalida

I primi certificati SSL erano costosi e lenti. La convalida aziendale richiedeva giorni o settimane di verifiche manuali. Nel 2002, GeoTrust ha introdotto Convalida del dominioautomatizzando il processo di verifica della proprietà del dominio tramite e-mail o record DNS.

I certificatiExtended Validation sono arrivati nel 2007, promettendo la massima garanzia con le barre verdi degli indirizzi nei browser. Let’s Encrypt ha lanciato il programma nel 2015, offrendo certificati Domain Validation gratuiti attraverso l’emissione automatica. Cloudflare ha seguito con il proprio programma di certificati gratuiti. Questi cambiamenti hanno democratizzato HTTPSrendendo la crittografia accessibile anche ai piccoli siti web.

Riduzione del periodo di validità del certificato

I periodi di validità dei certificati hanno continuato a ridursi. Nel 2015 i requisiti di base hanno ridotto la validità massima da cinque a tre anni. Nel 2018 il limite è stato fissato a due anni. Safari di Apple ha imposto un limite massimo di un anno nel 2020, costringendo gli altri browser a seguirlo.

Ora il settore sta spingendo verso un ciclo di vita dei certificati ancora più breve. Il CA/Browser Forum ha definito una netta riduzione dei periodi di validità dei certificati: 200 giorni a partire dal 15 marzo 2026,100 giorni dal 15 marzo 2027 e solo 47 giorni entro il 15 marzo 2029.

Questo cambiamento rende impraticabile la gestione manuale dei certificati, spingendo le organizzazioni verso soluzioni automatizzate come il Certificate-as-a-Service (CaaS) basato su ACME, dove la convalida, l’emissione e il rinnovo sono gestiti automaticamente.

---

Pietre miliari del settore che hanno influenzato l’adozione di HTTPS

La spinta HTTPS di Google

Nell’agosto 2014, Google ha annunciato l’HTTPS come segnale di ranking. Questa singola decisione ha cambiato la storia dell’SSL. I webmaster che ignoravano la crittografia ebbero improvvisamente dei motivi commerciali per preoccuparsene. Nel 2016, metà del traffico web era criptato.

Chrome 68 ha fatto il passo successivo nel luglio 2018, contrassegnando tutti i siti HTTP come “Non sicuro.” L’avviso è apparso nella barra degli indirizzi per ogni pagina non criptata. Oggi, oltre il 95% del traffico web utilizza HTTPS. Google ha trasformato la crittografia da una best practice di sicurezza a un requisito aziendale.

Evoluzione degli indicatori di sicurezza del browser

Ricordi la barra degli indirizzi verde di Extended Validation? Non c’è più. Chrome l’ha rimossa nel 2020 dopo che alcune ricerche hanno dimostrato che gli utenti non la notavano o non la capivano. La stessa icona del lucchetto sta scomparendo, sostituita da indicatori neutri che normalizzano l’HTTPS piuttosto che premiarlo.

Chrome 69 ha rimosso il testo “Secure”, lasciando solo il lucchetto. I browser attuali si concentrano sull’avviso di connessioni insicure piuttosto che sull’elogio di quelle sicure. Il messaggio: HTTPS è un’aspettativa predefinita, non qualcosa di speciale.

---

Le principali vulnerabilità di sicurezza che hanno guidato l’evoluzione dei protocolli

Attacchi degni di nota a SSL/TLS

POODLE ha colpito SSL 3.0 nel 2014, sfruttando le vulnerabilità del padding oracle in modalità CBC. Gli aggressori potevano decriptare i cookie protetti effettuando il downgrade delle connessioni e modificando ripetutamente il testo cifrato. L’attacco ha ucciso SSL 3.0 nel giro di pochi mesi.

BEAST ha preso di mira TLS 1.0 nel 2011, utilizzando una debolezza CBC simile. Gli attaccanti potevano decriptare i cookie HTTPS iniettando codice lato client e osservando le risposte criptate. La soluzione richiedeva l’implementazione di IV espliciti in TLS 1.1.

BREACH ha abusato della compressione HTTP nel 2013. L’attacco non ha preso di mira il protocollo TLS in sé, ma ha dimostrato come le decisioni del livello applicativo influiscano sulla sicurezza. Heartbleed, scoperto nel 2014, ha esposto un problema critico di OpenSSL che ha fatto trapelare chiavi private e dati degli utenti.

Lezioni apprese

Ogni vulnerabilità ha dimostrato lo stesso punto: la retrocompatibilità è pericolosa. Mantenere in vita i vecchi protocolli per i sistemi legacy crea vettori di attacco. L’industria ha imparato a deprezzare in modo aggressivo e a forzare gli aggiornamenti.

Il merito è anche dei ricercatori di sicurezza. La divulgazione pubblica delle vulnerabilità ha accelerato i miglioramenti. Senza POODLE, SSL 3.0 potrebbe essere ancora in agguato nelle configurazioni dei server.

---

Il futuro dei protocolli SSL/TLS

Crittografia post-quantistica

I computer quantistici minacciano gli attuali algoritmi di crittografia. La crittografia RSA e a curva ellittica potrebbe diventare obsoleta una volta che le macchine quantistiche avranno raggiunto una scala sufficiente. Il NIST sta standardizzando algoritmi post-quantistici progettati per resistere agli attacchi quantistici.

TLS dovrà essere aggiornato per supportare questi algoritmi resistenti ai quanti. La transizione non sarà facile: la crittografia post-quantistica utilizza chiavi più grandi e approcci matematici diversi. Ma l’evoluzione del protocollo che ci ha portato da SSL 2.0 a TLS 1.3 ha dimostrato che la comunità è in grado di gestire transizioni importanti.

Tecnologie emergenti

DTLS (Datagram Transport Layer Security) estende TLS alle connessioni UDP. QUICsviluppato da Google e standardizzato dall’IETF, integra la crittografia direttamente nel livello di trasporto. Questi protocolli si basano sulle fondamenta crittografiche di TLS e si adattano a diversi casi d’uso.

Alternative basate sulla blockchain come Remme sperimentano la PKI distribuita. Le autorità di certificazione continuano a evolversi, automatizzando più processi e supportando periodi di validità più brevi. Cosa succederà dopo TLS 1.3? Probabilmente miglioramenti incrementali piuttosto che una riprogettazione completa. TLS 1.3 ha fatto bene la maggior parte delle cose.

---

Rimani al passo con i certificati TLS 1.3-Ready di SSL Dragon

Comprendere l’evoluzione dei protocolli è una cosa. Implementare i moderni standard di crittografia è un’altra cosa. SSL Dragon offre certificati digitali pienamente compatibili con TLS 1.3 e TLS 1.2, supportando i più recenti protocolli crittografici e suite di cifratura.

Offriamo un’emissione rapida, una crittografia solida e un’affidabilità del 99,99% del browser grazie alle partnership con le principali autorità di certificazione, tra cui DigiCert, Sectigo e GeoTrust. Le nostre soluzioni di gestione automatizzata dei certificati ti aiutano a gestire i cicli di vita di 47 giorni senza problemi di rinnovo manuale.

Stai migrando da protocolli deprecati? Il nostro team di assistenza dedicato ti guida nella transizione. Ogni acquisto include una garanzia di rimborso di 25 giorni. Esplora il nostro portafoglio di certificati e proteggi la tua infrastruttura con l’ultima versione di TLS.