Quale versione del protocollo SSL/TLS sarebbe meglio usare?

Versioni protocollo SSL / TLS

Le librerie SSL / TLS e le applicazioni che le utilizzano consentono all’amministratore di limitare le versioni di SSL / TLS consentite, solitamente come parte della configurazione di protezione avanzata. Cinque versioni di SSL / TLS sono ampiamente supportate nel codice della libreria: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 e TLS 1.2. Tutte queste versioni sono interessate da almeno un problema di sicurezza che richiede una soluzione alternativa o una configurazione speciale da evitare e le prime due contengono gravi difetti che non possono essere risolti senza compromettere la compatibilità. Descriviamo brevemente la cronologia delle diverse versioni di SSL / TLS e mostriamo come ognuno di essi può o non può essere utilizzato in modo sicuro oggi se configurato correttamente.

Protocollo 	Azione
SSL 2.0 	disattivare
SSL 3.0 	disattivare
TLS 1.0 	Disabilita quando possibile
TLS 1.1 	Abilitare
TLS 1.2 	Abilitare

Configurazione consigliata per ciascuna versione di SSL / TLS.

SSL 2.0 è stato rilasciato nel 1995. Contiene numerosi difetti di progettazione che non possono essere risolti senza rompere il protocollo e potrebbero portare all’esposizione o alla modifica di dati riservati. SSL 2.0 non dovrebbe mai essere usato su Internet moderno. Quando viene rilevato oggi, SSL 2.0 è solitamente abilitato in seguito a un incidente o a una configurazione predefinita debole.

Risultato: disabilitare SSL 2.0 senza tener conto della compatibilità con le versioni precedenti.

SSL 3.0 è stato rilasciato nel 1996 come re-design completo. L’ attacco POODLE di Google sfrutta le funzionalità di scripting del browser e l’implementazione del padding non funzionante in SSL 3.0 per lanciare attacchi man-in-the-middle, che potrebbero portare all’esposizione o alla modifica di dati riservati [2] . Due soluzioni alternative potrebbero consentire a SSL 3.0 di rimanere in uso durante la risoluzione di POODLE:

Disabilitare tutte le suite di crittografia in modalità CBC quando comunicano con un client SSL 3.0; i codici di flusso non usano il padding e quindi non sono vulnerabili. Sfortunatamente, l’unico cifrario non CBC ampiamente supportato, RC4, è suscettibile di ulteriori problemi di sicurezza.
Una nuova suite di pseudo-cipher recentemente aggiunta a TLS, TLS_FALLBACK_SCSV , aiuta a rilevare gli attacchi di downgrade per resistere ai tentativi di un utente malintenzionato di obbligare una vittima a eseguire il downgrade a SSL 3.0 [3] . Al momento della stesura di questo documento (inizio 2015), TLS_FALLBACK_SCSV non è ancora supportato universalmente e i client che lo supportano sono comunque in grado di supportare TLS 1.0.

Per i motivi indicati, si consiglia di disabilitare SSL 3.0 anziché fare affidamento su una di queste soluzioni alternative.

Fino al 2014 molti server pubblici continuavano a supportare SSL 3.0 per compatibilità con le versioni precedenti, nonostante la sua sostituzione da parte di TLS quindici anni prima. Questo trade-off è ora inaccettabile alla luce della vulnerabilità irreversibile di POODLE. La disabilitazione di SSL 3.0 garantisce che il software non possa essere configurato in modo errato per utilizzarlo e che gli autori di attacchi non possano forzare il downgrade di un client e di un server.

Risultato: disabilitare SSL 3.0 senza tenere conto della compatibilità con le versioni precedenti.

TLS 1.0 è stato rilasciato nel 1999 come revisione di SSL 3.0. Tra le modifiche al protocollo c’era un nuovo schema di riempimento e, di conseguenza, TLS 1.0 non è vulnerabile all’attacco di POODLE quando il padding TLS è in uso.

Tuttavia, TLS 1.0 è vulnerabile all’attacco BEAST , che sfrutta le capacità e i punti deboli di scripting del browser nell’utilizzo dei vettori di inizializzazione utilizzati durante la crittografia con un codice a blocchi in modalità CBC [4] . BEAST può essere risolto senza interrompere il protocollo TLS 1.0 in due modi:

