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.

Come collegarsi con pidgin su jabber.tcpreset.net

Pidgin un programma per jabber

Potete scaricare ed installare pidgin dal sito.

Si consiglia di installare Pidgin utilizzando lo strumento di gestione dei pacchetti standard del vostro sistema Linux.
Su distribuzioni Debian GNU/Linux installiamo pidgin e il plugin otr in questo modo:
:~$ sudo apt-get update && sudo apt-get install pidgin pidgin-otr

Pidgin è comunque disponibile anche per piattaforma Windows, pidgin-2.12.0.exe.

Per dispositivi Android vi consiglio Xabber.

Invece per Mac OS X consiglio vivamente di utilizzare Adium.

Creiamo un account su jabber.tcpreset.net

Una volta fatto partire pidgin clicchiamo su accounts/manage-accounts/add.
Inseriamo i valori richiesti.

  • Protocol: XMPP
  • Username: il nome da te desiderato
  • Domain: jabber.tcpreset.net
  • Password: l@TuaP4ssw0rd

Opzionali sono i valori relativi all’alias e all’icona da utilizzare.
Metti la spunta nel box in basso dove dice di creare il nuovo account sul server.

Configuriamo OTR

  • Una volta registrato su jabber.tcpreset.net nella finestra principale di pidgin va su tools e poi su plugins.
  • Seleziona il plugin OTR (Off-The-Record-Messaging) poi in basso clicca su configura plugin.
  • Seleziona il tuo account dalla lista [key for account] e clicca su Generate appena sotto.
  • Inoltre nelle opzioni presenti in “Default OTR Settings” abiliti il private messaging, rendi obbligatorio l’utilizzo di otr (opzionale) e c’è anche la possibilita’ di non scrivere gli eventi su disco rigido

Adesso pidgin è pronto ad avere conversazioni criptografate con otr, end to end.

Quando iniziate una conversazione cliccate su PRIVATE e seguite le istruzioni per autenticare il vostro interlocutore (Buddy) .
Il metodo piu semplice per autenticare qualcuno e dichiarare di possedere il FINGEPRINT.
Nel mio caso questo: 6DFD1450 70993851 8CB504FA 677C6169 1A1AC57C 😉

Pidgin+TOR

Prima di proseguire nell’utilizzare tor, andiamo prima in Accounts sul menu in alto e poi su Manage Account.

Nella sezione “Advanced“, imposta quanto segue:

  • Connection Security: Require encryption
  • Connect Port: 5222
  • Connect Server: jabber.tcpreset.net
  • File Transfer Proxies: proxy.riseup.net

Fatto questo, adesso puoi collegarti a xmpp://jabber.tcpreset.net/ utilizzando Tor.

Il di sopra indirizzo è anche disponibile come hidden service nel onion network, contattatemi per istruzioni. ;)

Per collegarti al nostro indirizzo nascosto, dunque, è necessario utilizzare Tor.
Clicca sul tab che riguarda il Proxy sul menu in alto in pidgin.

Qui è dove inserisci l’indirizzo locale 127.0.0.1 che è anche l’indirizzo dove tor sulla porta 9050 (tipo Socks5) ascolta per connessioni in ingresso.

Buon divertimento & enjoy tcpreset.net.

Secure your Secure Shell

Perfect forward secrecy è una proprietà dei protocolli di negoziazione delle chiavi che assicura che se una chiave di cifratura a lungo termine viene compromessa, le chiavi di sessione generate a partire da essa rimangono riservate.

Scambio chiavi
Con SSH abbiamo due modi per scambiare chiavi in modo sicuro tra server e client, uno è il Diffie-Hellman, l’altro è Elliptic Curve Diffie-Hellman.
Entrambi offrono PFS ed entrambi sono odiati dall’ NSA proprio per questa ragione.

