SSL e TLS: differenze, evoluzione e sicurezza

SSL è il nome che molti usano ancora per abitudine, ma oggi la sicurezza del traffico web passa da TLS. La distinzione non è solo terminologica: SSL è una tecnologia superata, mentre TLS è l’evoluzione che ha corretto limiti critici, migliorato la negoziazione delle chiavi e reso più robusto il trasporto dei dati tra client e server.

In pratica, quando un sito mostra il lucchetto nel browser, quasi sempre sta usando TLS. Dire “certificato SSL” è diventato un modo colloquiale per indicare il certificato usato dal canale HTTPS, ma dal punto di vista tecnico il protocollo in uso è TLS. Questa differenza conta quando si leggono log, si configurano server web, si gestiscono appliance o si analizzano incidenti di sicurezza.

SSL e TLS: la differenza reale

SSL significa Secure Sockets Layer. Le versioni storiche più note sono SSL 2.0 e SSL 3.0, entrambe ormai considerate insicure e da disabilitare. TLS, Transport Layer Security, nasce come successore di SSL e ne eredita il modello di base: autenticazione del server tramite certificato, scambio sicuro delle chiavi e cifratura del traffico applicativo.

La sostanza è questa: SSL è il predecessore, TLS è lo standard attuale. Quando si parla di “attivare SSL” su un server moderno, nella maggior parte dei casi si intende configurare HTTPS con TLS 1.2 o TLS 1.3. Se un sistema supporta ancora SSL, va trattato come un rischio, non come una compatibilità da preservare.

Come funziona il handshake TLS

Il punto più importante non è il nome del protocollo, ma il modo in cui viene stabilita la sessione sicura. Il client si collega, propone versioni e suite crittografiche, il server risponde con i parametri che accetta, presenta il certificato e dimostra di possedere la chiave privata associata. Da lì in avanti, le parti derivano chiavi simmetriche temporanee per cifrare il traffico.

Questo processo serve a tre obiettivi distinti: autenticare il server, proteggere la confidenzialità dei dati e garantire l’integrità della comunicazione. Se il certificato non è valido, scaduto, emesso per un dominio diverso o firmato da una CA non fidata, il browser segnala un problema. Se la suite negoziata è debole o il protocollo è vecchio, il rischio non è solo teorico: può aprire la strada a downgrade attack, intercettazione o compatibilità fragile con client moderni.

Perché SSL è stato abbandonato

SSL 2.0 e SSL 3.0 sono stati dismessi perché non reggono più gli standard di sicurezza attuali. Alcuni attacchi storici hanno mostrato debolezze nell’uso del padding, nella negoziazione e nella gestione di certe primitive crittografiche. Il risultato è semplice: se un server accetta SSL, sta offrendo una superficie d’attacco inutile.

TLS ha corretto gran parte di quei problemi e ha continuato a evolvere. TLS 1.0 e 1.1 hanno avuto una lunga vita, ma oggi sono generalmente da evitare. TLS 1.2 resta ancora ampiamente supportato e, in molti ambienti, è il minimo accettabile. TLS 1.3 è l’opzione preferibile dove disponibile: semplifica l’handshake, elimina algoritmi obsoleti e migliora sia sicurezza sia prestazioni.

Versioni TLS: cosa tenere e cosa disattivare

La scelta pratica oggi è quasi sempre tra TLS 1.2 e TLS 1.3. Se devi mantenere compatibilità con client datati, TLS 1.2 è la soglia minima ragionevole. TLS 1.0 e TLS 1.1 vanno disabilitati salvo casi eccezionali e documentati, perché il costo di mantenerli è superiore al beneficio.

La strategia corretta è verificare prima chi si connette davvero al servizio. Su ambienti pubblici, spesso i client moderni coprono già TLS 1.2/1.3. Su integrazioni legacy, dispositivi industriali o software datato, può emergere la necessità di una transizione graduale. In quel caso non si “lascia tutto aperto”: si misura l’impatto, si pianifica la migrazione e si riduce la finestra di esposizione.

Certificati: il punto che confonde più spesso

Molti chiamano “certificato SSL” quello che in realtà è un certificato X.509 usato per TLS. Il certificato non cifra da solo il traffico: serve a dimostrare l’identità del server e a legare la chiave pubblica a un nome di dominio o a un’identità organizzativa. La cifratura avviene poi durante la sessione, con chiavi generate o derivate nel handshake.

Il certificato va verificato su più livelli: nome corretto nel SAN, catena completa, scadenza, algoritmo di firma, dimensione della chiave e presenza della chiave privata corrispondente sul server. Un certificato valido ma installato male produce comunque errori, e spesso il problema viene scambiato per “TLS rotto” quando in realtà è una semplice incoerenza di configurazione.

Configurazione corretta su server web

Su un server web moderno l’obiettivo minimo è: solo TLS 1.2 e 1.3, cipher suite robuste, certificato corretto, redirect da HTTP a HTTPS e HSTS se l’assetto è stabile. La configurazione precisa cambia tra Apache, Nginx e altri stack, ma il principio è identico: ridurre il numero di opzioni deboli e rendere prevedibile la negoziazione.

Prima di modificare la configurazione, conviene fare un backup del file interessato e testare la sintassi. Su sistemi Linux recenti, questo è il minimo sindacale quando si tocca il layer TLS, perché un errore di configurazione può bloccare l’accesso al sito o far fallire il reload del servizio.