Disabilitare tutte le suite di crittografia in modalità CBC; i codici stream non sono vulnerabili. Sfortunatamente, l’unico cifrario non CBC ampiamente supportato, RC4, è suscettibile di ulteriori problemi di sicurezza.
Modificare le librerie client e server TLS per aggiungere un “tocco” al modo in cui il software comunica, chiamato “insert empty fragments”.

Se TLS 1.0 deve essere supportato, si consiglia di verificare che sia il client che il server seguano la soluzione alternativa di “inserimento di frammenti vuoti” anziché passare a RC4.

Molti server continuano a supportare TLS 1.0 per la compatibilità con le versioni precedenti, in quanto alcuni software ampiamente distribuiti non supportano versioni successive di TLS (ad esempio, Windows XP, Windows Server 2003, OpenSSL 0.9.8), mentre altri software, incluso Mozilla Firefox, non implementare TLS 1.1 fino a molti anni dopo la sua introduzione nel 2006. Gli utenti di TLS 1.0 che desiderano utilizzare soluzioni alternative anziché interrompere il supporto devono essere diligenti nel garantire che le loro librerie TLS siano aggiornate e configurate correttamente. Consigliamo agli utenti di eseguire l’aggiornamento, a meno che uno specifico problema di compatibilità con le versioni precedenti non precluda la disabilitazione di TLS 1.0.

Risultato: disabilitare TLS 1.0; riattivare in caso di problemi di compatibilità con le versioni precedenti.

TLS 1.1 è stato rilasciato nel 2006 come revisione di TLS 1.0. Tra le modifiche al protocollo c’è un nuovo schema di generazione di IV; quindi, TLS 1.1 non è suscettibile a BEAST.

Mentre gli attacchi sono stati lanciati con successo contro specifiche funzionalità di TLS 1.1, come compressione (CRIME) e rinegoziazione, esistono soluzioni alternative che non interrompono la compatibilità del protocollo. Nota: questi problemi influenzano anche TLS 1.2.

Gli utenti di TLS 1.1 dovrebbero essere diligenti nell’assicurare che le loro librerie TLS siano aggiornate e configurate correttamente per abilitare i workaround di sicurezza in base alle migliori pratiche attuali (ad esempio, disabilitando la compressione e abilitando la soluzione alternativa per la rinegoziazione di RFC 5746).

Risultato: abilita TLS 1.1.

TLS 1.2 è stato rilasciato nel 2008 come revisione di TLS 1.1. Al momento, non è necessario eseguire l’aggiornamento da TLS 1.1 a 1.2 in risposta a eventuali vulnerabilità conosciute e sfruttabili, ma TLS 1.2 introduce funzionalità utili quali suite di crittografia GCM a prestazioni più elevate e una funzione pseudocasuale basata su SHA-256. Le suite di crittografia GCM utilizzano anche la crittografia autenticata, in sostituzione del tradizionale schema Encrypt-then-Authenticate di TLS.

Gli utenti di TLS 1.2 dovrebbero essere diligenti nel garantire che le loro librerie TLS siano aggiornate e configurate correttamente per abilitare i workaround di sicurezza in base alle migliori pratiche attuali (ad esempio, disabilitando la compressione e abilitando la soluzione alternativa alla rinegoziazione di RFC 5746).

Risultato: abilita TLS 1.2.

Cipher Suites

I protocolli SSL / TLS sono stati progettati per essere estensibili e modulari, consentendo di modificare i protocolli di autenticazione server / client, scambio di chiavi, crittografia e integrità dei messaggi (MAC) senza sostituire l’intero protocollo. Le suite di crittografia più recenti utilizzano RSA, ECDH o ECDSA per l’autenticazione, ECDHE per lo scambio delle chiavi, AES per la crittografia e GCM per l’integrità, ma esiste anche un gran numero di suite di crittografia compatibili con precedenti e versioni precedenti. Abbiamo suddiviso le suite di crittografia in tre categorie: quelle che dovrebbero essere sempre abilitate per la massima sicurezza possibile, quelle che possono essere attivate se lo si desidera per la compatibilità e quelle che dovrebbero essere sempre disabilitate a causa di problemi di sicurezza.

Suite Cipher consigliate

Gli amministratori dovrebbero essere sicuri di abilitare le seguenti suite di crittografia.