OpenSSH supporta 11 protocolli di scambio di chiavi:

  1. curve25519-sha256 : ECDH su Curve25519 con SHA2
  2. diffie-hellman-group1-sha1 : 1024 bit DH con SHA1
  3. diffie-hellman-group14-sha1 : 2048 bit DH con SHA1
  4. diffie-hellman-group14-sha256 : 2048 bit DH con SHA2
  5. diffie-hellman-group16-sha512 : 4096 bit DH con SHA2
  6. diffie-hellman-group18-sha512 : 8192 bit DH con SHA2
  7. diffie-hellman-group-exchange-sha1 : Custom DH con SHA1
  8. diffie-hellman-group-exchange-sha256 : Custom DH con SHA2
  9. ecdh-sha2-nistp256: ECDH su NIST P-256 con SHA2
  10. ecdh-sha2-nistp384: ECDH su NIST P-384 con SHA2
  11. ecdh-sha2-nistp521: ECDH su NIST P-521 con SHA2

Per la scelta della curva ECDH da questo listato dobbiamo osservare tre cose:
Da questa lista eliminiamo subito le ultime tre curve in quanto di proprieta’ del NIST e a noi il NIST non piace in quanto progetta di proposito algoritmi vulnerabili.

1024bit è una dimensione troppo piccola per il modulo DH quindi scartiamo anche il 2 e il 7.

Il modulo sha1 è un modulo pieno di bug, per la funzione hash useremo sha2. Quindi dal di sopra listato scarteremo anche il 3 oltre a quelli gia precedentemente messi da parte.

Curve25519 è il migliore e basterebbe anche da solo ma c’è il rischio di non essere compatibili con clients tipo winscp ed eclipse quindi includiamo anche 4,6 e 8.
Possiamo aggiungerli al file di configurazione di SSH in questo modo:

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Autenticazione
Lo scambio di chiavi garantisce che il server e il client condividano un segreto che nessun altro conosce. Dobbiamo anche assicurarci che condividano questo segreto l’uno con l’altro e non con un analista dell’NSA.
Per l’autenticazione esistono 4 algoritmi a chiave pubblica:

  1. DSA con SHA1
  2. ECDSA con SHA256, SHA384 o SHA512
  3. Ed25519 con SHA512
  4. RSA con SHA1

Le chiavi DSA non sono mai piu grandi di 1024bit, troppo poco, le scartiamo.
ECDSA sono del NIST e anche loro vanno disabilitate. Esse utilizzano la casualita’ per ogni firma quindi se la casualita’ non è il pezzo forte di questo algoritmo, loscartiamo.
RSA anche se utilizza sha1 non è un problema, quindi andremo ad aggiungere questa riga al nostro file di configurazione di ssh:

Protocol 2 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key

Questo disabiliterà anche il protocollo v1 terribilmente rotto che non dovresti aver abilitato in primo luogo. Dovremmo rimuovere le chiavi non utilizzate e generare solo una grande chiave RSA e una chiave Ed25519. Gli script di init possono ricreare le chiavi non utilizzate. Se non lo desideri, rimuovi i comandi ssh-keygen dallo script di init.

cd /etc/ssh rm ssh_host_*key* ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Autenticazione client
Il client deve dimostrare la propria identità anche al server. Ci sono vari metodi per farlo.

La più semplice è l'autenticazione della password. Questo dovrebbe essere disabilitato immediatamente dopo aver impostato un metodo più sicuro perché consente ai server compromessi di rubare le password. L'autenticazione tramite password è anche più vulnerabile agli attacchi bruteforce online.
Disabilitiamola sia sul server che sul client:

PasswordAuthentication no ChallengeResponseAuthentication no

Il metodo più comune e sicuro è l'autenticazione a chiave pubblica, sul server aggiungiamo:

PubkeyAuthentication yes

Genera chiavi client usando i seguenti comandi:

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100

