Defaults.Exposed › Correzioni › Crittografia moderna (versione TLS e cifrari)

Come correggere Crittografia moderna (versione TLS e cifrari)

Il TLS è il lucchetto che mescola i dati che scorrono tra i tuoi visitatori e il tuo sito. Due cose rendono affidabile quel lucchetto: usare una versione moderna di TLS (non quelle vecchie e rotte), e usare cifrari forti (la vera e propria ricetta della mescolatura). Questa pagina copre entrambi — più alcune impostazioni correlate che non incidono sulla tua valutazione ma vale la pena conoscere.

In sintesi per la tua attività: Se il tuo sito gira su crittografia obsoleta o cifrari deboli, i dati privati che i tuoi clienti digitano — accessi, numeri di carta, contatti — possono essere intercettati e letti in silenzio sulle reti condivise, e puoi fallire i controlli di sicurezza che banche, processori di pagamento e clienti più grandi ora richiedono prima di fare affari con te.

Cosa può costarti

• Un cliente paga o accede su WiFi di hotel o bar, una connessione obsoleta o un cifrario debole permette a uno sconosciuto su quella rete di leggere la sua carta e la sua password, e la frode — e la telefonata arrabbiata — risale dritta al tuo sito.
• Chiedi di accettare pagamenti con carta (o il tuo provider di pagamenti ti ri-verifica) e vieni respinto perché un TLS obsoleto o un cifrario vietato viola le regole di sicurezza dei pagamenti — il tuo checkout online viene congelato finché non è sistemato.
• L'ufficio IT di un cliente più grande fa una scansione di sicurezza di routine prima di firmare, vede che il tuo sito permette ancora crittografia rotta, e ti segnala come rischio — il contratto si blocca per un problema che non costa nulla sistemare.
• Un reclamo per la protezione dei dati o una violazione finisce sulla tua scrivania e la prima cosa che chiedono le autorità è se hai protetto «adeguatamente» i dati dei clienti — far girare crittografia pubblicamente nota come rotta da anni è una risposta molto difficile da dare.
• Il tuo sito mostra un lucchetto, quindi tutti danno per scontato che sia del tutto sicuro, e questa lacuna passa inosservata per anni — finché un singolo accesso o numero di carta intercettato si trasforma in un incidente molto più costoso della correzione gratuita.

Perché è importante. La crittografia che è sicura è invisibile; la crittografia obsoleta o debole è una passività che resta tranquilla fino al giorno in cui ti costa un cliente, un contratto o un superamento di conformità. I controlli della versione TLS e dei cifrari sono le due parti che davvero muovono la tua valutazione, ed entrambe sono tipicamente una singola impostazione gratuita — non c'è alcun vantaggio nel lasciare attive le vecchie opzioni rotte.

In parole semplici

Quando qualcuno visita il tuo sito, tutto ciò che digita — accessi, numeri di carta, nomi, numeri di telefono, messaggi — viene mescolato durante il tragitto così che gli estranei non possano leggerlo. La tecnologia che fa la mescolatura si chiama TLS (potresti sentirla anche chiamare SSL, il suo nome più vecchio). Perché quella mescolatura sia davvero sicura, due cose devono essere giuste:

1. La versione TLS — quale generazione della tecnologia stai usando. Le prime versioni (TLS 1.0 e 1.1) sono pubblicamente rotte da anni; quelle sicure sono TLS 1.2 e TLS 1.3.
2. Il cifrario — la ricetta specifica che il TLS usa per fare la mescolatura. Alcuni cifrari (come RC4, DES e 3DES) sono stati violati e ora sono vietati; i cifrari moderni sono ancora forti.

Questa pagina copre entrambi, perché un sito può azzeccarne uno e sbagliare l’altro. Puoi avere un lucchetto moderno con una vecchia ricetta violabile ancora attiva — o una ricetta forte protetta da un lucchetto obsoleto. Ognuna delle due lacune è una porta aperta. Entrambe di solito si chiudono con la stessa singola modifica gratuita alle impostazioni del tuo server o hosting.

Quanto può costarti

• Un cliente viene derubato su WiFi pubblica. Qualcuno accede al proprio account o paga da un hotel, un bar o un aeroporto. Poiché il tuo sito permette ancora una vecchia versione TLS o un cifrario debole, uno sconosciuto su quella stessa rete forza la connessione verso l’opzione violabile e legge la sua password e il numero di carta in tempo reale. La frode ricade sul cliente, ma la colpa — e la telefonata di assistenza — ricade su di te.
• I tuoi pagamenti con carta vengono spenti. Le regole di sicurezza dei pagamenti (PCI DSS) richiedono TLS 1.2 come minimo e vietano esplicitamente cifrari deboli come RC4. Quando il tuo processore ti ri-verifica, o quando chiedi di accettare carte, una configurazione obsoleta fallisce il controllo e il tuo checkout viene congelato finché non è sistemato — esattamente nel momento sbagliato per il flusso di cassa.
• Un affare si blocca in una revisione di sicurezza. Prima che un cliente più grande firmi, il suo ufficio IT fa una scansione di routine. Segnala subito che il tuo sito accetta ancora crittografia rotta — il tipo di scoperta che sembra sbadata e fa chiedere all’acquirente cos’altro sia allentato. Il contratto resta nel limbo per un problema che non costa nulla sistemare.
• Un’autorità di regolamentazione fa la domanda scomoda. Dopo qualsiasi reclamo o violazione, la prima cosa che un’autorità per la protezione dei dati vuole sapere è se hai protetto «adeguatamente» i dati personali. Far girare crittografia pubblicamente nota come rotta da anni è molto difficile da difendere, e «non ci eravamo resi conto che la vecchia versione fosse ancora attiva» non è una risposta comoda.
• Si nasconde dietro il lucchetto per anni. Poiché il tuo sito mostra ancora un lucchetto normale, nessuno nota la lacuna — finché un singolo accesso o numero di carta intercettato diventa un incidente pubblico molto più costoso di quanto sarebbe stata la correzione di cinque minuti.