Suite di crittografia ECDH / DH AES. Queste n

uove suite di crittografia utilizzano Elliptic-Curve Diffie Hellman (ECDH) e Diffie-Hellman (DH) per lo scambio di chiavi. A differenza delle vecchie suite di crittografia che utilizzano RSA statico basato sulla chiave pubblica del server per questo scopo, il traffico ECDH / DH catturato passivamente non può essere decifrato, anche se la chiave privata del server viene compromessa in seguito. Questa funzione è nota come segretezza in avanti .

Suite di crittografia AES. Le semplici suite di crittografia AES vengono utilizzate dai client che non supportano le suite di crittografia ECDH / DH o che sono disabilitate.

Un modo rapido per specificare solo le suite di crittografia basate su AES mentre richiede i certificati RSA, ECDH o ECDSA per l’autenticazione del server, quando si utilizza OpenSSL, è: AES+aRSA:AES+aECDH:AES+aECDSA . I moderni processori x86 supportano la crittografia AES e AES / GCM con accelerazione hardware. Questa funzionalità consente alle suite di crittografia AES di offrire sia prestazioni elevate che una solida sicurezza.

Suite di crittografia facoltative o non comuni

Le librerie SSL / TLS supportano comunemente molti altri cifrari e schemi di autenticazione, come le suite di crittografia Camellia, Triple-DES e SEED; e Kerberos, chiave già condivisa e schemi di autenticazione DSS. Mentre al momento attuale, non ci sono attacchi noti contro questi algoritmi, in genere possono essere disabilitati senza alcuna conseguenza di compatibilità. La disattivazione delle funzionalità non necessarie nelle librerie di sicurezza fondamentali aiuta anche a ridurre la superficie di attacco.

Suite Cipher deboli o spezzate

I seguenti tipi di suite di crittografia sono deboli o danneggiati e devono sempre essere disabilitati.

Cifra nullo. Il codice NULL (eNULL) non esegue alcuna crittografia e dovrebbe essere utilizzato solo per il test o il debug.

Esportare cifre di grado. Queste suite di crittografia obsolete sono state utilizzate quando le restrizioni all’esportazione degli Stati Uniti hanno limitato la forza crittografica a 40 bit (oltre 56). La maggior parte delle restrizioni pertinenti sono state revocate nel 2000, quindi non sono necessarie per tutti i software attuali e sono troppo deboli contro gli attacchi di forza bruta.

Cifre anonime Mentre SSL / TLS utilizza quasi sempre certificati per dimostrare l’identità di un server, questo non è richiesto quando si utilizza una suite di crittografia anonima (di solito disabilitata di default a livello di applicazione, ad esempio mod_ssl o IIS).

Suite di crittografia basate su MD5. Molte suite di crittografia meno recenti utilizzavano un algoritmo MAC basato su MD5 per rilevare le modifiche ai dati crittografati. L’algoritmo MD5 ha dimostrato di essere debole e suscettibile alle collisioni; inoltre, alcune suite di crittografia MD5 utilizzano crittografie con punti deboli noti, come RC2, che vengono automaticamente disabilitate evitando MD5.

Suite di crittografia RC4. L’algoritmo di scheduling chiave del cifrario RC4 è debole in quanto i primi byte di output possono essere correlati con la chiave. Questa debolezza è stata utilizzata in alcuni attacchi contro Wired Equivalent Privacy (WEP), il primo standard di crittografia per reti Wi-Fi 802.11, con risultati catastrofici. Sebbene SSL / TLS non sia vulnerabile o sfruttabile con le stesse tecniche del WEP, la debolezza sottostante in RC4 esiste comunque, ei ricercatori di sicurezza di Microsoft e di altre aziende ora raccomandano che sia disabilitato.

Questo consiglio potrebbe sorprendere molti professionisti IT, poiché una delle raccomandazioni immediate alla vulnerabilità di BEAST solo pochi anni fa era quella di disabilitare tutti i cifrari tranne RC4. Tuttavia, le migliori pratiche attuali indicano che RC4 stesso dovrebbe essere disabilitato.

Futuro