È possibile distribuire le nuove chiavi pubbliche del client utilizzando ssh-copy-id.
È anche possibile utilizzare l'autenticazione OTP per ridurre le conseguenze delle password perse. Google Authenticator è una buona implementazione di TOTP o password One Time Timeed . Puoi anche utilizzare un elenco stampato di password singole o qualsiasi altro modulo PAM , in realtà, se abiliti ChallengeResponseAuthentication.

Cifrari simmetrici
I cifrari simmetrici vengono utilizzati per crittografare i dati dopo il primo scambio di chiavi e l'autenticazione è completa.
Qui abbiamo alcuni algoritmi (10-14 sono stati rimossi in OpenSSH 7.6 ):

  1. 3des-cbc
  2. AES128-CBC
  3. AES192-CBC
  4. AES256-CBC
  5. AES128-ctr
  6. AES192-ctr
  7. AES256-ctr
  8. aes128-gcm@openssh.com
  9. aes256-gcm@openssh.com
  10. arcfour
  11. arcfour128
  12. arcfour256
  13. blowfish-cbc
  14. CAST128-CBC
  15. chacha20-poly1305@openssh.com

Dobbiamo considerare quanto segue.
Per la Sicurezza dell'algoritmo, essendo sia DES che RC4 completamente bacati li escludiamo, quindi 1,10 e 12 via!
Le dimensioni della chiave almeno 128bit.
Le dimensioni del blocco devono anche esse essere di almeno 128bit quindi eliminiamo 13 e 14 perchè di 64.
Per la modalita' di cifratura preferiamo quelli che supportano AE, authenticated encryption.

La crittografia autenticata ( AE ) o la crittografia autenticata con i dati associati ( AEAD ) è una forma di crittografia che fornisce simultaneamente garanzie di riservatezza , integrità e autenticità sui dati. Questi attributi sono forniti in un'unica interfaccia di programmazione facile da usare.

Facoltivamente consentiremo CTR per questioni di retro compatibilita'. CTR con Encrypt-then-MAC è provabilmente sicuro.

Chacha20-poly1305 è preferito su AES-GCM perché il protocollo SSH non crittografa le dimensioni dei messaggi quando GCM è in uso. Ciò consente alcune analisi del traffico anche senza decifrare i dati. Ci occuperemo presto di questo.

Aggiungiamo quanto segue sia sul server che sul client:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Codici di autenticazione dei messaggi
La crittografia fornisce riservatezza , il codice di autenticazione dei messaggi garantisce l' integrità . Abbiamo bisogno di entrambi. Se è selezionata una modalità di cifratura AE, non vengono utilizzati MAC aggiuntivi, l'integrità è già fornita. Se è selezionato CTR, allora abbiamo bisogno di un MAC per calcolare e allegare un tag ad ogni messaggio.
Esistono diversi modi per combinare cifrari e MAC: non tutti sono utili. I 3 più comuni:

  1. Encrypt-then-MAC : crittografa il messaggio, quindi collega il MAC del testo cifrato.
  2. MAC-then-encrypt : collega il MAC del testo in chiaro, quindi crittografa tutto.
  3. Encrypt-and-MAC : crittografa il messaggio, quindi collega il MAC del testo in chiaro.

Utilizzare solo Encrypt-then-MAC.
In caso di Encrypt-then-MAC, il MAC è verificato e, se errato, scartato. In caso di MAC-then-encrypt, prima il messaggio fornito dall'hacker deve essere decodificato e solo dopo puoi verificarlo. L'errore di decrittografia richiede meno tempo rispetto a un errore di verifica.
Ecco le scelte MAC disponibili:

  1. HMAC-MD5
  2. hmac-MD5-96
  3. HMAC-SHA1
  4. hmac-sha1-96
  5. hmac-sha2-256
  6. hmac-sha2-512
  7. UMAC-64
  8. UMAC-128
  9. hmac-md5-etm@openssh.com
  10. hmac-md5-96-etm@openssh.com
  11. hmac-sha1-etm@openssh.com
  12. hmac-sha1-96-etm@openssh.com
  13. hmac-sha2-256-etm@openssh.com
  14. hmac-sha2-512-etm@openssh.com
  15. umac-64-etm@openssh.com
  16. umac-128-etm@openssh.com

