home Ricerca per tag "security"


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.

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.