TLS 1.3 è, al momento della stesura, attualmente in fase di sviluppo e apporta modifiche sostanziali al protocollo rispetto alle revisioni precedenti; infatti, è la revisione più significativa del protocollo da SSL 3.0. In un’inversione dalla pratica precedente, molte caratteristiche di compatibilità debole o retrocompatibile, come RC4, compressione e autenticazione RSA statica, vengono proposte per essere eliminate da TLS 1.3. Quando viene distribuito TLS 1.3, gli amministratori dovrebbero implementare il supporto quando possibile. In particolare, quando i client e i server migrano a TLS 1.3, non saranno più necessari soluzioni temporanee e hardening.

Sorveglianza NSA: una guida per rimanere al sicuro

traduzione a cura di googletranslate da un articolo su The guardian scritto dal crittologo
Bruce Schneier

Ora che abbiamo abbastanza dettagli su come la NSA intercetta di nascosto su Internet, comprese le rivelazioni odierne del deliberato indebolimento dei sistemi crittografici della NSA, possiamo finalmente iniziare a capire come proteggerci.

Nelle ultime due settimane, ho lavorato con il Guardian alle storie della NSA e ho letto centinaia di documenti NSA top secret forniti dal denunciatore Edward Snowden. Non facevo parte della storia di oggi – era in corso ben prima di presentarmi – ma tutto ciò che ho letto conferma ciò che il Guardian sta riportando.

A questo punto, sento di poter dare qualche consiglio per proteggermi da un simile avversario.

Il modo principale in cui la NSA intercetta di nascosto sulle comunicazioni Internet è nella rete. È qui che le loro capacità si adattano meglio. Hanno investito in enormi programmi per raccogliere e analizzare automaticamente il traffico di rete. Tutto ciò che richiede loro di attaccare i singoli computer endpoint è significativamente più costoso e rischioso per loro, e lo faranno con cautela e con parsimonia.

Sfruttando i suoi accordi segreti con le compagnie di telecomunicazione – tutti gli Stati Uniti e il Regno Unito, e molti altri “partner” in tutto il mondo – l’NSA ottiene l’accesso ai tronchi delle comunicazioni che spostano il traffico Internet. Nei casi in cui non ha quel tipo di accesso amichevole, fa del suo meglio per monitorare segretamente i canali di comunicazione: toccando i cavi sottomarini, intercettando le comunicazioni via satellite e così via.

Si tratta di un’enorme quantità di dati e l’NSA ha capacità equivalenti enormi per passare rapidamente a tutto, alla ricerca di traffico interessante. “Interessante” può essere definito in molti modi: dalla fonte, dalla destinazione, dal contenuto, dagli individui coinvolti e così via. Questi dati sono incanalati nel vasto sistema NSA per analisi future.

La NSA raccoglie molti più metadati sul traffico internet: chi sta parlando con chi, quando, quanto, e con quale modalità di comunicazione. I metadati sono molto più facili da archiviare e analizzare rispetto ai contenuti. Può essere estremamente personale per l’individuo ed è un’intelligenza enormemente preziosa.

La Direzione Sistemi Intelligence è responsabile della raccolta dei dati e le risorse che dedica a questo sono sconcertanti. Leggo il rapporto sullo stato dopo il rapporto sullo stato di questi programmi, discutendo le capacità, i dettagli operativi, gli aggiornamenti pianificati e così via. Ogni singolo problema – recuperare i segnali elettronici dalla fibra, stare al passo con i flussi di terabyte, filtrare le cose interessanti – ha un gruppo dedicato a risolverli. La sua portata è globale.

La NSA attacca anche i dispositivi di rete direttamente : router, switch, firewall, ecc. La maggior parte di questi dispositivi ha funzionalità di sorveglianza già integrate ; il trucco sta nel surrettiziamente accenderli. Questa è una via d’attacco particolarmente fruttuosa; i router vengono aggiornati meno frequentemente, tendono a non installare software di sicurezza su di essi e vengono generalmente ignorati come vulnerabilità.

L’NSA dedica inoltre notevoli risorse per attaccare i computer degli endpoint. Questo tipo di cose è fatto dal suo gruppo TAO – Tailored Access Operations . TAO ha un menu di exploit che può servire contro il tuo computer, che tu stia utilizzando Windows, Mac OS, Linux, iOS o qualcos’altro, e una varietà di trucchi per metterli sul tuo computer. Il tuo software anti-virus non li rileverà e avresti problemi a trovarli anche se sapessi dove cercare. Si tratta di strumenti di hacker progettati dagli hacker con un budget sostanzialmente illimitato. Quello che ho tolto dalla lettura dei documenti di Snowden è che se l’NSA vuole entrare nel tuo computer.

