Nel post precedente abbiamo messo su un server OpenVPN, avendo cura di portare le stesse chiavi usate dal server sul client. Ma come ho detto nello scorso post, questa e’ una cattiva pratica per un dispositivo mobile, perche’ chi venisse in possesso del dispositivo potrebbe, in linea teorica, (recuperando la password della chiave privata) simulare il vostro server. Da quel momento, il rischio che qualcuno si sostituisca al server stesso sarebbe troppo alto. Dunque, adesso andiamo a creare certificati ad hoc per il client.
Per prima cosa: nel caso io smarrisca il cellulare o, peggio, un malware mi porti via le chiavi, di quanto aumenta la mia sicurezza rispetto al caso di prima?
Di fatto, avendo quelle chiavi , diciamo “lato client” e il certificato “cacert” , non possono ancora sostituirsi al server, ma possono pur sempre entrare nella vostra VPN: per questa ragione, pero’, esiste un meccanismo abbastanza ingegnoso, che e’ la revoca della firma digitale. Ma andiamo avanti, per capire.
Prima di iniziare c’e’ una cosa: un lettore mi ha scritto dicendo che su una versione di PF, su FreeBSD, scrivendo vpnnet= $vpn_if:network non si ottiene la rete collegata alla tun0, perche’ e’ una connessione ppp. Quindi, dovrete specificare a mano la rete, tipo vpnnet= “192.168.3.128/255.255.255.128” .
Detto questo, andiamo al punto. Nello scorso post abbiamo creato alcuni certificati ed una cacert, cioe’ il certificato di una CA, una certification authority. La domanda cioe’, e’ : ma se il cellulare usa i suoi certificati selfsigned, come fa il server a sapere che siano “suoi”?
La risposta e’ che tali certificati verranno certificati, e verranno certificati usando la Certification Authority di cui abbiamo, appunto, creato il certificato.
Nella puntata precedente abbiamo:
- openssl genrsa -des3 -out key.pem 2048
- openssl req -new -x509 -key key.pem -out cacert.pem -days 365
- openssl req -new -key key.pem -out server.csr
- openssl x509 -req -days 365 -in server.csr -signkey key.pem -out cert.pem
- openssl dhparam -out dh.pem 2048
Nella 1) abbiamo creato una chiave. Lo so, ci avete messo un pochino. Ma e’ esattamente cosi’ che deve essere, quindi va bene che ci abbiate messo un sacco di tempo. Nella 2) abbiamo creato un certificato che certifica l’identita’ del certificatore, ovvero abbiamo istituito una specie di ufficio anagrafe. Nella 3) invece abbiamo creato una RICHIESTA di certificato , cioe’ un certificato che non certifica nulla perche’ nessuno lo ha firmato. Avete presente quando vi dicono che un documento non vale perche’ “manca un timbro?”. Ecco, quel certificato, il .csr , e’ una carta di identita’, ma senza la firma del sindaco e il timbro dell’anagrafe.
Chiaramente, adesso bisogna farla firmare dall’anagrafe. Sfortunatamente, pero’, quella non e’ la carta di identita’ giusta: abbiamo creato un certificato usando la chiave del server, e la chiave e’ un pochino come la foto nella vostra carta di identita’. Se volete certificare qualcosa, dovete proprio metterci la vostra, di foto.
Allora, ricominciamo daccapo. Cosa dobbiamo certificare? Diciamo un cellulare samsung. Allora iniziamo col creare una chiave per il samsung, poi crediamo una richiesta di certificato usando quella chiave, e infine ci mettiamo la firma del “sindaco”:
- openssl genrsa -des3 -out samsung.pem 2048
- openssl req -new -key samsung.pem -out samsung.csr
- openssl x509 -req -days 365 -in samsung.csr -CA cacert.pem -CAkey key.pem -CAcreateserial -out samsung.pem
qui abbiamo fatto cose diverse:
- Abbiamo creato una chiave privata ad hoc per il cellulare, cosi’ non ci dobbiamo mettere la stessa del server.
- Abbiamo creato una richiesta di certificato, ovvero una carta di identita’ senza la firma del sindaco e dell’anagrafe.
- Abbiamo poi certificato la richiesta, facendone un vero certificato, ovvero una cosa che certifica l ‘identita’ di qualcuno.
Adesso torniamo un attimo indietro ed andiamo alla configurazione di OpenVPN:
- ca certs/cacert.pem
- cert certs/cert.pem
- key certs/key.pem
- dh certs/dh.pem
che cosa significa la prima riga in rosso? Significa che il nostro server OpenVPN accettera’ anche altri certificati , A PATTO CHE SIANO CERTIFICATI dalla Certification Authority , il cui certificato e’ contenuto in cacert.pem Non importa che non siano generati con la stessa chiave privata, questo e’ un problema di chi richiede il certificato. In linea teorica, il certificato dal lato client viene generato da un’altra parte, alla CA viene inviata solo la richiesta di certificato, e la chiave privata del client rimane sul client.
Ed e’ per questo che adesso abbiamo creato dei certificati per il samsung, ma li abbiamo fatti firmare dalla CA accettata dal server.
Adesso, che cosa dovete portare sul cellulare? Dovete portare:
- La cacert.pem , cioe’ la certification authority (ma SOLO il certificato: nessuna chiave!)
- Il file samsung.key, che contiene la chiave privata del client.(ma SOLO quella del client)
- Il file samsung.pem, che contiene il certificato dedicato per il cellulare (ma SOLO quello!)
questi sono gli UNICI tre file di cui avete bisogno. Gli altri NON devono trovarsi sul cellulare.
Fatto questo, non dovete fare altro che riprendere in mano il cellulare, TOGLIERE i certificati di prima, che da ora in avanti staranno SOLO sul server, e usare questi tre files per stabilire la VPN.
Cosa succede se vi fregano il cellulare? Se lo fanno, succedera’ che le credenziali (e la certification authority) caschino nelle mani del delinquente. Ma:
- Quel certificato di CA non puo’ essere usato per creare altri certificati, perche’ sul cellulare MANCA la CHIAVE associata alla CA (-CAkey key.pem sopra) , e quindi il nostro criminale non ne viene in possesso.
- La chiave del Samsung ha bisogno di una password, che vi e’ stata chiesta quando avete generato la chiave. Se l’avete scritta nel client perche’ siete pigri, allora quel cellulare puo’ ancora entrare nella VPN con quelle credenziali.
quindi, dobbiamo revocare quelle credenziali.
Per fare questo, prima creeremo un file per i certificati revocati, csr, e poi spiegheremo a openVPN di controllare che i certificati non siano stati revocati. Lo facciamo dentro la stessa cartella dove stanno gli altri certificati.
- echo “1000” >> index.txt
- openssl ca -gencrl -keyfile key.pem -cert cacert.pem -out revoked.crl -crldays 366
Il file index.txt servira’ per avere una lista rapida dei certificati annullati.
a quel punto aggiungiamo alla configurazione di OpenVPN la richiesta di controllare che i certificati siano revocati:
crl-verify certs/revoked.crl
Adesso possiamo revocare il certificato del samsung:
- openssl ca -revoke samsung.pem -keyfile key.pem -cert cacert.pem
Se tutto va bene e avete eseguito il comando dentro la directory certs, adesso anche il file index.txt dovrebbe essere stato aggiornato. Adesso avete revocato il vostro certificato, ma dovete ficcarlo dentro il contenitore di crl, di certificati malvagi.
Per farlo, ridiamo il comando che abbiamo usato per generare il file dei certificati malvagi la prima volta.
- openssl ca -gencrl -keyfile key.pem -cert cacert.pem -out revoked.crl -crldays 366
e a questo punto , verra’ generata una nuova crl con il certificato annullato dentro, e riavviando openvpn, da quel momento il certificato apparira’ come revocato e non potra’ piu’ accedere.
Ovviamente, dopo la prima volta, soltanto gli ultimi due comandi saranno necessari per revocare un certificato, e il fatto che abbiamo indicato una durata di 366 giorni, sicuramente superiore alla durata del certificato stesso (che avevamo messo a 365) , ci da’ la sicurezza che la nostra lista di certificati malvagi scadra’ dopo il certificato malvagio, e non saremo mai in rete “scoperti”.
E se un malware vi frega le chiavi e tutto a vostra insaputa? Otterrete che qualcuno possa collegarsi alla vostra VPN. Questo e’ un male dal momento che dentro c’e’ il vostro tessssooro e voi ci tenete un sacco al vostro anello.
Allora, avete ancora il comando del vostro server. Il quale logga: tra parentesi, ricordate di ruotare i log di openvpn, se non volete trovarvi il disco pieno. Quindi, per esempio, potreste dare un’occhiatina ai log di accesso.
Oppure, se avete solo un cellulare da collegare, come me, potete agire sulla configurazione di OpenVPN, e rimuovere la voce:
-
duplicate-cn
a questo punto, se state collegati H24, non c’e’ nessun altro che potra’ ricollegarsi, perche’ NON accettera’ due volte le stesse credenziali.
Adesso andiamo alla vexata quaestio: ma la VPN deve uscire su internet? Molti di voi stanno usando la tecnologia VPN (cioe’ il tunnel IPsec) allo scopo di creare un proxy IP, che nasconda l’indirizzo originale del chiamante.
Non ho voglia di discutere la parziale inutilita’ di questa misura in un mondo ove mega e mega di javascript girano sul vostro browser, ma il punto e’ un altro. Usare una tecnologia tipica delle VPN, il tunnel IPsec, per ottenere un proxy IP non fa una VPN. Fa un IP proxy.
VPN e’ una Rete PRIVATA Virtuale. “Privata” significa “privata”. Per quanto i fanatici del non- network splitting siano numerosi, una VPN che esce verso internet e’ uno stupido IP Proxy, ma non stiamo parlando di una VPN. VPN aperta ad internet e’ come dire “Carro Armato Cabrio”, o “Bunker Sotterraneo con Veranda sul Mare”: potete farla, ma poi non vi lamentate se avete costruito una cosa diversa da quella che credevate, e vi ritrovate con un falso senso di sicurezza.
In generale quando siete in una VPN siete nel vostro bunker sotterraneo. Non parlate con l’esterno, se non attraverso degli intermediari, che comunque devono impedire il contatto. Quindi certo, quando siete in vpn e leggete la posta la leggete da una macchina che la scarica con fetchmail, ma lo fa seguendo un altro percorso, che NON e’ un percorso attraverso il quale si possa entrare nella VPN. Insomma, nel bunker potete avere il telefono, a patto che dai fili non ci passino le persone.
