~/tips/hardening_tls.key

di

Prefazione

Secure Sockets Layer (SSL) era un protocollo progettato per proteggere il traffico di rete in transito, tuttavia nel ’99 è stato sostituito da Transport Layer Security (TLS). Questi protocolli sono noti per proteggere il traffico web con HTTPS. Tuttavia, possono essere utilizzati per proteggere molti tipi di traffico diversi, ad esempio il traffico e-mail, la messaggistica istantanea e altro.

Un po’ di storia

La versione originale di SSL è stata sviluppata da Netscape per il browser Navigator ma non è stata pubblicata. La versione 2.0 è stata pubblicata nel 1995 e aggiornata nuovamente a SSL 3.0 nel 1996. La versione SSL 2.0 è stata vietata nella RFC 6176 rilasciata nel 2011. La versione SSL 3.0 è stata deprecata nella RFC 7568 nel 2015.

Il supporto del browser per SSL è stato rimosso molti anni fa. Chrome ha rimosso SSL e TLS fallback nella versione 32 rilasciato a novembre 2014. Firefox ha rimosso SSL nella versione 34 rilasciata a dicembre 2014. Internet Explorer ha disabilitato SSL per i siti in modalità protetta a febbraio 2015.

Pertanto, tutti i sistemi in questi giorni dovrebbero invece eseguire esclusivamente Transport Layer Security. Tuttavia, ovviamente questo ha anche avuto problemi di sicurezza e miglioramenti aggiunti nel tempo. TLS 1.0 è stato rilasciato per la prima volta nel 1999, TLS 1.1 è stato rilasciato nel 2006 ed entrambi sono stati ritirati nel 2021. Tuttavia, molte organizzazioni hanno scoraggiato l’uso di “Early TLS” (TLS 1.0) molto prima della data di ritiro del 2021. Ad esempio, il Payment Card Industry Security Standards Council (PCI SSC) spingeva le organizzazioni ad abbandonare TLS 1.0 prima di giugno 2018.

Infatti, poiché TLS 1.0 e TLS 1.1 sono ora obsoleti, molti browser hanno rimosso il supporto per questi protocolli. Chrome ha deprecato TLS 1.0 e TLS 1.1 in Chrome 72, con una rimozione totale in Chrome 81. Tuttavia, questo è stato ritardato a causa della pandemia da Coronavirus, sebbene sia stato aggiunto un avviso in Chrome 84. TLS 1.2 è stato ampiamente supportato dai browser Web per molti ormai da anni, ad esempio Chrome supporta il più sicuro TLS 1.2 da agosto 2013 e Firefox lo supporta da febbraio 2014.

Nel 2018, TLS 1.3 è stato rilasciato ed è ampiamente supportato dai browser Web, ma molti siti non lo hanno ancora abilitato, anche se offre miglioramenti della sicurezza rispetto alle versioni precedenti.

Detto questo, le organizzazioni dovrebbero disabilitare tutte le versioni di SSL e disabilitare TLS 1.0 e TLS 1.1. E anche tu dovresti anche controllare se hai abilitato TLS 1.3 e considerare di abilitarlo se non lo fai.

Cipher suites

Quando si tratta di configurare TLS, ci sono molte più opzioni oltre alla versione che la tua applicazione dovrebbe supportare: devi anche configurare quali “suite di cifratura” vuoi supportare. Si tratta di un insieme di algoritmi utilizzati per proteggere la connessione e in genere includono:

  • un algoritmo di scambio di chiavi
  • un algoritmo di autenticazione
  • un algoritmo di crittografia
  • un controllo di integrità

Scambio delle chiavi