Esempio di controllo rapido da terminale

Per capire rapidamente cosa espone un server, puoi verificare la negoziazione TLS con uno strumento di diagnostica. Il comando seguente mostra versione, certificato e parametri di handshake:

openssl s_client -connect example.com:443 -servername example.com

Tra le cose da osservare: la versione TLS negoziata, il nome del certificato, la catena presentata e l’eventuale presenza di errori di verifica. Se il certificato non corrisponde al dominio, il problema è immediato e va corretto lato server o lato terminazione SSL/TLS, non aggirato nel client.

HTTP e HTTPS non sono la stessa cosa

HTTP è il protocollo applicativo; HTTPS è HTTP trasportato dentro TLS. Questo significa che il contenuto della richiesta e della risposta viene protetto, ma non elimina automaticamente tutti i problemi del sito. Un’applicazione vulnerabile resta vulnerabile anche su HTTPS: SQL injection, XSS, accessi impropri e log esposti non spariscono solo perché c’è il lucchetto.

Un errore frequente è trattare TLS come una soluzione totale. In realtà protegge il canale, non la logica applicativa. Per questo un audit serio guarda insieme trasporto, hardening del web server, policy dei cookie, header di sicurezza, gestione delle sessioni e aggiornamento del software.

Prestazioni: TLS pesa, ma meno di quanto si creda

Molti associano TLS a un sovraccarico importante, ma nella pratica l’impatto è spesso contenuto, soprattutto con hardware moderno, session reuse e TLS 1.3. Il costo vero si vede più facilmente sul primo handshake che sul traffico continuativo. Per questo le metriche da guardare sono TTFB, latenza p95, percentuale di handshake falliti e carico CPU nei picchi.

Se un sito lento peggiora dopo l’attivazione di HTTPS, non è detto che TLS sia la causa principale. Potrebbe esserci una configurazione subottimale, una catena di certificati troppo pesante, un reverse proxy mal tarato o un backend già saturo. Prima di cambiare algoritmi o disabilitare controlli, conviene misurare.

Errori tipici da evitare

1. Mantenere SSL 2.0, SSL 3.0, TLS 1.0 o TLS 1.1 attivi “per sicurezza di compatibilità”. In realtà aumentano il rischio senza offrire un vantaggio reale.
2. Usare un certificato valido ma con nome non coerente con il dominio servito. Il browser segnala l’errore, anche se il certificato è stato emesso correttamente.
3. Installare solo il certificato del server e dimenticare la catena intermedia. Alcuni client possono fallire la verifica o mostrare warning.
4. Confondere la protezione del canale con la sicurezza dell’applicazione. TLS non corregge bug logici o autorizzazioni sbagliate.
5. Tenere chiavi private e file di configurazione in modo disordinato. La sicurezza del canale dipende anche dalla protezione dei segreti lato server.

Controlli pratici dopo una modifica TLS

Dopo un cambio di configurazione, i controlli minimi sono semplici: il sito risponde in HTTPS, il certificato è valido, la versione negoziata è quella attesa e non compaiono errori nei log del web server. Su Apache o Nginx, un reload riuscito non basta: serve anche una verifica reale dal client.

Un controllo utile è aprire il sito da un browser aggiornato e da un client di test, osservando eventuali warning, catena incompleta o problemi di redirect. Se il sito espone ancora HTTP, il redirect verso HTTPS deve essere coerente e non creare loop, soprattutto dietro proxy o CDN.

Se c’è una CDN o un bilanciatore, bisogna capire dove termina TLS. La terminazione può avvenire all’edge, sul load balancer o sull’origin. Cambia poco per l’utente finale, ma cambia molto per diagnostica, logging, gestione dei certificati e responsabilità operativa. Se non è chiaro dove avvenga la terminazione, si finisce facilmente a cercare il problema nel posto sbagliato.

TLS 1.3: perché è il riferimento attuale

TLS 1.3 ha semplificato il protocollo e rimosso parti che nel tempo avevano accumulato complessità e fragilità. Il risultato è un handshake più rapido, meno opzioni pericolose e una superficie d’attacco più piccola. Non è solo una versione “più nuova”: è una razionalizzazione del modello di sicurezza.

Non tutti gli ambienti possono adottarlo senza verifiche, ma dove è possibile conviene farlo. La compatibilità con client moderni è in genere buona, e il vantaggio operativo sta anche nella semplificazione della manutenzione: meno scelte da tenere sotto controllo, meno eccezioni da spiegare, meno spazio per configurazioni deboli.

Conclusione tecnica: cosa ricordare davvero

Se devi portarti a casa un solo concetto, è questo: SSL è il passato, TLS è il presente. In un’infrastruttura sana si disattivano i protocolli vecchi, si verifica il certificato con attenzione, si controlla la catena, si misura l’impatto sulle prestazioni e si considera TLS una parte del sistema di sicurezza, non la sicurezza intera.

Chi gestisce server, hosting o servizi esposti su Internet dovrebbe trattare la configurazione TLS come un componente vivo: va testato, documentato e rivisto nel tempo. Le versioni evolvono, i client cambiano, i requisiti di compliance si spostano. Restare fermi alla dicitura “SSL attivo” non aiuta nessuno: molto meglio sapere esattamente quale TLS stai offrendo, a chi e con quali compromessi.