Sicurezza dell'algoritmo hash : No MD5 e SHA1.
Encrypt-then-MAC : non sono a conoscenza di una prova di sicurezza per CTR-and-HMAC. Dato che non ci sono su CTR attacchi di downgrade possiamo aggiungerli alla fine della lista per retrocompatibilita'.
Dimensione tag : almeno 128 bit. Questo elimina umac-64-etm.
Dimensione della chiave almeno 128 bit.

Aggiungiamo al file di configurazione di SSH quanto segue sia per il client che per il server:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Openvpn 2.4

AEAD (GCM)

Openvpn 2.4 è l’ultima versione del software per tunnel criptati.
Con la nuova versione molte sono le novita’:

  • IP e porta mobile
  • Negoziazione della cifratura del canale dati
  • Supporto per la crittografia del canale dati con AEAD (GCM)
  • Scambio di chiavi ECDH
  • Connette ai clients DNS Dualstack round-robin
  • Supporto per la fornitura di server DNS IPv6
  • redirect-gateway ipv6
  • Compressione e supporto LZ4
  • Http proxy password all’interno del file di configurazione
  • Token di autenticazione
  • Client di gestione portachiavi per Mac OS X.
  • Supporto per piattaforma Android
  • Supporto piattaforma AIX
  • Controllo della crittografia del canale

E’ da un po che aspetto Openvpn 2.4 .
Le precedenti versioni non supportavano propriamente il concetto di Perfect Forward Secrecy.

Il cifrario di default era AES-256-CBC in modalita’ CBC appunto.
Infatti GCM fornisce sia criptografia che controllo di integrita’, mentre CBC solo criptografia.

Per questo in modalita’ GCMnon vedrai mai crittografare due volte con lo stesso hash della stessa chiave e questo protegge dai replay attacks.

Gli sviluppatori hanno sempre preferito la retrocompatibilita’ con quante piu’ applicazioni client possibile, spesso di vecchia generazione, a discapito della sicurezza.

Openvpn 2.4 è un software che utilizzo tantissimo e il supporto per protocolli di crittografia avanzati di tipo ellittico per la crittografia è, finalmente, default.

Configurazione

 

Configureremo un sistema debian stretch con Openvpn 2.4 e openssl-1.0.2j.

E’ mia intenzione fornire il livello di sicurezza piu alto possibile per i dati in transito, per gli utenti e per il server stesso, iniziamo.

Innanzitutto configuriamo il forwarding sulla nostra vpnbox con qualche comando iptables e qualche modifica a etc/sysctl.conf, il file dove è possibile apportare modiche al kernel, al tcp/ip stack, alla virtual memory e quant’altro, senza riavviare la nostra vpnbox, on the fly.

Grazie ad iptables utilizzeremo il NAT che permettera’ ai clients della vpn di collegarsi alla rete pubblica.


-P FORWARD DROP
-A FORWARD -s 10.1.0.0/24 -i tun0 -o eth0 -j ACCEPT
-A FORWARD -d 10.1.0.0/24 -i eth0 -o tun0 -j ACCEPT
# nat/masquerade
-t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j MASQUERADE
# in etc/sysctl.conf abilitiamo il forwarding per i clients
net.ipv4.ip_forward = 1

Adesso impostiamo la porta di asolto, il protocollo, l’interfaccia di rete utilizzata, nel nostro caso tun0 e l’ip che l’interfaccia virtuale della nostra vpn utilizzera’.


port 4343
proto udp
dev tun0
server 10.1.0.0 255.255.255.0

Per il numero di porta ho scelto un valore diverso dal default 1192.

TCP o UDP ?

Tcpreset.net ai suoi clienti offre entrambi i protocolli.

A proposito di questo argomento il protocollo UDP resta quello consigliabile in termini di velovita’ proprio perchè piu’ semplice del TCP.