L’algoritmo di scambio delle chiavi è l’algoritmo utilizzato per scambiare le chiavi per l’utilizzo da parte dell’algoritmo di crittografia: poiché stai potenzialmente comunicando con una parte con cui non hai mai comunicato prima (come un sito Web che non hai mai visitato in precedenza), hai bisogno di alcuni meccanismo per lo scambio di chiavi crittografiche. Ciò comporta generalmente l’uso di chiavi asimmetriche per proteggere un canale tramite il quale è possibile scambiare chiavi simmetriche. Sebbene all’inizio possa sembrare strano, in genere è dovuto al fatto che la crittografia simmetrica è più veloce, quindi più adatta alla “crittografia di massa”. Un esempio di un algoritmo utilizzato per lo scambio di chiavi sarebbe Diffie-Hellman a curva ellittica. Ci arriviamo fra poco.

Algoritmo di autenticazione

L’algoritmo di autenticazione viene utilizzato per garantire che il server remoto sia chi dice di essere e, pertanto, non è stata eseguita alcuna intercettazione. Questo ci porta nell’enorme argomento dell’infrastruttura a chiave pubblica, in breve, il tuo browser Web è preconfigurato con i dettagli di un gran numero di autorità di certificazione (CA) attendibili e la tua organizzazione potrebbe persino avere la propria CA. Il certificato del sistema remoto viene verificato per garantire che sia firmato da un’autorità di certificazione attendibile. L’idea è che solo il server corretto potrebbe avere il certificato corretto firmato dalla terza parte attendibile (l’autorità di certificazione) poiché la CA non avrebbe firmato un certificato senza prima convalidare la proprietà del server.

Algoritmo di autenticazione

L’algoritmo di autenticazione può essere lo stesso dell’algoritmo di scambio di chiavi, ad esempio con TLS_RSA_WITH_AES_256_GCM_SHA384, RSA viene utilizzato sia per lo scambio di chiavi che per l’autenticazione mentre con TLS_DHE_RSA_WITH_AES_256_CCM, Ephemeral Diffie-Hellman viene utilizzato per lo scambio di chiavi e RSA viene utilizzato per l’autenticazione.

Si noti inoltre che esiste un’opzione “Anon” per l’autenticazione, ma questa disabilita effettivamente il controllo dell’autenticazione e quindi non dovrebbe essere utilizzata. Ad esempio, nella suite di cifratura TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384, l’autenticità del sistema remoto non è convalidata.

Algoritmo di crittografia

L’algoritmo di crittografia è quello utilizzato per crittografare la maggior parte delle comunicazioni, quindi il traffico Web effettivo, il traffico di posta elettronica o il contenuto del download di file. Utilizziamo qui il termine algoritmo di crittografia per distinguerlo da altri algoritmi di crittografia che potrebbero essere utilizzati, ad esempio la crittografia verrà utilizzata durante lo scambio di chiavi, ma tale algoritmo può essere utilizzato solo per lo scambio di chiavi e un algoritmo diverso utilizzato per il resto del trasferimento dati. Un esempio di un algoritmo di crittografia sarebbe AES.

Controllo di integrità

C’è anche un controllo di integrità, per garantire che il messaggio provenga da dove dovrebbe provenire e che non sia stato manomesso durante il transito. Poiché la crittografia viene utilizzata per mascherare il contenuto di una comunicazione (che protegge la riservatezza dei dati), alcune persone presumono che ciò significhi che protegga anche l’integrità dei dati, impedendo che vengano modificati durante il transito. Tuttavia, questo non è necessariamente il caso e la protezione della riservatezza e la protezione dell’integrità sono due sfide separate e possono essere gestite da meccanismi diversi. Ad esempio, una connessione può utilizzare AES in modalità CBC per la riservatezza, ma può utilizzare un HMAC utilizzando SHA-2 per l’integrità. In alternativa, un sistema può utilizzare AES-GCM che può fornire entrambi.

Key Exchange Algorithms

L’algoritmo di scambio di chiavi viene utilizzato – come dice il nome stesso – per scambiare una chiave utilizzata per la crittografia: l’algoritmo di scambio chiavi utilizza in genere la crittografia asimmetrica.

Una delle principali preoccupazioni qui è come vengono generate le chiavi e se è fattibile per un utente malintenzionato compromettere le sessioni passate quando compromette il sistema.

