Perché SSL è diventato TLS: la guerra segreta tra Netscape e Microsoft che ha cambiato il Web

A metà degli anni ’90, il panorama del Web era infuocato da una competizione senza esclusione di colpi tra due giganti emergenti: Netscape e Microsoft. La cosiddetta “guerra dei browser” non si limitava all’interfaccia utente o alle prestazioni, ma si estendeva anche ai protocolli fondamentali per la sicurezza delle comunicazioni su Internet. Netscape, allora pioniera del Web commerciale, fu la prima a introdurre un sistema crittografico per proteggere le comunicazioni: SSL (Secure Sockets Layer). La versione iniziale, mai rilasciata pubblicamente, conteneva gravi falle crittografiche. Il primo protocollo effettivamente distribuito fu SSL 2.0, integrato in alcune versioni di Netscape Navigator: risale al 1995. Il protocollo TLS, erede di SSL, nacque nel 1999 ma la sua origine è tutto fuorché lineare: è il frutto di rivalità, compromessi tecnici e lotte di potere.

A cosa servono SSL/TLS?

Anche se incontriamo, almeno “dietro le quinte”, i protocolli SSL/TLS prevalentemente sul Web non è soltanto qui che sono utilizzati.

SSL e TLS (Transport Layer Security) sono protocolli crittografici progettati per proteggere la comunicazione tra due dispositivi attraverso una rete. Il loro scopo principale è garantire:

• Crittografia – I dati scambiati sono cifrati e quindi illeggibili da chiunque intercetti il traffico.
• Autenticazione – Verifica che la controparte (i.e. un server) sia chi dice di essere.
• Integrità – Garantisce che i dati non siano stati modificati durante il transito.

Anche se il caso più noto è HTTPS (le pagine Web trasmesse in forma crittografata usano proprio TLS sui server Web moderni…) i protocolli SSL/TLS sono usati in molti altri contesti. Citiamone i principali:

Ambito	Descrizione
Email	Protocollo STARTTLS su SMTP, IMAP e POP3 per proteggere l’invio e la ricezione di email.
VPN	Protocolli come OpenVPN usano TLS per autenticare e cifrare il traffico tra client e server.
VoIP	Comunicazioni vocali sicure tramite SIP su TLS.
FTPS	Versione sicura di FTP che utilizza TLS per proteggere il trasferimento dei file.
Database	Connessioni sicure con PostgreSQL, MySQL, MongoDB e altri, tramite TLS.
LDAP over TLS (LDAPS)	Protegge le interrogazioni ai servizi di directory aziendali con TLS.
IoT (MQTT su TLS)	TLS è usato per proteggere le comunicazioni tra dispositivi connessi tramite protocollo MQTT.

SSL 2.0: le fondamenta imperfette

Si capì abbastanza velocemente che SSL 2.0 non era esente da problemi in quanto presentava molteplici problemi:

• Debolezze nella negoziazione delle cipher suite (insieme predefinito di algoritmi crittografici usati in una connessione SSL/TLS per garantire sicurezza e privacy).
• Mancanza di protezione contro attacchi man-in-the-middle
• Problemi di interoperabilità e gestione della sessione

Era evidente che SSL 2.0 necessitasse di una revisione. Ed è proprio qui che entrò in gioco Microsoft. L’azienda all’epoca guidata da Bill Gates non si limitò a implementare SSL 2.0, ma decise di “correggerlo” e ridefinirlo secondo i propri interessi. Così nacque PCT (Private Communication Technology), un protocollo ispirato a SSL 2.0 ma con modifiche proprietarie, supportato solo da Internet Explorer e IIS (Internet Information Services).

La mossa era chiara: Microsoft voleva assumere il controllo sullo standard della sicurezza online, battendo sul tempo Netscape.

SSL 3.0: la risposta di Netscape

Netscape, dal canto suo, non poteva permettere che Microsoft guidasse la definizione della sicurezza sul Web. La risposta fu lo sviluppo di SSL 3.0, una riscrittura molto più ambiziosa e pulita del protocollo, frutto del lavoro di Paul Kocher, esperto crittografo.