Cos’è davvero

La versione TLS

Un sito non supporta solo una versione di TLS — può offrirne diverse contemporaneamente e lasciare che il browser di ciascun visitatore scelga. Un visitatore moderno userà la versione più recente disponibile e vedrà un lucchetto normale. Il pericolo è che le vecchie versioni rotte possano starsene lì accanto a quelle buone come una porta sul retro aperta: un attaccante può forzare la connessione di un visitatore a «declassare» a TLS 1.0 o 1.1 e poi sfruttare le debolezze note di quelle versioni (gli attacchi BEAST e POODLE sono gli esempi famosi) per decifrare il traffico.

Quindi il nostro controllo si connette al tuo sito e testa ogni versione singolarmente — TLS 1.0, 1.1, 1.2 e 1.3 — per vedere quali il tuo server accetta ancora. Ecco com’è fatto un «buono» e come viene valutato:

• TLS 1.3 (con o senza 1.2), e nessuna legacy: il risultato migliore — una configurazione moderna e pulita. Punteggio pieno.
• Solo TLS 1.2, senza 1.3: sicuro e superato, ma lasci sul tavolo la versione più nuova e veloce. Quasi tutto il punteggio; abilitare 1.3 vale la pena.
• TLS 1.0 o 1.1 ancora accettati: un fallimento automatico, valutato zero e segnalato come critico — non importa che funzionino anche 1.2/1.3, perché le versioni rotte sono la porta aperta. Questo è ciò che devi sistemare.

Il cifrario

Una volta scelta una versione, il TLS sceglie un cifrario — l’algoritmo effettivo che mescola i dati. La maggior parte dei cifrari moderni è forte. Una manciata è rotta e non deve mai essere usata: RC4 (la sua mescolatura è sbilanciata e lascia trapelare il testo in chiaro), DES (la sua chiave è così corta da poter essere forzata), 3DES (vulnerabile all’attacco «Sweet32»), più NULL (nessuna cifratura affatto), cifrari EXPORT-grade (deliberatamente indeboliti — gli attacchi FREAK e Logjam), e cifrari anonimi (nessun controllo di identità, così un impostore può sedersi in mezzo).

Il nostro controllo dei cifrari fa due cose. Prima guarda il cifrario che il tuo server ha effettivamente negoziato con noi. Poi — ed è la parte importante — prova attivamente a stabilire un handshake usando diversi cifrari noti come rotti (RC4, 3DES, EXPORT, NULL e varianti anonime). Un server può scegliere un cifrario forte quando parla con un client moderno e tuttavia accettare uno debole se un attaccante insiste — ed è un reale rischio di declassamento. Se il tuo server accetta un qualsiasi cifrario vietato, il controllo lo segnala; accettarne uno critico (come RC4 o NULL) è un fallimento. (Su TLS 1.3 non c’è nulla di cui preoccuparsi qui — quella versione ha rimosso ogni cifrario debole per progettazione, quindi le verifiche vengono saltate.)

I tre extra informativi

Tre elementi correlati vengono riportati ma non incidono sulla tua valutazione — sono segnalati come informativi perché non possono essere verificati in modo affidabile dall’esterno, e su qualsiasi server o CDN moderno sono già gestiti correttamente:

• Compressione TLS (l’attacco CRIME): una vecchia funzionalità che, se lasciata attiva, potrebbe permettere a un attaccante di estrarre i cookie di sessione. È disabilitata per impostazione predefinita su ogni server web moderno da oltre un decennio, quindi oggi è di fatto un non-problema.
• OCSP stapling: una comodità per prestazioni e privacy in cui il tuo server pre-recupera la prova che il suo certificato non è stato revocato, così che ogni visitatore non debba chiederlo da sé all’autorità di certificazione (cosa più lenta e che fa trapelare dati di navigazione). Le CDN come Cloudflare lo fanno automaticamente.
• Rinegoziazione sicura: una correzione per un vecchio difetto (CVE-2009-3555) che permetteva agli attaccanti di iniettare dati in una sessione. Il TLS 1.3 ha rimosso del tutto la rinegoziazione, quindi lì è un non-problema, e i moderni server TLS 1.2 implementano la correzione per impostazione predefinita.