Il protocollo TCP garantisce la consegna dei dati implementando meccanismi di controllo e di rinvio dei dati stessi, operazione che richiede il suo tempo.

L’UDP, al contrario, invia i dati in rete e poi se ne disinteressa.

Per questo motivo è molto usato nello streaming di audio e video dove è necessaria molta velocita’ e anche nella risoluzione dei nomi di dominio con il DNS.

La direttiva Server definisce quale numerazione e classe di ip la nostra vpn utilizzera’ per sè e i clients.

La vpnbox avra’ ip 10.1.0.1 sulla sua interfaccia di rete, mentre un pool di 254 indirizzi ip sara’ a disposizione dei clients che la utilizzeranno.

Routing

Inoltre dovremmo dire ad Openvpn 2.4 il routing che avranno i clients.
Utilizzando la classe di ip privati dai quali i clients provengono, impostiamo il routing:


# Routing
client-config-dir /etc/openvpn/ccd/client1
route 192.168.1.0 255.255.255.0
# nel file etc/openvpn/ccd/client1 con iroute definiamo che classe di ip client1 fa parte.
iroute 192.168.1.0 255.255.255.0

Poi impostiamo altri parametri che riguardano vari aspetti della connessione e sono dei buoni defaults.


keepalive 10 120
compress lz4
max-clients 60
tun-mtu 1500
persist-key
persist-tun

Vi consiglio di consultare il manuale disponibile sul sito ufficiale di Openvpn per i dettagli ;).

Certificati SSL con criptografia efemerale a curve ellittiche

 

Adesso creeremo i certificati necessari alla nostra VPN.
Il modo piu’ facile per impostare una CA è scaricare il pacchetto easyrsa v3.0.5.

$ git clone https://github.com/OpenVPN/easy-rsa.git easy-rsa/.

E’ mia intenzione utilizzare EC (curve ellittiche) per i certificati SSL di questo server invece di RSA.

Utilizzero’ il massimo in quanto a sicurezza che la criptografia a curve ellittiche ha da offrire con Openvpn 2.4.
Edita il file vars in questo modo:


set_var EASYRSA "$PWD"
set_var EASYRSA_OPENSSL "/usr/local/openssl/bin/openssl"
set_var EASYRSA_PKI "$EASYRSA/pki"
set_var EASYRSA_DN org
set_var EASYRSA_REQ_COUNTRY "US"
set_var EASYRSA_REQ_PROVINCE "California"
set_var EASYRSA_REQ_CITY "San Francisco"
set_var EASYRSA_REQ_ORG "Copyleft Certificate Co"
set_var EASYRSA_REQ_EMAIL "me@example.net"
set_var EASYRSA_REQ_OU "My Organizational Unit"
# Cetificati a curve ellittiche (y)
set_var EASYRSA_ALGO ec
# definiamo quali curve ellittiche usare
set_var EASYRSA_CURVE brainpoolP512r1
# Scadenza certificati della CA
set_var EASYRSA_CA_EXPIRE 365
set_var EASYRSA_CERT_EXPIRE 365
set_var EASYRSA_CRL_DAYS 365
# Cryptographic digest to use.
set_var EASYRSA_DIGEST "sha512"

Inizializiamo la PKI.


./easyrsa init-pki

Creiamo la CA.


./easyrsa build-ca

Generiamo una richiesta di certificato ed una chiave privata per il server.

./easyrsa gen-req server somename nopass

Firma il certificato

./easyrsa sign-req somename

Creiamo il certificato per gli utenti.

./easyrsa gen-req client1

Firmiamolo,

./easyrsa sign-req client1

Sul server adesso andiamo a specificare il path per certificati e chiave privata:


ca /etc/openvpn/EasyRSA-3.0.3/pki/ca.crt
cert /etc/openvpn/EasyRSA-3.0.3/pki/issued/vpn.server.crt
key /etc/openvpn/EasyRSA-3.0.3/pki/private/vpn.server.key