Inoltre, per ogni sessione dovrebbero essere generate chiavi di sessione univoche, il che significa che la segretezza in avanti proteggerebbe tutte le altre comunicazioni se una singola chiave di sessione viene compromessa, oltre a proteggere le comunicazioni precedenti se la chiave a lungo termine viene compromessa.

Un’altra cosa degna di nota qui è l’attacco ROBOT (That’s Return Of Bleichenbacher’s Oracle Threat) che è una vulnerabilità nello scambio di chiavi di crittografia RSA (o più precisamente è un attacco Oracle di riempimento contro PKCS # 1 v1.5, utilizzato da RSA) . Si tratta di una vulnerabilità significativa che consentirebbe a un utente malintenzionato di monitorare il traffico e successivamente decrittografarlo.

Pertanto, a causa sia di ROBOT che della sua mancanza di Forward Secrecy in generale, è necessario disabilitare tutte le suite di cifratura che utilizzano lo scambio di chiavi di crittografia RSA. Il nome IANA per tutte queste suite di crittografia inizia con “TLS_RSA”, ad esempio TLS_RSA_WITH_AES_128_GCM_SHA256. Da non confondere con le suite di crittografia che utilizzano RSA per l’autenticazione ma non lo scambio di chiavi, come TLS_DHE_RSA_WITH_AES_256_CCM. Per farla breve: dovresti disabilitare tutte le suite di cifratura che avviano TLS_RSA a favore di alternative più sicure come Diffie-Hellman Ephemeral (TLS_DHE) o Elliptic Curve Diffie-Hellman Ephemeral (TLS_ECDHE).

Cifratura e modalità

Quando si tratta di crittografia è possibile utilizzare un altro algoritmo e se si tratta di una cifratura a blocchi, comporterà anche l’uso di una modalità di cifratura. La maggior parte degli algoritmi di crittografia utilizzati con TLS sono cifrari a blocchi e i cifrari a blocchi crittografano un blocco di dati di lunghezza fissa e quindi per crittografare dati di lunghezza maggiore rispetto a un singolo blocco, è necessario utilizzare una modalità di cifratura. La modalità di cifratura più semplice è nota come Electronic Cookbook (ECB) e crittografa separatamente ogni parte del testo in chiaro, ma ciò può rivelare schemi nel testo in chiaro all’interno del testo cifrato, quindi esistono molte modalità alternative che utilizzano la diffusione per nascondere questi schemi.

Ad esempio, con Cipher Block Chaining (CBC), ogni blocco di testo in chiaro viene sottoposto a XOR con il blocco di testo cifrato precedente. Il primo blocco è sottoposto a XOR con un vettore di inizializzazione (IV). Questo nasconde i modelli nel testo in chiaro. Tuttavia, diverse vulnerabilità Oracle di riempimento sono state precedentemente rilevate all’interno delle implementazioni di CBC all’interno di Transport Layer Security (TLS). Come Lucky13, Zombie POODLE e GOLDENDOODLE.

Per questo motivo, l’uso di ECB e CBC è sconsigliato a favore di modalità più sicure come CCM e GCM.

Per evitare del tutto il problema delle modalità di cifratura non è necessario utilizzare una cifratura a blocchi, ma potrebbe essere utilizzata una cifratura a flusso. Ciò negherebbe il requisito per una modalità di cifratura. Esempi di cifrari a flusso includono Chacha20 e RC4. Tuttavia, RC4 è noto per essere vulnerabile ad attacchi come Bar Mitzvah e RC4NOMORE, quindi mangari non scegliere quello!

Altre crittografie scoraggiate o deprecate includono DES, 3DES e IDEA. RFC 5469 afferma che l’uso di DES e IDEA non è raccomandato (e li rimuove ufficialmente da TLS 1.2, sebbene alcune implementazioni possano ancora supportarli).

DES è stato sostituito da AES nel 2002 e ufficialmente ritirato nel 2005. Il suo utilizzo in TLS è stato effettivamente deprecato nel 2009. Questa RFC rilasciata nel 2009 descriveva DES come “noto per essere vulnerabile agli attacchi di forza bruta pratica da oltre 20 anni”.

In breve, dovresti disabilitare le crittografie deprecate e sconsigliate, incluse le crittografie DES, IDEA, 3DES, RC2, RC4, IDEA, ARIA, SEED e NULL. Questo potrebbe lasciarti solo con AES e ChaCha20, abilitati, tuttavia AES è ampiamente supportato e attualmente si ritiene che offra un elevato livello di sicurezza. La ricerca ha dimostrato che ChaCha20 offre un livello di sicurezza simile a AES ma è più veloce su alcune CPU (come quelle che non dispongono dell’estensione del set di istruzioni AES-NI).

Autenticazione e controllo dell’integrità

Infine, TLS include un controllo di autenticazione e integrità di solito tramite un HMAC, anche se, ove possibile, è preferibile un algoritmo AEAD (che è crittografia autenticata con dati associati e suite di crittografia come TLS_AES_256_GCM_SHA384).

Per l’autenticazione e il controllo dell’integrità potresti vedere algoritmi come HMAC-MD5 e HMAC-SHA1 e vedrai molta documentazione online che parla di come MD5 e SHA1 non sono sicuri – e lo sono, ma qui c’è un’importante distinzione: molti degli attacchi documentati contro MD5 e SHA1 attaccano la sua resistenza alle collisioni, che è meno importante in questo contesto poiché l’algoritmo viene utilizzato come parte di un HMAC.

Nella maggior parte delle applicazioni pratiche, in TLS non dovrebbero essere utilizzate suite di cifratura che utilizzano MD5 o SHA1, in parte perché le opzioni della suite di cifratura che utilizzano questi algoritmi sono sconsigliate per altri motivi. Ad esempio, TLS_RSA_WITH_RC4_128_SHA dovrebbe essere disabilitato a causa della mancanza di forward secrecy e dell’uso dell’algoritmo di crittografia rotto RC4. Quindi, se sei alle prese con il fatto che HMAC-SHA1 sia davvero così male, disabilita semplicemente la suite e usa qualcosa di più sicuro.

TL;DR

  • Disabilita tutte le versioni di SSL
  • Disabilita TLS 1.0 e TLS 1.1 a favore di TLS 1.2 e versioni successive
  • Prendi in considerazione l’abilitazione di TLS 1.3
  • Disattiva le suite di cifratura che utilizzano l’autenticazione anonima
  • Disattiva gli algoritmi di scambio di chiavi che non supportano la “forward secrecy”, come RSA, a favore di alternative più sicure come Diffie-Hellman Ephemeral e Elliptic Curve Diffie-Hellman Ephemeral
  • Disabilita tutte le crittografie deboli, scoraggiate e deprecate, quali DES, 3DES, RC2, RC4 e NULL a favore di algoritmi più sicuri come AES e ChaCha20
  • Prendi in considerazione la possibilità di disabilitare le suite di cifratura che utilizzano algoritmi non ampiamente supportati, come IDEA, ARIA e SEED.
  • Disattiva le suite di cifratura che utilizzano modalità di cifratura deboli come CBC a favore di opzioni più sicure come CCM e GCM
  • Disattiva algoritmi di autenticazione deboli come HMAC-MD5 e HMAC-SHA1 a favore di alternative più sicure come HMAC-SHA384 o algoritmi AEAD come AES-GCM

Quindi, se pretendi solo la compatibilità con i client moderni, dovresti abilitare solo TLS 1.3 con solo le seguenti crittografie:

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256
  • TLS_CHACHA20_POLY1305_SHA256

Se hai bisogno di compatibilità con client legacy, come Windows XP o Android 4 aggiuntive all’elenco sopra indicato:

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA26
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-CHACHA20-POLY1305
  • ECDHE-RSA-CHACHA20-POLY1305
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • DHE-RSA-CHACHA20-POLY1305

Configurazioni

Apache

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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305

Nginx 

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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;

Riferimenti

EOF

Lascia un commento