Li mostriamo così che la tua persona IT abbia il quadro completo, ma per la stragrande maggioranza dei titolari non c’è nulla da fare — il tuo punteggio è guidato dai controlli della versione e dei cifrari qui sopra.

Come sistemarlo (gratis, ~30 minuti)

Passa questo alla tua persona IT — la correzione è gratuita. Questa sezione è per chi gestisce il tuo dominio, il tuo sito o il tuo hosting. La correzione è una modifica di configurazione, non un acquisto; facciamo pagare solo il monitoraggio nel tempo, perché la tua crittografia resti configurata correttamente. La singola configurazione moderna qui sotto sistema in una volta sia le segnalazioni sulla versione sia quelle sui cifrari.

L’approccio affidabile più semplice è generare una configurazione collaudata invece di scriverla a mano: incolla il tipo del tuo server nel Generatore di configurazione SSL di Mozilla su https://ssl-config.mozilla.org/ e scegli il profilo «Intermediate» (ampia compatibilità) o «Modern» (solo TLS 1.3, se non devi supportare nulla di vecchio). Produce per te le righe ssl_protocols e ssl_ciphers corrette.

Per piattaforma:

1. Cloudflare o un host gestito — di solito uno o due clic. In Cloudflare: SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2, e le suite di cifrari lì sono gestite per te (la piattaforma non offrirà cifrari vietati). La maggior parte degli host gestiti e dei creatori di siti (Squarespace, Wix, Shopify, host WordPress moderni) impone già TLS 1.2+ con cifrari forti — conferma solo che non ci sia ancora attiva un’opzione di «TLS legacy» o «compatibilità con browser vecchi».
2. Nginx. Imposta solo versioni moderne e un elenco esplicito di cifrari forti, poi ricarica:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

   (TLS 1.3 richiede OpenSSL 1.1.1+ sulla macchina.)
3. Apache. Disabilita le vecchie versioni e fissa un elenco di cifrari forti, poi riavvia:

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS. Usa lo strumento gratuito IIS Crypto (o le equivalenti impostazioni del registro) per disabilitare TLS 1.0 e 1.1, disabilitare i cifrari RC4/DES/3DES/NULL/EXPORT, e lasciare TLS 1.2 e 1.3 con cifrari forti abilitati. Il modello «Best Practices» dello strumento fa tutto questo in un clic.
5. Gli extra informativi (opzionali, gratuiti). Se vuoi fare pulizia completa: su Nginx aggiungi ssl_stapling on; ssl_stapling_verify on; (con una riga resolver) per l’OCSP stapling; su Apache, SSLUseStapling On. La compressione TLS e la rinegoziazione sicura sono già sicure per impostazione predefinita sui server moderni — nessuna azione necessaria. Su Cloudflare tutti e tre sono gestiti automaticamente.
6. Verifica, poi ricontrolla qui. Conferma che rimangano solo le versioni e i cifrari sicuri — per esempio con nmap --script ssl-enum-ciphers -p 443 tuodominio.com, o testa con gli strumenti collegati a https://ssl-config.mozilla.org/ — poi riesegui questo controllo. Dove possibile, abilita TLS 1.3 accanto a 1.2: è sia più veloce sia più sicuro.

Errori comuni

• «Abbiamo un lucchetto, quindi siamo a posto.» Il lucchetto dimostra solo che una connessione sicura esiste. Non dice nulla sul fatto che una vecchia versione o un cifrario vietato sia ancora accettato in sottofondo — che è precisamente la lacuna che questi controlli trovano.
• Sistemare la versione ma non i cifrari (o viceversa). Disabilitare TLS 1.0/1.1 non rimuove automaticamente RC4 o 3DES, e fissare cifrari forti non disabilita automaticamente le vecchie versioni. Imposta entrambi — la configurazione generata qui sopra lo fa.
• Lasciare attivi gli interruttori di «legacy» o «compatibilità con browser vecchi». Molti host e CDN hanno un’opzione che riabilita in silenzio le versioni rotte o i cifrari deboli «per compatibilità». Non aiuta quasi mai un visitatore reale e causa direttamente questa segnalazione.
• Dimenticare di ricaricare/riavviare davvero il server. Le modifiche di configurazione non hanno effetto finché il server web non viene ricaricato — un motivo sorprendentemente comune per cui un sito «sistemato» fallisce ancora il ricontrollo.
• Configurare un server ma non tutti. Se gestisci un bilanciatore di carico, più server web, o sottodomini separati (negozio, blog, app), ogni endpoint TLS ha bisogno della stessa configurazione — quello più debole è ciò che un attaccante prende di mira.

Cosa ricordare

La versione TLS e il cifrario sono le due parti della tua crittografia che davvero muovono la tua valutazione, ed entrambe si riducono a spegnere opzioni che sono rotte in pubblico da anni. La correzione è gratuita, è di solito una riga di configurazione moderna per server, e per un visitatore normale non cambia nulla se non rendere la sua connessione davvero sicura. Gli elementi correlati — compressione, OCSP stapling, rinegoziazione sicura — vale la pena conoscerli ma non incideranno sul tuo punteggio, e su qualsiasi configurazione moderna sono già gestiti per te.

FAQ