Sempre sul server andiamo a definire tutti i parametri per una connessione che usa esclusivamente TLSv1.2 e cifrari AEAD(GCM) che garantiscono perfect forward secrecy.

Cifrari

Vediamo di quali cifrari Openvpn 2.4 dispone.

Abbiamo detto che vogliamo solo quelli che supportano crittografia a curve ellittiche e vogliamo solo i cifrari piu’ forti, 256bit possono bastare.

root@VPN:# openvpn --show-ciphers | grep 256-GCM
AES-256-GCM (256 bit key, 128 bit block, TLS client/server mode only)

Risulta che Openvpn 2.4 con i suddetti criteri dispone di AES-256-GCM che e’ il nuovo cifrario di default per Openvpn 2.4 e sostituisce Blowfish BF-CBC (64bit).

Aggiungiamolo al file di configurazione:

cipher AES-256-GCM

Piu’ cifrari utilizziamo piu’estesa sara’ la gamma di applicazioni clients che sara’ in grado di connettersi alla nostra vpnbox.
Se ques

to puo essere considerato un bene in realta’ ci costringe all’uso di protocolli insicuri e deboli, inoltre offre a qualche maleintenzionato una superfice maggiore da attaccare.


root@VPN ~ # openvpn --show-tls | grep 256-GCM
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

Vediamo che i cifrari adesso sono tre stando alle caratteristiche da noi ricercate. Con Openvpn 2.4 è stato ridotto il numero di cifrari di default in tls-cipher.

E’ molto facile che un uso incorretto dei cifrari provochi degli errori nella connessione e inoltre meno cifrari ci sono e minori saranno le possibilita’ di bersaglio durante un attacco .

Qualsiasi sia il cifrario da voi scelto, il client, nel suo file di configurazione, deve contenere i medesimi cifrari del server.
Aggiungiamo al file di configurazione i cifrari disopra mostrati,

tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

ed anche,


ncp-ciphers AES-256-GCM
ecdh-curve brainpoolP512r1

Ncp-cipehrs è una nuova opzione in Openvpn2.4.
Sta ad indicare che è possibile negoziare il cifrario che cripta il data channel. Ma per noi non ci puo’ essere alcuna negoziazione, AES-256-GCM come unica opzione.

ecdh-curve stabilisce invece quale curva ellittica usare.

Noi useremo brainpoolP512r1 che è considerato safe dal sito safecurves.cr.yp.to.

Autenticazione

L’autenticazione al momento è gestita unicamente con il buon vecchio PAM.

E’ in fase di allestimento un sistema d’autenticazione 2FA con google-authenticator.

Sicurezza

 

Openvpn2.4 supporta i migliori algoritmi di sicurezza.
Ammenochè tu non abbia per qualche motivo specifico bisogno di ultilizzare SSLv3,TLSv1 o TLSv1.1, essi vanno disabilitati in quanto insicuri e va utilizzato solo il protocollo TLSv1.2 e lo facciamo con questa direttiva:


tls-version-min 1.2

Un altra novita’ per Openvpn2.4 è la direttiva tls-crypt che è un upgrade del precedente tls-auth.

Crittografando il canale di controllo viene criptato anche il certificato utilizzato nella connessione TLS.

Quindi è anche più difficile determinare che si tratta di una connessione vpn dopo un packet inspection.

In conclusione la nostra vpn sara’ in esecuzione con l’utente non privileggiato nobody.

Andiamo ad aggiungere al file di configurazione le seguenti direttive:


user nobody
group nogroup

Queste sono alcune delle direttive implementate sulla vpn da me offerta.

Per ulteriori approfondimenti vi invito a consultare il sito di riferimento vpn.tcpreset.net [WORK IN PROGRESS]

Qualora fosse vostra intenzione usufruire della vpn da me offerta, per qualsiasi chiarimento, consulenza, sia per utilizzo privato che businness, alla pagina contatti tutti i dettagli.