L’NSA si occupa di tutti i dati crittografati che incontra di più sovvertendo la crittografia sottostante piuttosto che facendo leva su eventuali scoperte matematiche segrete. Innanzitutto, c’è un sacco di cattiva crittografia là fuori. Se trova una connessione Internet protetta da MS-CHAP, ad esempio, è facile interrompere e recuperare la chiave. Sfrutta le password utente scelte male, utilizzando lo stesso dizionario che gli hacker utilizzano nel mondo non classificato.

Come è stato rivelato oggi , la NSA lavora anche con i venditori di prodotti di sicurezza per garantire che i prodotti di crittografia commerciale siano infranti in modi segreti che solo loro conoscono. Sappiamo che questo è successo storicamente: CryptoAG e Lotus Notes sono gli esempi più pubblici, e ci sono prove di una porta di servizio in Windows . Alcune persone mi hanno raccontato alcune storie recenti sulle loro esperienze e ho intenzione di scrivere presto su di loro. Fondamentalmente, l’NSA chiede alle aziende di cambiare sottilmente i loro prodotti in modi non rilevabili: rendendo il generatore di numeri casuali meno casuale, perdendo la chiave in qualche modo, aggiungendo un esponente comune a un protocollo di scambio a chiave pubblica, e così via. Se viene scoperta la porta sul retro, viene spiegata come un errore. E come ora sappiamo, la NSA ha avuto enorme successo da questo programma.

TAO si infiltra anche nei computer per recuperare le chiavi a lungo termine. Quindi se stai usando una VPN che usa un complesso segreto condiviso per proteggere i tuoi dati e la NSA decide che se ne importa, potrebbe provare a rubare quel segreto. Questo tipo di cose viene fatto solo contro obiettivi di alto valore.

Come si comunica in modo sicuro contro un simile avversario? Snowden lo ha detto in una sessione di domande e risposte online subito dopo aver reso pubblico il suo primo documento: “La crittografia funziona. I potenti sistemi crittografici correttamente implementati sono una delle poche cose su cui potete fare affidamento.”

Credo che questo sia vero , nonostante le rivelazioni odierne e le allettanti accenni di ” capacità pseudoanalitiche innovative ” fatte da James Clapper, il direttore dell’intelligence nazionale in un altro documento top-secret. Queste capacità implicano deliberatamente un indebolimento della crittografia.

La frase successiva di Snowden è altrettanto importante: “Sfortunatamente, la sicurezza degli endpoint è così terribilmente debole che la NSA può spesso trovare dei modi per aggirarla.”

Endpoint indica il software che stai utilizzando, il computer su cui lo stai utilizzando e la rete locale in cui lo stai utilizzando. Se l’NSA può modificare l’algoritmo di crittografia o rilasciare un Trojan sul computer, tutta la crittografia in il mondo non ha importanza. Se si vuole rimanere al sicuro contro la NSA, è necessario fare del proprio meglio per garantire che la crittografia possa operare senza impedimenti.

Con tutto questo in mente, ho cinque consigli:

1) Nascondere nella rete . Implementa servizi nascosti. Usa Tor per anonimizzare te stesso. Sì, l’NSA si rivolge agli utenti di Tor, ma è lavoro per loro. Meno sei ovvio, più sei sicuro.

2) Cripta le tue comunicazioni . Utilizza TLS. Usa IPsec. Anche in questo caso, mentre è vero che l’NSA prende di mira le connessioni criptate – e potrebbe avere exploit espliciti contro questi protocolli – tu sei molto più protetto che se comunichi in chiaro.

3) Supponiamo che mentre il tuo computer può essere compromesso, ci vorrebbe lavoro e rischi da parte dell’NSA – quindi probabilmente non lo è . Se hai qualcosa di veramente importante, usa un traferro. Da quando ho iniziato a lavorare con i documenti Snowden, ho acquistato un nuovo computer che non è mai stato collegato a Internet. Se voglio trasferire un file, crittografo il file sul computer sicuro e lo passo sul mio computer internet, usando una chiavetta USB. Per decifrare qualcosa, inverto il processo. Questo potrebbe non essere a prova di proiettile, ma è abbastanza buono.

