home Ricerca per tag "sicurezza"


HTTPS, cos'è e come funziona

L'ultimo articolo riguardante la sicurezza sul web risale a qualche mese fa ed abbiamo deciso di riprendere l'argomento per parlarvi di HTTPS, che da qualche giorno è stato abilitato anche qua su L'angolo nerd. Per molti di voi potrebbe suonare familiare, sicuramente vi sarà già capitato di leggerlo sulla barra degli indirizzi del browser quando navigate su siti come Facebook, Google, Twitter o YouTube, accompagnato da un piccolo lucchetto chiuso. Ma cos'è questo HTTPS? HTTPS sta per HyperText Transfer Protocol over Secure Socket Layer e si tratta di un protocollo per l'invio di informazioni attraverso la rete, proprio come HTTP, ma più sicuro. Giusto per rifilarvi una carrellata di informazioni nerd, il protocollo HTTPS utilizza la porta 443 al posto della usuale porta 80 di HTTP ed un sistema basato su SSL/TLS per cifrare le informazioni scambiate tra il client (voi) ed il server (L'angolo nerd, ad esempio). In particolare, SSL (Secure Sockets Layer) e TLS (Transmission Layer Security) sono altri due protocolli, che vengono utilizzati per garantire la cifratura dei pacchetti inviati tramite rete Internet. Ok, tutto molto bello, ma perchè usare HTTPS?L'utilizzo del protocollo HTTPS garantisce una maggiore sicurezza permettendo lo scambio di dati cifrati tra client e server, evitando quindi attacchi del tipo man-in-the-middle o eavesdropping, mediante il quale l'attaccante, che si trova "a metà" tra voi e il server, potrebbe intercettare le informazioni inviate.Più precisamente, HTTPS NON blocca questi tipi di attacchi, semplicemente li rende inutili. Attraverso il protocollo HTTP standard infatti i dati vengono passati in plain text, ossia non cifrati, permettendo quindi al malintenzionato di scovare facilmente ad esempio il vostro username e la vostra password. Questi dati possono essere intercettati comunque anche se inviati tramite HTTPS, ma risulteranno cifrati, di conseguenza illeggibili. Come funziona HTTPS?HTTPS è basato sul sistema delle chiavi pubbliche e private (trattato nell'articolo sulla crittografia). L'amministratore di un server Web che vuole adottare questa protezione per la connessione dall'esterno al suo server deve prima creare un certificato a chiave pubblica che dovrà poi essere firmato da un'Autorità di Certificazione (CA), un ente pubblico o privato abilitato a rilasciare certificati digitali conformi agli standard internazionali.Nel caso in cui il certificato creato per un server Web non fosse stato firmato il browser ci avviserà che il sito a cui vorremmo connetterci non è sicuro. Ma cerchiamo di capire meglio come funziona questo sistema delle chiavi pubbliche e private. Queste due chiavi sono legate da un calcolo matematico, tipicamente il prodotto di due numeri primi molto (molto molto) grandi, in modo che sia impossibile risalire a quella privata disponendo solo di quella pubblica. Per mandare un messaggio al server basterà cifrarlo utilizzando la sua chiave pubblica, così che solo il server stesso, attraverso la sua chiave privata potrà decifrarlo. Dopo aver messo a punto i dettagli tecnici da utilizzare per il trasferimento, come ad esempio la versione degli algoritmi di protocollo o di cifratura, il browser procederà quindi alla cifratura di una chiave generata in loco con la chiave pubblica del server, per poi connettersi con questo e inviare tale chiave. Terminato questo passaggio la connessione tra il client e il server sarà sicura e procederà con la stessa chiave, che verrà utilizzata per cifrare e decifrare il flusso dei dati. In conclusione è interessante dare uno sguardo alle debolezze e alle limitazioni di questo tipo di comunicazione.Innanzitutto, se un utente malintenzionato rubasse il certificato con la chiave privata di un server che usa HTTPS, sarebbe possibile per lui creare e firmare falsi certificati per qualsiasi dominio a cui far connettere gli utenti senza che loro se ne accorgano. Inoltre, con l'implementazione di HTTPS su un server Web, verranno inviati più dati rispetto che con una normale connessione HTTP. Ciò comporta quindi un volume di traffico più alto, con una conseguente velocità di navigazione ridotta. Ma allora perché non usare il protocollo HTTPS solo sulla pagina di login? Tutti avrete sentito parlare dei Cookie, che essenzialmente sono righe di testo utilizzate per l'autenticazione automatica, quel meccanismo che permette ad esempio di non dover inserire username e password ogni volta che si accede a Facebook o Google. Username e password sarebbero quindi al sicuro perchè cifrati, ma che dire di questi cookie? Questi invece rimarrebbero in chiaro, senza alcun tipo di cifratura, il che renderebbe inutile cifrare i dati al momento del login. Per questo è necessario che la connessione rimanga cifrata per tutta la sua durata, dall'inizio alla fine.

L'evoluzione di Keybase, smartphone e chat a portata di click

Circa due mesi fa abbiamo parlato di Keybase e abbiamo visto come sia possibile verificare la propria identità e quella dei nostri amici online e di come memorizzare e scambiare documenti cifrati in totale comodità attraverso questo servizio. Keybase è un progetto giovane ed in continuo sviluppo, basti pensare che fino a pochi mesi fa non esistevano nè KBFS, nè l'applicazione per pc, ma il suo team di programmatori sembra non arrestarsi mai. Dall'ultima volta che ne abbiamo parlato infatti è stata rilasciata l'applicazione mobile, disponibile gratuitamente sia per Android che per iOS, che, proprio come per la versione Desktop, permette di comunicare in modo cifrato e sicuro con qualsiasi altro membro della community. [ Immagine presa dal Play Store in quanto, per questioni di sicurezza, all'interno dell'applicazione non è possibile effettuare screenshot ] A differenza di quest'ultima però, da mobile non è ancora possibile navigare tra i propri documenti, ma è disponibile un servizio di messaggistica completo. Oltre alla crittografia end-to-end infatti sarà possibile raggiungere una determinata persona attraverso lo username di uno qualsiasi dei suoi profili social collegati, senza dover inserire nè email nè numero di telefono. Inoltre, per una maggior sicurezza, essendo lo smartphone uno strumento più soggetto a furti rispetto ad un pc, la passphrase verrà richiesta ad ogni apertura dell'applicazione. L'altra grande novità arriva sotto forma di estensione per Chrome e permette di effettuare chat private e cifrate con gli utenti Keybase direttamente dai loro profili social. Infatti, una volta installata, su ogni profilo Facebook, Twitter, Reddit, Hacker News e tutti quelli supportati dalla piattaforma, sarà disponibile un tasto blu che permettereà di iniziare una chat con quella persona. Nel caso quest'ultima non fosse iscritta a Keybase, sarà comunque possibile inviarle messaggi cifrati, facendo notare al destinatario che sarà necessario iscriversi al portale per poterli leggere. Sulla documentazione ufficiale è disponibile inoltre una piccola sezione F.A.Q. che ne descrive in breve il funzionamento, puntualizzando che Keybase non è in grado di leggere i messaggi inviati poichè cifrati end-to-end (il che assicura che i messaggi inviati possano essere letti solo da te e dalla persona con cui stai comunicando) e descrivendone la sicurezza trattandosi semplicemente di un'estensione che delega la cifratura e l'invio del messaggio all'app installata sul pc. 

Git, GPG e la firma dei Commit

Qualsiasi hosting per repository Git, che sia GitHub, GitLab, Bitbucket o altro, richiede l'inserimento di una password o la presenza di una chiave - se si usa SSH - al momento del push di qualsiasi modifica effettuata. Ma allora perchè dovrei addirittura firmare i miei commit con una chiave PGP? Di fatto, una persona con sufficienti privilegi è in grado di modificare qualsiasi commit o, addirittura, compromettere il nostro account ed effettuare modifiche a nostro nome. In questi casi la certezza assoluta - a meno che non sia il nostro PC ad essere compromesso [1] - si ha solo attraverso la firma dei commit effettuati. Se pensate che tutto ciò sia un po' da paranoici probabilmente avete ragione, ma vi consiglio di dare una lettura a questa Git Horror Story scritta da Mike Gerwitz. Detto questo vediamo ora come firmare i nostri commit di Git utilizzando gpg (o gpg2), presenti nei repository ufficiali di Debian e Ubuntu. Per chi non avesse mai utilizzato uno di questi due tool sarà necessario prima di tutto generare una nuova coppia di chiavi attraverso il comando gpg2 --gen-key. Il programma chiederà dunque di inserire il vostro nome reale, l'email a cui associare le nuove chiavi e una passphrase che verrà richiesta al momento dell'utilizzo della chiave. È importante assicurarsi che l'indirizzo email inserito sia lo stesso con cui siete iscritti al servizio online - ad esempio GitHub - in caso contrario i vostri commit non verranno considerati verificati sulla piattaforma. Una volta generate dovreste ottenere una schermata simile a quella qui sopra. Utilizziamo quindi l'ID della coppia appena generata (gli ultimi 8 caratteri), nel nostro caso ECD810FF, per esportare la chiave pubblica attraverso il comando gpg2 --armor --export ECD810FF e copiamo tutto il blocco di testo risultante, comprese le righe contententi -----BEGIN PGP PUBLIC KEY BLOCK----- e -----END PGP PUBLIC KEY BLOCK-----. Restano soltanto due passaggi per ultimare il procedimento, il caricamento della chiave sul nostro profilo GitHub e la configurazione locale di Git. Per quanto riguarda il primo passo basterà accedere a GitHub e inserire una nuova chiave GPG in Settings > SSH and GPG keys. Passiamo ora alla configurazione di Git. Ci serviremo dell'ID della chiave per specificare a Git quale utilizzare per firmare i commit attraverso il comando git config --global user.signingkey ECD810FF. Per firmare il commit sarà quindi sufficiente aggiungere il parametro -S a git commit, ad esempio git commit -S -m "Woah! A signed commit!". N.B. Nel caso in cui dovessimo ricevere un errore del tipo  gpg: saltato "ECD810FF": la chiave segreta non è disponibilegpg: signing failed: la chiave segreta non è disponibileerror: gpg non è riuscito a firmare i datifatal: scrittura dell'oggetto di commit non riuscita Sarà necessario specificare il programma per la gestione delle chiavi attraverso il comando git config --global gpg.program "gpg2" (sostituendo gpg2 con il tool utilizzato). Allo stesso modo per firmare tag e release sarà sufficiente utilizzare il comando git tag -s nometag. Chiaramente è possibile verificare le firme attraverso il parametro -v per i tag e --show-signature per i commit. git log --show-signature ci mostrerà quindi la history del repository mettendo in risalto i commit firmati. È inoltre possibile effettuare merge "controllati" attraverso il parametro --verify-signatures, vale a dire che il comando git merge --verify-signatures verrà eseguito solo se tutte le modifiche risulteranno firmate.  Infine possiamo rendere totalmente automatica la procedura per la firma di commit e tag , in modo da poterci dimenticare di aggiungere i parametri -S e -s nei comandi. Per far questo basterà aggiungere un'ulteriore configurazione a Git attraverso il comando git config --global commit.gpgsign true. [Screenshot e comandi per la guida sono stati effettuati su una repository di test raggiungibile qui] [1] In questo caso non avete altra scelta che piallare il PC e stare più attenti la prossima volta.

KBFS, il cloud sicuro

Nell'articolo precedente abbiamo visto Keybase e le funzionalità social che offre. Abbiamo anche accennato a KBFS, che sta per Keybase Filesystem ed in questo articolo andremo a vedere di cosa si tratta e del perchè risulta essere un'alternativa davvero innovativa ai più comuni servizi di cloud. Il servizio di KBFS è integrato nell'applicazione per PC di Keybase e, come le altre funzionalità della suite, è utilizzabile sia da riga di comando che in modalità grafica. Per semplicità possiamo pensarlo come una sorta di Dropbox, che appare sulla nostra macchina come una cartella dentro la quale possiamo caricare file e documenti. A differenza di questi servizi però non esiste un modello di sincronizzazione, vale a dire che non dovremo scaricare tutti i file in locale per poterli gestire, ma verranno scaricati solo al momento dell'apertura. Un'altra differenza è la gerarchia delle sottocartelle in cui ci imbattiamo. Questo perchè lo spazio a nostra disposizione è logicamente suddiviso in un'area pubblica e una privata. Al fine di descrivere le funzionalità di KBFS utilizzerò il mio username sul sistema, aroblu94. Detto questo i nostri due spazi personali saranno raggiungibili rispettivamente a /keybase/public/aroblu94/ e /keybase/private/aroblu94/. Cominciamo vedendo nello specifico le funzionalità della cartella pubblica. Tutto quello che andremo a inserire qui verrà infatti firmato con la nostra chiave in modo automatico e reso disponibile a tutti gli utenti Keybase comodamente in chiaro. Lo scopo di questa funzionalità è quella di poter condividere determinati file in modo sicuro, dando al tempo stesso la certezza a chi li preleva o visualizza che si tratta di file non manomessi al momento del download. La firma infatti serve proprio a questo, è un po' come dire "Questo file è autentico e funzionante, potete scaricarlo da qui senza temere che possa essere stato modificato". In aggiunta a questo la vostra cartella pubblica funge da webroot, permettendovi di caricarci al suo interno un "minisito". Basterà infatti la presenza di un file index, che sia .html, .md o quant'altro, per poterlo raggiungere ad un indirizzo del tipo https://aroblu94.keybase.pub. Allo stesso modo è possibile raggiungere le cartelle pubbliche di qualsiasi utente Keybase, utilizzando sia il loro username sulla piattaforma, che gli username di qualsiasi altro social network collegato. Vale a dire che il contenuto della cartella /keybase/public/aroblu94/ può essere raggiunto ad esempio anche come /keybase/public/aro94@twitter/ /keybase/public/aroblu94@reddit/ /keybase/public/aroblu94@github/ Vediamo ora le funzionalità dell'area privata di keybase. Allo stesso modo ci sarà una cartella /keybase/private/aroblu94/. Tutti i file che vengono caricati qui sono cifrati e accessibili solo a noi stessi, solamente da macchine che sono state verificate. Per poter usare KBFS infatti sarà necessario aggiungere il PC alla lista dei device verificati del nostro account. Ovviamente non possiamo raggiungere le cartelle private degli altri utenti come facevamo con quelle pubbliche, è possibile però creare delle cartelle condivise tra utenti. Se volessi infatti scambiare dei documenti in modo sicuro con Daniele e Niccolò - gli altri due membri de L'angolo nerd -, sarà sufficiente creare una cartella aroblu94,theloker,nicokant sotto /keybase/private/. Sempre grazie alla connessione bi-direzionale tra i profili collegati ad ogni account Keybase è possibile utilizzare lo username Twitter, GitHub o quello che preferiamo per collegarci con una persona. Per quanto riguarda la sicurezza dell'intero sistema bisogna ricordare che i server Keybase non memorizzano alcuna chiave privata e di conseguenza non possono leggere i file caricati in /keybase/public/, mentre conoscono - ovviamente - il contenuto di quelli pubblici. Keybase inoltre conosce ulteriori metadata quali la cartella modificata, la data di modifica/accesso e - approssimativamente - la quantità di dati scambiati, fermandosi però all'altezza di /keybase/private/{cartella}/, senza conoscere invece file e sottocartelle all'interno, come possiamo leggere nella citazione seguente presa dalla documentazione di Keybase: The Keybase servers can obviously read everything in /keybase/public. As for /keybase/private, Keybase can tell (1) what top level folders you're working in (such as /keybase/private/aroblu94,pal), (2) when you're writing and reading data, and (3) approximately how much data. The Keybase server does not know individual file names or subdirectory names. It could try to guess whether you're writing 100 small files or 1 large file, but it would be a timing-based guess. If you write a 1MB file in a private folder called /keybase/private/aroblu94/pics_of_me/thong.jpg, the Keybase server has no idea this is a folder called pics_of_me, or that there's a file called thong.jpg, or whether you look good. It doesn't know you're writing pictures, Excel docs, your DNA sequence, or mp3's. Per ulteriori informazioni sui meccanismi di sicurezza adottati in Keybase Filesystem vi rimando alla documentazione ufficiale.

Keybase, la crittografia si fa social

In un mondo sempre più incentrato su internet la sicurezza online e la protezione dei dati personali sono argomenti all'ordine del giorno.  Ed è proprio la crittografia che permette, attraverso particolari funzioni matematiche, di "offuscare" i nostri dati rendendoli illeggibili da chiunque altro fuorchè noi e il server che ci eroga il servizio desiderato, che sia Google, Facebook o chiunque altro. Questo processo avviene in modo automatico e senza un nostro intervento nel momento in cui viene stabilita la connessione, ma è importante ricordare che in rete non tutti i dati vengono cifrati. Il caso più comune è quello delle email in cui, nella maggior parte dei casi, il contenuto viene inviato in chiaro. E se volessimo cifrare dei messaggi, in modo da essere sicuri che solo il destinatario possa leggerli? Uno dei metodi tutt'ora più utilizzati passa attraverso PGP, un sistema di crittografia basato su una coppia di chiavi per ogni utente, che permette ad entrambe le parti in comunicazione di essere sicuri che il messaggio arrivi dalla persona giusta senza essere stato nè manomesso nè letto dal cosiddetto man-in-the-middle [1]. Ogni coppia di chiavi è quindi associata ad un indirizzo email e sul web si trovano moltissimi database e siti con l'obiettivo di raccogliere le chiavi pubbliche degli utenti rendendo più comoda la ricerca di quella necessaria per comunicare in modo sicuro con una persona. Fin qui tutto bene, sembrerebbe la rivoluzione, ma la verità è che nessuno lo usa, se non per divertimeno e/o test. Questo perchè l'utilizzo di PGP risulta essere prolisso e scomodo (ricerco la chiave, cifro il messaggio con quella chiave e invio il messaggio cifrato; ricevo il messaggio cifrato, lo "apro" con la mia chiave, lo leggo e rispondo) e, a meno di non avere a che fare con un segreto di stato, siamo tutti disposti a permettere a chiunque di leggere le nostre email a fronte di una comodità e immediatezza senza eguali. Esistono però diverse applicazioni che implementano questo tipo di sicurezza in modo totalmente automatico e da qualche tempo a questa parte molti dei servizi più noti, quali Telegram e Whatsapp ad esempio, stanno adottando questo tipo di crittografia, ma la maggior parte di quelle in circolazione adotta soltanto il metodo "standard", non cifrato. Ed è qui che entra in gioco Keybase, un servizio che potrebbe ricordare uno dei tanti database di chiavi pubbliche, ma che in realtà offre molto di più. Più che un sito di raccolta chiavi, si potrebbe definire come un social network, il cui scopo è quello di creare una rete di identità verificate. Il proprio profilo è infatti collegabile a quello dei più comuni social network, tra cui Facebook, Twitter e Reddit, in aggiunta ai propri dispositivi [2] e siti internet. Il profilo principale dispone infatti solamente di un indirizzo email, quello a cui è associata la coppia di chiavi necessaria per la cifratura dei messaggi, a cui sarà poi possibile collegare tutti gli altri servizi, attraverso ad esempio la pubblicazione di un post sul social network che si vuole verificare. In questo modo dal proprio profilo su Keybase sarà possibile raggiungere i profili esterni verificati e allo stesso tempo avere la certezza che "quel profilo Facebook e quell'account Github appartengono stessa persona". La componente "social" di keybase è inoltre la possibilità di verificare le identità di altri utenti, firmando il loro profilo. Un po' come dire "Conosco questa persona nella realtà e vi assicuro che questi profili sul web siano veramente i suoi". Ovviamente queste funzionalità sono disponibili sia dal sito web che da command line (disponibile sia per Windows, che Linux e OSX) e da qualche mese a questa parte è stata introdotta un'applicazione per pc, sempre multipiattaforma, in modo da effettuare tutte le operazioni elencate sopra con comodità. Dal lancio dell'applicazione sono seguite numerose novità, tra cui l'introduzione di una chat real time completamente cifrata e KBFS. Acronimo di "Keybase File System" è di fatto un servizio di hosting gratuito che implementa e permette di utilizzare comodamente i meccanismi di cifratura di PGP. Presentandosi come una cartella keybase nella root del proprio pc, è suddivisa in due parti da due sottocartelle, una pubblica - cartella public - e una privata - private -. Per farla breve è una sorta di Dropbox, uno spazio online su cui caricare i nostri documenti, ma suddiviso in due aree. Tutto quello che carichiamo nella zona privata viene cifrato con la nostra chiave e di conseguenza risulta leggibile solo da noi stessi, mentre i file nella cartella pubblica vengono firmati con la nostra chiave e messi a disposizione di tutti gli utenti Keybase. Le potenzialità di KBFS non finiscono qui, ma essendo un argomento particolarmente denso e davvero innovativo è bene spenderci qualche parola in più nel prossimo articolo. In conclusione, perchè utilizzare Keybase? Innanzitutto perchè  tutti dovremmo tenere un po' di più alla sicurezza dei nostri dati in rete e questo servizio permette di farlo in modo divertente e social, e poi per KBFS, che da solo - a mio parere - vale il tempo "perso" per iscriversi al sito. [1] Tipicamente in un attacco viene nominato man-in-the-middle il malintenzionato che si posiziona nel mezzo di una conversazione intercettando tutti i messaggi. [2] Keybase permette di verificare i propri PC in modo tale che le operazioni legate al proprio profilo (attraverso l'applicazione o la command line) possano essere effettuate solo sui dispositivi registrati. Tra questi ci sono inoltre i cosiddetti paper key, delle chiavi sotto forma di stringa di testo da trascrivere su un foglio di carta utilizzate per il recupero dell'account o l'accesso nel caso non si possa verificare il dispositivo in altro modo.