Con SSL 3.0, Netscape introdusse alcune novità decisive migliorando le attività di negoziazione crittografica, la protezione contro rollback attack (attacco in cui un aggressore forza due sistemi a usare una versione più vecchia e vulnerabile di un protocollo di sicurezza) e una struttura estensibile per adattarsi a nuovi algoritmi.

Eppure, la frammentazione tra SSL 3.0 e PCT minacciava di creare una pericolosa dualità nell’ambito degli standard di sicurezza.

Il compromesso: dalla rivalità alla standardizzazione

Per evitare una guerra senza vincitori, a portare pace e un po’ d’ordine ci pensò un gruppo di mediatori indipendenti. Con un intervento determinante di un allora (ancora) poco noto Bruce Schneier, insieme con molti altri esperti crittografi, Netscape e Microsoft acconsentirono a cedere la definizione del protocollo all’IETF (Internet Engineering Task Force), per garantire un processo aperto e neutrale.

Come parte dell’accordo, SSL 3.0 fu modificato per non sembrare un semplice standard “marchiato Netscape” e il nome cambiato in TLS 1.0. Tecnicamente, TLS 1.0 è a tutti gli effetti SSL 3.1, ma il cambio di nome fu una mossa diplomatica per sancire una nuova era di cooperazione e neutralità.

Dopo SSL 3.0, quindi, IETF – ente che si occupa della standardizzazione dei protocolli Internet – ha gestito la stesura delle specifiche delle varie versioni di TLS (e continua a farlo ancora oggi).

Perché si parla ancora di SSL?

Molti strumenti e interfacce usano ancora il termine SSL per abitudine, anche se tecnicamente implementano TLS. Il motivo è riconducibile a motivi di branding, marketing o comprensibilità per gli utenti meno tecnici. Inoltre, i certificati digitali usati con TLS sono ancora chiamati “certificati SSL” in numerosi servizi, anche se non usano più SSL vero e proprio da anni.

Alcune librerie e API software mantengono il prefisso “SSL” per continuità, anche se sotto il cofano usano solo TLS: si pensi ad esempio, alla notissima OpenSSL.

Perché alcune versioni di TLS sono già state abbandonate e come verificare quelle in uso

Tutte le versioni di SSL sono ormai considerato “decadute”. Tuttavia, anche TLS 1.0 e TLS 1.1 sono accantonate dal 2021. Ciò è dovuto al fatto che le prime versioni di TLS utilizzavano algoritmi di cifratura e di hashing oggi considerati insicuri:

• MD5 e SHA-1: soggetti a collisioni, quindi non più affidabili per garantire l’integrità dei dati.
• Cifrature con blocchi in modalità CBC (Cipher Block Chaining): vulnerabili ad attacchi come BEAST e Lucky13.
• Assenza di forward secrecy: la compromissione delle chiavi private può esporre tutte le comunicazioni passate.

Alcune versioni di TLS (e SSL) hanno mostrato vulnerabilità di sicurezza critiche nel tempo. Ad esempio POODLE (Padding Oracle On Downgraded Legacy Encryption) sfruttava la compatibilità con SSL 3.0 per attacchi di tipo man-in-the-middle; i cosiddetti attacchi di downgrade forzavano client e server a usare versioni più vecchie e insicure; gli attacchi come BEAST e CRIME sfruttavano debolezze nelle modalità di cifratura e compressione.

In ambito locale, si possono usare openssl o nmap per verificare le versioni TLS supportate dai vari siti. Esempio:

openssl s_client -connect nomehost:443 -tls1_2
openssl s_client -connect nomehost:443 -tls1_3
openssl s_client -connect nomehost:443 -tls1_1

nmap --script ssl-enum-ciphers -p 443 nomehost

L’ultimo comando genera un resoconto con tutte le versioni TLS e gli algoritmi supportati dal server.

Il test di Qualys – SSL Labs è da sempre un punto di riferimento report per ottenere un riscontro dettagliato sulle versioni TLS supportate, sulla sicurezza dei certificati, sulle cipher suite e sulle vulnerabilità note.