4) Diffidare del software di crittografia commerciale, in particolare dai grandi fornitori . La mia ipotesi è che la maggior parte dei prodotti di crittografia di grandi aziende statunitensi abbia backdoor amichevoli della NSA, e anche molti stranieri lo fanno. È prudente presumere che anche i prodotti stranieri abbiano backdoor installate all’estero. Il software closed-source è più facile per la NSA di backdoor rispetto al software open-source. I sistemi che si affidano a segreti segreti sono vulnerabili alla NSA, attraverso mezzi legali o più clandestini.

5) Prova a utilizzare la crittografia del dominio pubblico che deve essere compatibile con altre implementazioni . Ad esempio, è più difficile per NSA TLS backdoor rispetto a BitLocker, perché TLS di qualsiasi fornitore deve essere compatibile con TLS di tutti gli altri fornitori, mentre BitLocker deve essere compatibile solo con se stesso, dando all’NSA molta più libertà di apportare modifiche. E poiché BitLocker è proprietario, è molto meno probabile che tali modifiche vengano scoperte. Preferisci crittografia simmetrica su crittografia a chiave pubblica. Preferire sistemi convenzionali basati su log discreti su sistemi a curva ellittica; questi ultimi hanno delle costanti che l’NSA influenza quando possono.

Da quando ho iniziato a lavorare con i documenti di Snowden, ho utilizzato GPG , Silent Circle , Tails , OTR , TrueCrypt , BleachBit e alcune altre cose di cui non ho intenzione di scrivere. C’è una funzione di crittografia non documentata nel mio programma Password Safe dalla riga di comando); Ho usato anche quello.

Capisco che la maggior parte di questo è impossibile per il tipico utente di Internet. Anche io non uso tutti questi strumenti per quasi tutto ciò su cui sto lavorando. E io sono ancora principalmente su Windows, sfortunatamente. Linux sarebbe più sicuro.

La NSA ha trasformato il tessuto di Internet in una vasta piattaforma di sorveglianza, ma non sono magici. Sono limitati dalle stesse realtà economiche di tutti noi, e la nostra migliore difesa è rendere la sorveglianza di noi il più costosa possibile.

Fidati della matematica. La crittografia è tua amica. Usalo bene e fai del tuo meglio per assicurarti che nulla possa comprometterlo. È così che puoi rimanere sicuro anche di fronte alla NSA.

Certificati di sicurezza Letsencrypt

Criptiamo tutto!

Tutti i nostri servizi richiedono criptografia SSL/TLS.
Non ho mai visto di buon occhio gli enti commerciali che offrono certificati di criptografia.
Un elemento importante come la sicurezza, che inizia con un rapporto di figucia tra me e il cliente, non puo essere messo nelle mani di terze parti il cui unico scopo è il profitto.
Prima di letsencrypt ero solito creare manualmente una Cetification Authority.

Questo comportava, pero’, la necessita’, per gli utenti, di seguire una procedura un po complicata per installare il certificato della CA. E la sua cattiva implementazione è un messaggio di errore ben noto sui nostri browser.

Let’s Encrypt è, infatti, una autorità di certificazione che si propone di rilasciare certificati gratuitamente, semplificando notevolmente l’intero processo per l’ottenimento dei certificati stessi.
Tramite una serie di semplici operazioni, ed utilizzando un client apposito, è infatti possibile abilitare il supporto ad HTTPS su un web server, gestendo facilmente tutto ciò che riguarda l’uso dei certificati.

Let’s Encrypt è un importante passo verso quel concetto di criptografia semplice ed usufruibile da chiunque.
L’idea che sta alla base di Let’s Encrypt è particolarmente innovativa: oltre ad azzerare i costi per ottenere facilmente un web server sicuro, consente anche di generare i certificati in maniera estremamente semplice e rapida.

Essendo ancora in fase beta, non ci resta che aspettare di vedere cosa riserverà il futuro per questo progetto, che sembra molto promettente e che potrebbe contribuire a migliorare significativamente la sicurezza delle trasmissioni HTTP e non solo.