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.