- 16 Agosto 2010
- 66
- 0
- Miglior risposta
- 0
Buona sera a tutti.
Da molto tempo volevo tornare a scrivere in questo forum, sono davvero contento che nel frattempo abbia continuato il suo restyling - non solo estetico.
Cito il ragazzo che qualche giorno fa mi ha gentilmente consigliato - seppur incondizionatamente, la stesura di questa guida, [MENTION]Andreitos97[/MENTION].
Premessa: questa non sarà una semplice guida, non è nel mio stile e non mi piace preconfezionare qualcosa che potrebbe invece avere tantissimi spunti d'interesse.
Sarà una guida molto lunga e spero di formattarla al meglio, non troverete un tutorial ma un riassunto di tutto quel che ho voluto imprimere in parte teorica e pratica.
Vi sarà un'intero paragrafo sulla storia, sugli usi e i costumi che questa invenzione ha caratterizzato e ad essa vi saranno aggiunte voci di capitolo, storiografie e biografie.
Non penso che sia un qualcosa che in tanti leggeranno ma l'ho voluto fare un po' perché mi ci sono impegnato, un po' perché mi è divertito e mi farebbe piacere aiutasse qualcuno, visto che in rete, almeno in Italia, una guida del genere spesso e volentieri la si fa uscire con fatica. Ho deciso, quindi, di utilizzare la marcatura SPOILER per suddividere i vari capitoli, giusto per non rendere la guida troppo lunga ed esasperante da leggere.
Buona continuazione.
Probabilmente il 60% di questa community conosce già Tor.
Chi ne è affascinato, chi spaventato, chi indifferente.
Ad ogni modo, ecco un po' di storia anche per il restante 40% - che non fa mai male.
La storia e la nascita di Tor.
2004, è l'era di Tor.
La storia finisce qui, ora cominciamo un po’ di tecnica.
Tor e la Cipolla.
Esempio di errore di crittazione in Tor – livello di comprensione medio/alto
Come proteggersi?
Cosa sono i siti .onion, quanti sono e come aprirne uno?
La "guida" finisce qui, ci ho messo due giorni a compierla e chiedo scusa all'utente citato ad inizio pagina per averci messo così tanto.
Spero vi sia state d'aiuto. Per qualunque domanda, io sono qui.
Da molto tempo volevo tornare a scrivere in questo forum, sono davvero contento che nel frattempo abbia continuato il suo restyling - non solo estetico.
Cito il ragazzo che qualche giorno fa mi ha gentilmente consigliato - seppur incondizionatamente, la stesura di questa guida, [MENTION]Andreitos97[/MENTION].
Premessa: questa non sarà una semplice guida, non è nel mio stile e non mi piace preconfezionare qualcosa che potrebbe invece avere tantissimi spunti d'interesse.
Sarà una guida molto lunga e spero di formattarla al meglio, non troverete un tutorial ma un riassunto di tutto quel che ho voluto imprimere in parte teorica e pratica.
Vi sarà un'intero paragrafo sulla storia, sugli usi e i costumi che questa invenzione ha caratterizzato e ad essa vi saranno aggiunte voci di capitolo, storiografie e biografie.
Non penso che sia un qualcosa che in tanti leggeranno ma l'ho voluto fare un po' perché mi ci sono impegnato, un po' perché mi è divertito e mi farebbe piacere aiutasse qualcuno, visto che in rete, almeno in Italia, una guida del genere spesso e volentieri la si fa uscire con fatica. Ho deciso, quindi, di utilizzare la marcatura SPOILER per suddividere i vari capitoli, giusto per non rendere la guida troppo lunga ed esasperante da leggere.
Buona continuazione.
Probabilmente il 60% di questa community conosce già Tor.
Chi ne è affascinato, chi spaventato, chi indifferente.
Ad ogni modo, ecco un po' di storia anche per il restante 40% - che non fa mai male.
La storia e la nascita di Tor.
Tor nasce esattamente diciannove anni prima della comparsa della prima rete di telecomunicazione globale, ossia l’Internet che noi tutti siamo abituati ad utilizzare quotidianamente, spesso dimenticando quanto lavoro e difficoltà ci sia dietro anche un singolo byte di memoria.
Ci troviamo a Berkeley, Università della California, siamo nel 1979 e un tale David Chaum, dal suo laboratorio di ricerca elettronica, scrive un piccolo manuale di dieci pagine che prenderà il nome – intraducibile in italiano – di Computer Systems Established, Maintained and Trusted by Mutually Suspicious Groups.
Non serve tradurla – e non si dovrebbe – ma basta pensare che queste dieci pagine da quel momento in poi esplosero in uno dei concetti informatici più complessi e interessanti di sempre.
Catapultiamoci completamente: fingiamo di trovarci davvero verso la fine del 1979, Internet è già una realtà di tutti i giorni ma non è ancora diffuso, molte persone continuano a riferirsi ad una certa MILNET – di cosa si trattava?
Altro non era che una piccola fetta del nostro attuale Internet, solo privatizzata e resa disponibile soltanto ad una cerchia di collettivi – ad esempio il Dipartimento della Difesa, le università o i centri di ricerca per lo sviluppo scientifico. Per quanto possa sembrare un’idea idiota, rendere privata la rete fu un colpo di genio.
Venne fuori, infatti, che le attività di tutti questi ricercatori, studenti e membri di gruppi scientifici sparsi per tutto il mondo venivano in realtà monitorate a distanza di mesi.
Esatto, non c’era una vera e propria sicurezza poiché nessun membro avrebbe mai immaginato una tale diffusione e propagazione di un servizio che quarant’anni fa si credeva confinato ai servizi segreti.
Lentamente, quindi, prese largo l'idea di scambiarsi, oltre alle informazioni e dati, messaggi privati che coinvolgessero altri “utenti” comuni – estranei a quelle cerchie e a quel vantaggio.
Da questo caos, del tutto spontaneamente, nasce la posta elettronica, i primi forum, le prime password e i primi algoritmi di protezione.
Dagli anni '80 in poi è tutto un boom: nasce il software proprietario, le licenze sono vendute a peso d'oro, nascono le prime royalties e i primi sistemi operativi ceduti dietro "contratto".
Unix viene servito sotto una licenza commerciale, nel 1983, sempre presso l'Università di Berkeley, nasce la Berkeley Software Distribution (BSD) sviluppata con una grossa sovvenzione da parte dello stato al fine di progettare uno standard UNIX per fine unicamente governativo.
A nessuno sta bene, Internet si scopre libero ma i Software al suo interno non lo sono.
Per contrattaccare questo monopolio, lo stesso anno un tale Richard Stallmann – come se non lo conosceste – inizia una rimplementazione gratuita di UNIX che prenderà il nome di GNU – anche qui, quante volte l’avete sentita questa storia? – (acronimo di "Gnu is not UNIX” – “Gnu non è UNIX”) che conseguentemente, in poco tempo, porterà alla creazione del più influente editor di testo della storia informatica: emacs.
Stallman con il suo GNU ridefinisce l’attuale idea di "pubblico dominio" a cui darà il nome di copyleft– vi ricorda per caso il copyright? – ossia una licenza che permette di distribuire gratuitamente un software, dichiarando la più completa libertà dell’utente nella ridistribuzione e modifica del sorgente.
Geniale come idea, no?
Quindi internet si liberalizza quasi del tutto e saltiamo avanti di tre anni.
Siamo nel 1985 e il nostro David Chaum comincia a familiarizzare con un gruppo variegato di anarchici, i Cypherpunks e nello specifico con Eric Hughes, fondatore e capo di questa unione.
Insieme scrivono il primo manifesto sulla crittografia come metodo di rivoluzione politica e da questa illuminazione tutto prende vita.
Nel 1986 David Chaum e il suo gruppo provocano una grave querelle giuridica, suscitando l'ira e facendo incazzare non poco la “open-minded” religione di Scientology che, in tribunale, accusava i Cypherpunks di aver perpetrato il sistema informatico governativo e di aver poi distribuito file e informazioni strettamente confidenziali con terze parti.
Toc-toc, Wikileaks ;)
Comunque, la causa avrà vita lunga, tant’è che il Congresso decide, lo stesso anno, di scrivere una legge apposita che fungesse da emendamento per una già pre-esistente, ma non funzionale, legge sulle frodi bancarie e fiscali, inserendone però un’ultima: quella digitale.
Ve la faccio breve: in pratica nel 1986 il Governo degli Stati Uniti d’America si accorge che da un semplice computer, partendo da una semplice riga di codice, fosse possibile disintegrare un sistema intero fondato su centinaia di migliaia di segreti.
Come non poteva Chaum, in mezzo a tutto quel bel casino, porsi qualche domanda?
Il manifesto fu un successo ma Chaum voleva andare oltre: perché qualcuno dovrebbe nascondere la verità e soprattutto, qual è il modo per nasconderla al meglio?
L'anno stesso Chaum torna a Berkeley e scrive il primo robusto meccanismo di crittografia fondato sulle Mix-net – un sistema di reti protette basato su delle chiavi di protezione che lui stesso descrisse nel manuale citato ad inizio pagina – e per quattro anni tutto resta in incubazione.
Anni '90, Paul Syverson conosce Chaum ed insieme ad un gruppo di quattro programmatori estendono l'applicazione delle Mixnet per il routing di pacchetti di informazioni – praticamente una modificazione alla nostra normale ricezione sulle connessioni basate sulla transizione client-server – che prenderà il nome di Onion Routing proprio perché i dati ricevuti non si spostano su delle linee rette ma rimbalzano da uno strato ad un altro, come all’interno di una grande cipolla digitale.
Nel 1992 Internet si espande alla navigazione web, lo scambio di informazioni è talmente immersivo ed elevato che immediatamente i ricercatori che si occupano di privacy in Rete percepiscono che la navigazione web, oltre ad essere facilmente intercettabile dai provider di rete, lascia informazioni personali sui log dei server.
In pochi mesi si risente la necessità di un protocollo unidirezionale che tuteli, almeno parzialmente, la sicurezza di un singolo individuo.
Comincia lo sviluppo del protocollo SSL che permette una più dinamica criptazione end-to-end evitando così, almeno, l’intercettazione da parte degli ISP ma lasciando comunque libera la protezione sui referral e sui cookie, ad esempio.
Siamo nel 1999 ed il concetto di proxy prende vita in tutta la sua artificiale bellezza, è l'era di Napster e di Crowds – una versione ancora embrionale di Tor, che tra l’altro deriva da “blending into a crowd”, ossia “disperdersi in mezzo alla folla” – che sceglie casualmente un proxy e indirizza la connessione non verso la destinazione (client to server) ma verso il proxy stesso.
Ci troviamo a Berkeley, Università della California, siamo nel 1979 e un tale David Chaum, dal suo laboratorio di ricerca elettronica, scrive un piccolo manuale di dieci pagine che prenderà il nome – intraducibile in italiano – di Computer Systems Established, Maintained and Trusted by Mutually Suspicious Groups.
Non serve tradurla – e non si dovrebbe – ma basta pensare che queste dieci pagine da quel momento in poi esplosero in uno dei concetti informatici più complessi e interessanti di sempre.
Catapultiamoci completamente: fingiamo di trovarci davvero verso la fine del 1979, Internet è già una realtà di tutti i giorni ma non è ancora diffuso, molte persone continuano a riferirsi ad una certa MILNET – di cosa si trattava?
Altro non era che una piccola fetta del nostro attuale Internet, solo privatizzata e resa disponibile soltanto ad una cerchia di collettivi – ad esempio il Dipartimento della Difesa, le università o i centri di ricerca per lo sviluppo scientifico. Per quanto possa sembrare un’idea idiota, rendere privata la rete fu un colpo di genio.
Venne fuori, infatti, che le attività di tutti questi ricercatori, studenti e membri di gruppi scientifici sparsi per tutto il mondo venivano in realtà monitorate a distanza di mesi.
Esatto, non c’era una vera e propria sicurezza poiché nessun membro avrebbe mai immaginato una tale diffusione e propagazione di un servizio che quarant’anni fa si credeva confinato ai servizi segreti.
Lentamente, quindi, prese largo l'idea di scambiarsi, oltre alle informazioni e dati, messaggi privati che coinvolgessero altri “utenti” comuni – estranei a quelle cerchie e a quel vantaggio.
Da questo caos, del tutto spontaneamente, nasce la posta elettronica, i primi forum, le prime password e i primi algoritmi di protezione.
Dagli anni '80 in poi è tutto un boom: nasce il software proprietario, le licenze sono vendute a peso d'oro, nascono le prime royalties e i primi sistemi operativi ceduti dietro "contratto".
Unix viene servito sotto una licenza commerciale, nel 1983, sempre presso l'Università di Berkeley, nasce la Berkeley Software Distribution (BSD) sviluppata con una grossa sovvenzione da parte dello stato al fine di progettare uno standard UNIX per fine unicamente governativo.
A nessuno sta bene, Internet si scopre libero ma i Software al suo interno non lo sono.
Per contrattaccare questo monopolio, lo stesso anno un tale Richard Stallmann – come se non lo conosceste – inizia una rimplementazione gratuita di UNIX che prenderà il nome di GNU – anche qui, quante volte l’avete sentita questa storia? – (acronimo di "Gnu is not UNIX” – “Gnu non è UNIX”) che conseguentemente, in poco tempo, porterà alla creazione del più influente editor di testo della storia informatica: emacs.
Stallman con il suo GNU ridefinisce l’attuale idea di "pubblico dominio" a cui darà il nome di copyleft– vi ricorda per caso il copyright? – ossia una licenza che permette di distribuire gratuitamente un software, dichiarando la più completa libertà dell’utente nella ridistribuzione e modifica del sorgente.
Geniale come idea, no?
Quindi internet si liberalizza quasi del tutto e saltiamo avanti di tre anni.
Siamo nel 1985 e il nostro David Chaum comincia a familiarizzare con un gruppo variegato di anarchici, i Cypherpunks e nello specifico con Eric Hughes, fondatore e capo di questa unione.
Insieme scrivono il primo manifesto sulla crittografia come metodo di rivoluzione politica e da questa illuminazione tutto prende vita.
Nel 1986 David Chaum e il suo gruppo provocano una grave querelle giuridica, suscitando l'ira e facendo incazzare non poco la “open-minded” religione di Scientology che, in tribunale, accusava i Cypherpunks di aver perpetrato il sistema informatico governativo e di aver poi distribuito file e informazioni strettamente confidenziali con terze parti.
Toc-toc, Wikileaks ;)
Comunque, la causa avrà vita lunga, tant’è che il Congresso decide, lo stesso anno, di scrivere una legge apposita che fungesse da emendamento per una già pre-esistente, ma non funzionale, legge sulle frodi bancarie e fiscali, inserendone però un’ultima: quella digitale.
Ve la faccio breve: in pratica nel 1986 il Governo degli Stati Uniti d’America si accorge che da un semplice computer, partendo da una semplice riga di codice, fosse possibile disintegrare un sistema intero fondato su centinaia di migliaia di segreti.
Come non poteva Chaum, in mezzo a tutto quel bel casino, porsi qualche domanda?
Il manifesto fu un successo ma Chaum voleva andare oltre: perché qualcuno dovrebbe nascondere la verità e soprattutto, qual è il modo per nasconderla al meglio?
L'anno stesso Chaum torna a Berkeley e scrive il primo robusto meccanismo di crittografia fondato sulle Mix-net – un sistema di reti protette basato su delle chiavi di protezione che lui stesso descrisse nel manuale citato ad inizio pagina – e per quattro anni tutto resta in incubazione.
Anni '90, Paul Syverson conosce Chaum ed insieme ad un gruppo di quattro programmatori estendono l'applicazione delle Mixnet per il routing di pacchetti di informazioni – praticamente una modificazione alla nostra normale ricezione sulle connessioni basate sulla transizione client-server – che prenderà il nome di Onion Routing proprio perché i dati ricevuti non si spostano su delle linee rette ma rimbalzano da uno strato ad un altro, come all’interno di una grande cipolla digitale.
Nel 1992 Internet si espande alla navigazione web, lo scambio di informazioni è talmente immersivo ed elevato che immediatamente i ricercatori che si occupano di privacy in Rete percepiscono che la navigazione web, oltre ad essere facilmente intercettabile dai provider di rete, lascia informazioni personali sui log dei server.
In pochi mesi si risente la necessità di un protocollo unidirezionale che tuteli, almeno parzialmente, la sicurezza di un singolo individuo.
Comincia lo sviluppo del protocollo SSL che permette una più dinamica criptazione end-to-end evitando così, almeno, l’intercettazione da parte degli ISP ma lasciando comunque libera la protezione sui referral e sui cookie, ad esempio.
Siamo nel 1999 ed il concetto di proxy prende vita in tutta la sua artificiale bellezza, è l'era di Napster e di Crowds – una versione ancora embrionale di Tor, che tra l’altro deriva da “blending into a crowd”, ossia “disperdersi in mezzo alla folla” – che sceglie casualmente un proxy e indirizza la connessione non verso la destinazione (client to server) ma verso il proxy stesso.
2004, è l'era di Tor.
"Tor" sta per "the second generation Onion Routing" e nella sua fase principale si trattava “semplicemente” di una rete permeata da proxy criptati che permettevano di rendere anonima qualunque comunicazione che avveniva tramite l'utilizzo del protocollo TCP.
Capirete voi stessi, un utente normale non ne ha bisogno, o sbaglio?
L'idea originale concepita da Chaum e Syverson, infatti, nasceva come sostentamento ad un ambiente di lavoro altamente formalizzato – come laboratori di ricerca o gruppi di studio universitari – e per molto tempo l’efficacia crittografica di questo ambiente è stata utilizzata dalle sfere governative e da nessun altro.
Soltanto dopo un anno, quando all’USENIX Security Semposium Tor viene presentato al pubblico, viene formata una teoria “normalizzante” e lentamente, con probabile sorpresa da parte di molte persone, Tor è diventato un strumento adattabile a qualunque priorità.
Capirete voi stessi, un utente normale non ne ha bisogno, o sbaglio?
L'idea originale concepita da Chaum e Syverson, infatti, nasceva come sostentamento ad un ambiente di lavoro altamente formalizzato – come laboratori di ricerca o gruppi di studio universitari – e per molto tempo l’efficacia crittografica di questo ambiente è stata utilizzata dalle sfere governative e da nessun altro.
Soltanto dopo un anno, quando all’USENIX Security Semposium Tor viene presentato al pubblico, viene formata una teoria “normalizzante” e lentamente, con probabile sorpresa da parte di molte persone, Tor è diventato un strumento adattabile a qualunque priorità.
La storia finisce qui, ora cominciamo un po’ di tecnica.
Tor fonda le sue radici su una serie di nodi chiamati relay, che conseguentemente si basano su altre quattro serie di nodi: client, relay, router e directory server. Serve guardare da vicino un programma per capire al meglio il loro funzionamento e in totale il funzionamento di Tor.
Uno degli esempi che ricordo fu utilizzato in questo simposio, nella presentazione ufficiale di Tor, fu molto intuitivo anche per i meno esperti e voglio ripresentarvelo.
Immaginiamo quattro persone diverse: Jane e Bob sono dei server facilmente e pubblicamente raggiungibili da chiunque in internet e che si trovano in quella parte chiamata clearnet. Poi c'è Alice e lei è la protagonista di questo esempio.
Alice, a differenza di Jane e Bob, sta utilizzando un client di Tor.
La nostra ultima persona è Dave che è un particolare server pubblico chiamato "directory server", Dave è quasi unico nel suo genere perché fa un lavoro che soltanto in pochi sanno fare. Lui e i suoi simili, infatti, forniscono ad Alice la lista pubblica e aggiornata di relay – immaginiamo che siano delle conversazioni private, dei dati – che permettono il traffico anonimo in uscita e la realizzazione di praticamente tutti i servizi presenti in Tor.
Senza questi relay Alice non potrebbe navigare in Tor e non potrebbe accedervi, un po’ come un file torrent senza seed.
Alice quindi sta utilizzando Tor e questo grazie a Dave.
Il primo passo compiuto da Tor , nel momento in cui Alice si connette, è quello di contattare Dave per ottenere la lista aggiornata di tutti i nodi e di tutte le “conversazioni” possibili così da velocizzare qualunque genere di connessione.
Arrivata fin qui, Alice istruisce il proprio client di contattare il server Bob magari perché vuole entrare in un sito pubblico, ma bloccato nel suo paese.
Immediatamente la richiesta arriva a Bob, il client Tor di Alice da quel momento non farà altro che costruire una catena di piccoli nodi attraverso i quali invierà altrettante richieste che passeranno però attraverso Dave, proteggendo e mascherando quindi l’identità di Alice dentro il server Bob.
Tor funziona esattamente così: immaginiamo anche una lunga catena in ferro, praticamente infinita e dove all’interno di ogni nodo metallico è contenuto un dato, un bit di memoria. Tutti i dati presenti all’interno di questa enorme catena prendono un particolare nome a seconda della loro posizione nella catena stessa.
Da cosa è data la posizione nella catena?
Un file in un formato immagine (.png o .bmp) si porterà dietro massimo 500kb, e quella immagine sarà la prima che il server invierà al nodo più vicino e quanto più in alto nella catena, così da poter essere inviata il prima possibile.
I nodi di questa catena sono diversificati e ognuno di loro ha un corrispettivo potere – rileggeteli più volte, li riuseremo più avanti: il primo nodo si chiama Guard Node (Nodo di Guardia), il secondo è il Middleman Node (Nodo Intermediario), il terzo ed ultimo è l’Exit Node (Nodo di Uscita) e ognuno di loro funziona autonomamente.
La scelta dei nodi di una catena viene effettuata non soltanto in base ai byte di memoria contenuti in esso, ma anche in base alle informazioni ricevute dal directory server (il prezioso Dave). Ogni dato inviato – quindi ogni “conversazione” – quando passa attraverso le directory invia il proprio indirizzo IP (mascherato) e una serie di caratteristiche molto peculiari. Tutto questo poi passa attraverso gli exit node che sono la parte più interessante ed importante: contattando loro personalmente, si ha una specie di raccomandazione a lungo termine poiché le macchine esterne alla rete di Tor, prima di poter completamente uscire dal range di spazio in cui si sono inseriti, devono dichiarare di essere stati “mascherati” abbastanza bene.
In termini strettamente tecnici: quando la richiesta inviata attraversa una entry-node (o nodo intermedio, middleman node – come specificato prima) viene agganciata ad essa una configurazione che ne limita la banda in un default di 250kB/s e con un massimo di 10GB giornalieri, questo fungerà da lasciapassare per quando, nell’exit node, si utilizza una porta raggiungibile da tutti i bridge.
Tornando alla catena: tutte le rimanenti "conversazioni" che non oltrepassano questo fatidico Exit-Node sono da considerarsi nodi intermediari. Il perché di questa scelta è intuitiva già di per sé: il primo e l'ultimo nodo della catena rappresenta un ottimo punto dove attaccare il protocollo di connessione, e questo risulta principalmente il motivo per la quale attaccare il protocollo di desinenza – quello principale, intermedio o d’uscita – sarebbe impossibile senonché improbabile.
La comunicazione che avviene all'interno della rete di Tor è crittata e questo impedirebbe comunque qualsivoglia genere di attacco di ricostruire la "conversazione" poiché il flusso sarebbe spezzettato, come se la catena d'un tratto si rompesse e si scomponesse.
Uno degli esempi che ricordo fu utilizzato in questo simposio, nella presentazione ufficiale di Tor, fu molto intuitivo anche per i meno esperti e voglio ripresentarvelo.
Immaginiamo quattro persone diverse: Jane e Bob sono dei server facilmente e pubblicamente raggiungibili da chiunque in internet e che si trovano in quella parte chiamata clearnet. Poi c'è Alice e lei è la protagonista di questo esempio.
Alice, a differenza di Jane e Bob, sta utilizzando un client di Tor.
La nostra ultima persona è Dave che è un particolare server pubblico chiamato "directory server", Dave è quasi unico nel suo genere perché fa un lavoro che soltanto in pochi sanno fare. Lui e i suoi simili, infatti, forniscono ad Alice la lista pubblica e aggiornata di relay – immaginiamo che siano delle conversazioni private, dei dati – che permettono il traffico anonimo in uscita e la realizzazione di praticamente tutti i servizi presenti in Tor.
Senza questi relay Alice non potrebbe navigare in Tor e non potrebbe accedervi, un po’ come un file torrent senza seed.
Alice quindi sta utilizzando Tor e questo grazie a Dave.
Il primo passo compiuto da Tor , nel momento in cui Alice si connette, è quello di contattare Dave per ottenere la lista aggiornata di tutti i nodi e di tutte le “conversazioni” possibili così da velocizzare qualunque genere di connessione.
Arrivata fin qui, Alice istruisce il proprio client di contattare il server Bob magari perché vuole entrare in un sito pubblico, ma bloccato nel suo paese.
Immediatamente la richiesta arriva a Bob, il client Tor di Alice da quel momento non farà altro che costruire una catena di piccoli nodi attraverso i quali invierà altrettante richieste che passeranno però attraverso Dave, proteggendo e mascherando quindi l’identità di Alice dentro il server Bob.
Tor funziona esattamente così: immaginiamo anche una lunga catena in ferro, praticamente infinita e dove all’interno di ogni nodo metallico è contenuto un dato, un bit di memoria. Tutti i dati presenti all’interno di questa enorme catena prendono un particolare nome a seconda della loro posizione nella catena stessa.
Da cosa è data la posizione nella catena?
Un file in un formato immagine (.png o .bmp) si porterà dietro massimo 500kb, e quella immagine sarà la prima che il server invierà al nodo più vicino e quanto più in alto nella catena, così da poter essere inviata il prima possibile.
I nodi di questa catena sono diversificati e ognuno di loro ha un corrispettivo potere – rileggeteli più volte, li riuseremo più avanti: il primo nodo si chiama Guard Node (Nodo di Guardia), il secondo è il Middleman Node (Nodo Intermediario), il terzo ed ultimo è l’Exit Node (Nodo di Uscita) e ognuno di loro funziona autonomamente.
La scelta dei nodi di una catena viene effettuata non soltanto in base ai byte di memoria contenuti in esso, ma anche in base alle informazioni ricevute dal directory server (il prezioso Dave). Ogni dato inviato – quindi ogni “conversazione” – quando passa attraverso le directory invia il proprio indirizzo IP (mascherato) e una serie di caratteristiche molto peculiari. Tutto questo poi passa attraverso gli exit node che sono la parte più interessante ed importante: contattando loro personalmente, si ha una specie di raccomandazione a lungo termine poiché le macchine esterne alla rete di Tor, prima di poter completamente uscire dal range di spazio in cui si sono inseriti, devono dichiarare di essere stati “mascherati” abbastanza bene.
In termini strettamente tecnici: quando la richiesta inviata attraversa una entry-node (o nodo intermedio, middleman node – come specificato prima) viene agganciata ad essa una configurazione che ne limita la banda in un default di 250kB/s e con un massimo di 10GB giornalieri, questo fungerà da lasciapassare per quando, nell’exit node, si utilizza una porta raggiungibile da tutti i bridge.
Tornando alla catena: tutte le rimanenti "conversazioni" che non oltrepassano questo fatidico Exit-Node sono da considerarsi nodi intermediari. Il perché di questa scelta è intuitiva già di per sé: il primo e l'ultimo nodo della catena rappresenta un ottimo punto dove attaccare il protocollo di connessione, e questo risulta principalmente il motivo per la quale attaccare il protocollo di desinenza – quello principale, intermedio o d’uscita – sarebbe impossibile senonché improbabile.
La comunicazione che avviene all'interno della rete di Tor è crittata e questo impedirebbe comunque qualsivoglia genere di attacco di ricostruire la "conversazione" poiché il flusso sarebbe spezzettato, come se la catena d'un tratto si rompesse e si scomponesse.
Tor e la Cipolla.
Andiamo avanti con l’esempio, immaginando – e immaginando bene – l’interno di un circuito esattamente come l’interno di una cipolla e diciamo che questa fatidica cipolla è composta da quattro strati uno sopra l’altro, ben diversificati e ognuno con la propria chiave.
Alice è quindi riuscita ad entrare in un sito bloccato nel suo paese utilizzando Tor, questo sempre grazie all’aiuto del suo amico Dave che le ha permesso di ottenere la lista aggiornata di tutte le “conversazioni”.
La domanda sorge spontanea: Alice come è riuscita a sparire dai radar e in che modo hanno comunicato tra di loro tutti questi server?
Il principale strato di questa cipollottola, quello alla superficie, è di proprietà del Guard Node ed è protetto dalle chiavi del Guard Node stesso: non c'è niente che tu possa fare, le chiavi le ha in tasca.
Soltanto lui può leggere il contenuto di questo strato e tutti i messaggi contenuti al suo interno restano di sua proprietà – compresa l’identità di Alice.
Il Guard Node non è però avido e sa fare il suo lavoro, leggendo le istruzioni all'interno del suo personale strato capisce che deve inviare il resto del contenuto a Middleman Node.
Middleman Node non è tanto diverso da Guard Node, lui riceve ed archivia tutto in maniera molto meticolosa, il contenuto del suo strato è leggibile unicamente dal suo destinatario – e proprio qui vengono raccolte le tracce di Alice.
In questo strato, Middleman Node dà un'occhiata alle istruzioni e sa che deve spedire il resto del contenuto ad Exit Node.
Qui non ve lo sto neanche a spiegare: l’Exit Node è la via del non ritorno.
Arrivati a questo livello, le indicazioni e le tracce riguardanti Alice non esistono più.
Exit Node, l'amico in comune, riceve da Middleman Node tutti gli ultimi scarti circa l’identità della nostra Alice, il polvericcio di tutta l’intera cipolla.
Exit legge il contenuto decifrabile esclusivamente da lui e sa cosa deve fare: richiesta al nostro amico server Bob – quello a cui Alice si è affidata – che in questo caso funge proprio da “picker”, ossia un impacchettatore di dati. Visualizzerà al volo la richiesta fatta da Exit Node e la rinvierà a quest’ultimo, che di conseguenza la inoltrerà nuovamente a Middleman Node il quale, vedendosi arrivare una risposta da Exit, passerà il pacchetto già imbustato a Guard Node che chiuderà il circuito inviando la risposta ad Alice.
Il protocollo in questo modo è in grado di non essere percepito dalle analisi del traffico poiché correlare contenuto e mittente diverrebbe un’impresa titanica.
Ricordando che, anche se si riuscisse a decifrare uno di questi intervalli di "domanda-risposta", comunque la chiave di sessione verrebbe, in un costante rigeneramento, modificata frequentemente e leggibile soltanto da Alice in persona.
Alice è quindi riuscita ad entrare in un sito bloccato nel suo paese utilizzando Tor, questo sempre grazie all’aiuto del suo amico Dave che le ha permesso di ottenere la lista aggiornata di tutte le “conversazioni”.
La domanda sorge spontanea: Alice come è riuscita a sparire dai radar e in che modo hanno comunicato tra di loro tutti questi server?
Il principale strato di questa cipollottola, quello alla superficie, è di proprietà del Guard Node ed è protetto dalle chiavi del Guard Node stesso: non c'è niente che tu possa fare, le chiavi le ha in tasca.
Soltanto lui può leggere il contenuto di questo strato e tutti i messaggi contenuti al suo interno restano di sua proprietà – compresa l’identità di Alice.
Il Guard Node non è però avido e sa fare il suo lavoro, leggendo le istruzioni all'interno del suo personale strato capisce che deve inviare il resto del contenuto a Middleman Node.
Middleman Node non è tanto diverso da Guard Node, lui riceve ed archivia tutto in maniera molto meticolosa, il contenuto del suo strato è leggibile unicamente dal suo destinatario – e proprio qui vengono raccolte le tracce di Alice.
In questo strato, Middleman Node dà un'occhiata alle istruzioni e sa che deve spedire il resto del contenuto ad Exit Node.
Qui non ve lo sto neanche a spiegare: l’Exit Node è la via del non ritorno.
Arrivati a questo livello, le indicazioni e le tracce riguardanti Alice non esistono più.
Exit Node, l'amico in comune, riceve da Middleman Node tutti gli ultimi scarti circa l’identità della nostra Alice, il polvericcio di tutta l’intera cipolla.
Exit legge il contenuto decifrabile esclusivamente da lui e sa cosa deve fare: richiesta al nostro amico server Bob – quello a cui Alice si è affidata – che in questo caso funge proprio da “picker”, ossia un impacchettatore di dati. Visualizzerà al volo la richiesta fatta da Exit Node e la rinvierà a quest’ultimo, che di conseguenza la inoltrerà nuovamente a Middleman Node il quale, vedendosi arrivare una risposta da Exit, passerà il pacchetto già imbustato a Guard Node che chiuderà il circuito inviando la risposta ad Alice.
Il protocollo in questo modo è in grado di non essere percepito dalle analisi del traffico poiché correlare contenuto e mittente diverrebbe un’impresa titanica.
Ricordando che, anche se si riuscisse a decifrare uno di questi intervalli di "domanda-risposta", comunque la chiave di sessione verrebbe, in un costante rigeneramento, modificata frequentemente e leggibile soltanto da Alice in persona.
Esempio di errore di crittazione in Tor – livello di comprensione medio/alto
Non voglio indurvi all'omicidio raccontandovi la storia della crittografia, anche perché personalmente non ricordo nulla e mi annoierebbe un po’, ma vorrei però aprire una finestra sui sistemi crittografici che, sempre in costante evoluzione, sembrano così difficili da violare soprattutto se coesistenti ad uno sviluppo tanto esigente di un software tanto inviolabile. Il tutto sarà coadiuvato da piccoli esempi che per funzionare dovrebbero implementare un po' di C – che consente di generare velocemente alcuni schemi non auto-esplicativi per molti – e questa è probabilmente la parte più tecnica e meno teorica della “guida” che inserisco ugualmente per principio.
Tor non è solito utilizzare una gestione diretta per la rotta dei propri nodi, sfrutta e manipola diversi protocolli di rete ed ognuno di loro inevitabilmente passa attraverso il loro personale SOCKS che, dopo una breve fase di handshake, invia – come già spiegato prima – una richiesta in cui specifica i parametri per lo svolgimento della crittazione.
In questo determinato caso gli esempi che tratterò saranno confinati al protocollo V4A nella versione 4.07 e mi baserò su un bug – esteso qui per motivi pratici – che sfrutta il Buffer Overflow di una macchina Windows.
Questo protocollo non è ancora in disuso ma questo bug è stato risolto già da molto tempo ed è da intendersi tale soltanto per fini esplicativi.
Diciamo di aver inviato una richiesta HTTP proxandola sulla TCP su una porta 6588, l'attacco consiste in un reverse overflow dei caratteri ASCII e nello specifico da uno spazio seguito da 320 o più caratteri di non-space, seguiti da altrettanti due ritorno a capo che nella variante Socks4A determinano un messaggio di errore e un read-only sulla violazione principale della porta 6588.
Ci si trova quindi di fronte il message box e se non lo si termina manualmente un retry farà partire un secondo messaggio che ripete lo stesso errore principale. Differenti numeri di bytes invieranno quindi differenti errori fino al buffer overflow.
Per risolvere ci viene in soccorso Torify con un resolv.conf che automaticamente dà un’idea del lookup generale che un errore simile potrebbe assimilare. Il problema sta esattamente nella cattiva gestione dei DNS contenuta all’interno del PREROUTING – dove gli ASCII vengono letti a 7 bit.
Si apre Tails e con un iptables-restore (iptable.service) si sfruttano gli usage di memoria contenuti nella seguente stringa:
che funziona anche semplicemente immettendo semplicemente:
così da evitare che il systemd cada in declino una volta riaperta la parte attaccata.
Ricordiamo che in questa versione le iptables vengono lette in consecutiva con la gestione dei DNS e delle porte attaccate, quindi un PREROUTING senza prima un redirect non avrebbe senso.
Tor non è solito utilizzare una gestione diretta per la rotta dei propri nodi, sfrutta e manipola diversi protocolli di rete ed ognuno di loro inevitabilmente passa attraverso il loro personale SOCKS che, dopo una breve fase di handshake, invia – come già spiegato prima – una richiesta in cui specifica i parametri per lo svolgimento della crittazione.
In questo determinato caso gli esempi che tratterò saranno confinati al protocollo V4A nella versione 4.07 e mi baserò su un bug – esteso qui per motivi pratici – che sfrutta il Buffer Overflow di una macchina Windows.
Questo protocollo non è ancora in disuso ma questo bug è stato risolto già da molto tempo ed è da intendersi tale soltanto per fini esplicativi.
Diciamo di aver inviato una richiesta HTTP proxandola sulla TCP su una porta 6588, l'attacco consiste in un reverse overflow dei caratteri ASCII e nello specifico da uno spazio seguito da 320 o più caratteri di non-space, seguiti da altrettanti due ritorno a capo che nella variante Socks4A determinano un messaggio di errore e un read-only sulla violazione principale della porta 6588.
Ci si trova quindi di fronte il message box e se non lo si termina manualmente un retry farà partire un secondo messaggio che ripete lo stesso errore principale. Differenti numeri di bytes invieranno quindi differenti errori fino al buffer overflow.
Per risolvere ci viene in soccorso Torify con un resolv.conf che automaticamente dà un’idea del lookup generale che un errore simile potrebbe assimilare. Il problema sta esattamente nella cattiva gestione dei DNS contenuta all’interno del PREROUTING – dove gli ASCII vengono letti a 7 bit.
Si apre Tails e con un iptables-restore (iptable.service) si sfruttano gli usage di memoria contenuti nella seguente stringa:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Ricordiamo che in questa versione le iptables vengono lette in consecutiva con la gestione dei DNS e delle porte attaccate, quindi un PREROUTING senza prima un redirect non avrebbe senso.
Come proteggersi?
In effetti potrebbe far ridere una cosa simile: perché volersi proteggere se si è già protetti?
Un po’ come chiedere più sicurezza all’interno di una stazione di polizia.
In effetti la domanda non è del tutto matta o fuori controllo, qualcosa sotto c’è.
Ci si addentra in questo limbo per svariati e innumerevoli motivi e nessuno di questi andrebbe riconosciuto come “condivisibile” perché la privacy non è una opzione e proprio per questo motivo forse mi trovo qui a scrivere questa “guida”.
Tratteremo l’argomento senza pregiudicare nulla, bene o male che sia, i modi per proteggersi, a discapito del perché lo si fa, restano questi.
Premessa:[/B nessuno di questi modi fungerà da giubbotto antiproiettile, Tor non ha queste capacità e, se non lo aveste già capito da soli, la sicurezza in Internet non è mai davvero impenetrabile. Ci si può per tanto avvicinare, ma ricordiamoci che mettere la propria vita privata in mano ad una serie di numeri e variabili può risultare letale se non si prendono le giuste precauzioni.
Esistono diverse maniere per configurare al meglio la vostra personale sicurezza, credo che in ognuno di questi metodi una buona tecnica è sempre di conforto.
Cominciamo dal Tor Bundle che fino a qualche anno fa si poteva scaricare virtualmente sul sito ufficiale e che oramai da un po’ di tempo risulta difficile trovare – perché? Probabilmente perché tenere aggiornato un pacchetto è meno comodo di tenere aggiornato singolarmente un software e una shell assestante.
Il bundle comprendeva questi tre piccoli software:
Vidalia – un’interfaccia grafica per gli utenti base.
Privoxy – un talentuoso web proxy che molto spesso viene affiancato a Squid, entrambi in sincrono si occupano della gestione dei cookies sul controllo degli accessi – entrambi compatibili con SOCKS e distribuiti in licenza GPL.
Turbutton – piccola estensione per il controllo dei proxy automaticamente installata in Vidalia.
Io consiglio anche un altro caching web proxy: Polipo – il mio preferito.
Per quest’ultimo soltanto le versioni superiori alle 1.0.4 accettano SOCKS, quindi attenzione.
Non scriverò di come installarli uno ad uno perché i modi sono tanti e ognuno potrebbe trovarsi meglio “creandosene” direttamente uno specificatamente costruito per le proprie esigenze. Renderò invece disponibile la mia personale configurazione server, sperando possa esservi utile.
Privoxy è la mia prima scelta, si tratta di un proxy quasi totalmente strutturato seguendo le linee guida dei protocolli HTTP ed HTTPS che permette una configurazione estremamente accurata delle proprie regole, flessibile e saldo come una roccia, la sua installazione è una delle più semplici di questo bundle.
Io consiglio di abilitare nel vostro OS un dualboot con un ambiente UNIX qualsiasi, dove Tor è più libero di esprimersi e dove la gestione dei pacchetti è drasticamente più aperta di quanto non lo sia in Windows.
Se siamo su OSX – come nel mio caso – apriamo il terminale e diamo:
Questo scaricherà il pacchetto e imposterà la configurazione di default che lancerà poi il servizio.
Questo servizio è controllato da un apposito script che troveremo in /etc/init.d – sempre all’interno di /etc/ troveremo il file di configurazione, teniamolo d’occhio.
Dopo aver lanciato Privoxy, dobbiamo fare in modo che Tor si accorga di lui e viceversa.
Apriamo Firefox – non mi dite che stavate utilizzando chrome per navigare insieme a Tor – e andiamo su “Modifica/Preferenze”, quindi su “Impostazioni connessione”.
A questo punto bisogna indicare l’indirizzo di start-line che sarà 127.0.0.1 e la porta 8118 che fungerà da proxy HTTP ed SSL.
Ora tocca alla gestione delle config.
Torniamo in /etc/ e andiamo su /privoxy/config/, apriamolo e spostiamoci sulla riga 661.
Avremo di fronte la stringa listen-address che ci permette di variare i parametri dell’indirizzo a cui Privoxy è collegato.
Possiamo variarli in base alle nostre esigenze, io solitamente lascio tutto invariato.
Un piccolo trucchetto: l’user-defined è molto importante.
Spostiamoci su /etc/privoxy e modifichiamo il file user-defined, editiamolo da root e cerchiamo al suo interno la stringa { allow-ads }.
Questa stringa è molto importante per il set-domain del nostro bundle perché l’user-defined permette a Privoxy di sapere quali siano i contenuti bloccati (una sorta di adblock in miniatura).
Per aggiungere un sito specifico, inseriamo sotto { allow-ads } il sito che desideriamo proteggere dal block seguito da un punto (.sciax2.it) quindi riavviamo Privoxy.
Privoxy è un root-server, ricordiamolo, tutti i dati inviati a Tor non oltrepassano la Exit Node ma vengono rinviati con un modulo ancor più criptato a Privoxy, che li esamina e li modifica prima di inviarli completamente in rete.
Ora passiamo al mio preferito: Polipo.
Polipo nelle versioni attuali di Tor si comporta un po' diversamente da come accordato agli inizi, è infatti passato da un progetto assestante ad una specie di protesi artificiale che accompagna la nostra cipolla in tutte le nuove release. Per questo motivo bisogna prima riconfigurare l'avvio automatico settato di default in Tor e poi reinstallare Polipo in maniera del tutto distaccata da Tor stesso.
Polipo è il più piccolino fra i suoi "connazionali", utilizza la versione integrata dell'HTTP/1.1 per uno stream e un pipelining che supporta anche in locale (e che se lo si fa giochicchiare con Squid è ancora più divertente perché entrambi hanno un completo supporto all'IPv6 e con un po' di immaginazione li si può utilizzare per ridurre ancor di più la latenza dei vari servizi).
Da terminale, diamo:
quindi riconfiguriamo Polipo dando:
– se non avete gedit, inserite il nome del vostro editor di fiducia –
quindi inseriamo al posto della configurazione che trovate, quella che vedete in questo git:
Facciamo partire il daemon dando:
creiamo la directory delle cache dando:
e quindi installiamo la nuova configurazione:
poi, se proprio vogliamo – per evitare problemi ed inconvenienti con le porte principali, in /etc/polipo/config inseriamo:
e finisce qui.
Come penultimo stadio di protezione io mi sono sempre affidato anche a DansGuardian, che è una buonissima alternativa a tanti web content filter che si trovano un po’ dappertutto. Unire questi tre progetti (Squid/Polipo, Privoxy e DansGuardian) è una grande accoppiata.
Praticamente la famiglia perfetta. :soso:
Ricordiamo che DansGuardian utilizza la porta 8123 quindi dovrà essere riconfigurata per Polipo.
Scarichiamolo dando:
subito spostiamoci su /etc/dansguardian/dansguardian.conf ed eliminamo questa stringa:
ed al suo posto inseriamo un #.
Ora dovremmo cambiare le porte per renderle compatibili con Squid e Polipo.
Cerchiamoci le stringhe denominate filterport e proxyport e cambiamo le porte con:
E adesso daremo il default “proxy” per entrambi i daemon utente e gruppo, questo servirà ad evitare il login della rete – quindi spreco di tempo – tutte le volte che si avvia un processo su Tor.
quindi alla fine dell’elenco inseriamo queste due stringhe:
Attiviamo adesso Squid da far congiungere con Polipo e DansGuardian.
Squid è l'ex IRCache e sono personalmente contento di aver conosciuto i soli due sviluppatori italiani,
E' composto da una repo centrale con il codice in FreeBSD quindi è, ovviamente, aperto a tutti.
Squid funziona semplicemente: basa la sua proxy-list su una autenticazione degli utenti tramite gli schemi Basic e Digest, poi li valida in SASL e partendo dal reverse proxy li monitora.
Praticamente filtra i contenuti che, basandosi una lista infinitamente grande e sempre aggiornata, possono o non possono sembrare fraudolenti e quindi li ricalca con una sfera protettiva che, nel gergo tecnico, viene denominata layer Comm I/O (livello commutativo ad input output).
Installiamolo dando:
che Squidcrea la sua cache in /var/cache/squid, a differenza di Polipo o di DansGuardian che utilizzano la root principale
ora configuriamolo andando in:
/etc/squid/squid.conf
trovando e modificando questi valori:
il primo http_access è la lista controllo che dà l'autorizzazione ad utilizzare il proxy, di default soltanto il localhost è accettato ad accedervi, ma per motivi di testing noi lo cambieremo. Il secondo dà una configurazione anti-testing che vieta a chiunque di accedere al nostro proxy.
Come ultima istanza, cambiamo il visible_hostname.
Cerchiamocelo e diamo il nome che vogliamo, il più fantasioso possibile.
visible_hostname eryuga
Questo sarà il nome che comparirà nello status e nel messaggio d’errore.
Et voilà, avremo il nostro amato Tor Bundle personalizzato nei minimi dettagli e pronto per navigare ed esasperare il governo degli Stati Uniti D’America.
Un po’ come chiedere più sicurezza all’interno di una stazione di polizia.
In effetti la domanda non è del tutto matta o fuori controllo, qualcosa sotto c’è.
Ci si addentra in questo limbo per svariati e innumerevoli motivi e nessuno di questi andrebbe riconosciuto come “condivisibile” perché la privacy non è una opzione e proprio per questo motivo forse mi trovo qui a scrivere questa “guida”.
Tratteremo l’argomento senza pregiudicare nulla, bene o male che sia, i modi per proteggersi, a discapito del perché lo si fa, restano questi.
Premessa:[/B nessuno di questi modi fungerà da giubbotto antiproiettile, Tor non ha queste capacità e, se non lo aveste già capito da soli, la sicurezza in Internet non è mai davvero impenetrabile. Ci si può per tanto avvicinare, ma ricordiamoci che mettere la propria vita privata in mano ad una serie di numeri e variabili può risultare letale se non si prendono le giuste precauzioni.
Esistono diverse maniere per configurare al meglio la vostra personale sicurezza, credo che in ognuno di questi metodi una buona tecnica è sempre di conforto.
Cominciamo dal Tor Bundle che fino a qualche anno fa si poteva scaricare virtualmente sul sito ufficiale e che oramai da un po’ di tempo risulta difficile trovare – perché? Probabilmente perché tenere aggiornato un pacchetto è meno comodo di tenere aggiornato singolarmente un software e una shell assestante.
Il bundle comprendeva questi tre piccoli software:
Vidalia – un’interfaccia grafica per gli utenti base.
Privoxy – un talentuoso web proxy che molto spesso viene affiancato a Squid, entrambi in sincrono si occupano della gestione dei cookies sul controllo degli accessi – entrambi compatibili con SOCKS e distribuiti in licenza GPL.
Turbutton – piccola estensione per il controllo dei proxy automaticamente installata in Vidalia.
Io consiglio anche un altro caching web proxy: Polipo – il mio preferito.
Per quest’ultimo soltanto le versioni superiori alle 1.0.4 accettano SOCKS, quindi attenzione.
Non scriverò di come installarli uno ad uno perché i modi sono tanti e ognuno potrebbe trovarsi meglio “creandosene” direttamente uno specificatamente costruito per le proprie esigenze. Renderò invece disponibile la mia personale configurazione server, sperando possa esservi utile.
Privoxy è la mia prima scelta, si tratta di un proxy quasi totalmente strutturato seguendo le linee guida dei protocolli HTTP ed HTTPS che permette una configurazione estremamente accurata delle proprie regole, flessibile e saldo come una roccia, la sua installazione è una delle più semplici di questo bundle.
Io consiglio di abilitare nel vostro OS un dualboot con un ambiente UNIX qualsiasi, dove Tor è più libero di esprimersi e dove la gestione dei pacchetti è drasticamente più aperta di quanto non lo sia in Windows.
Se siamo su OSX – come nel mio caso – apriamo il terminale e diamo:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Questo servizio è controllato da un apposito script che troveremo in /etc/init.d – sempre all’interno di /etc/ troveremo il file di configurazione, teniamolo d’occhio.
Dopo aver lanciato Privoxy, dobbiamo fare in modo che Tor si accorga di lui e viceversa.
Apriamo Firefox – non mi dite che stavate utilizzando chrome per navigare insieme a Tor – e andiamo su “Modifica/Preferenze”, quindi su “Impostazioni connessione”.
A questo punto bisogna indicare l’indirizzo di start-line che sarà 127.0.0.1 e la porta 8118 che fungerà da proxy HTTP ed SSL.
Ora tocca alla gestione delle config.
Torniamo in /etc/ e andiamo su /privoxy/config/, apriamolo e spostiamoci sulla riga 661.
Avremo di fronte la stringa listen-address che ci permette di variare i parametri dell’indirizzo a cui Privoxy è collegato.
Possiamo variarli in base alle nostre esigenze, io solitamente lascio tutto invariato.
Un piccolo trucchetto: l’user-defined è molto importante.
Spostiamoci su /etc/privoxy e modifichiamo il file user-defined, editiamolo da root e cerchiamo al suo interno la stringa { allow-ads }.
Questa stringa è molto importante per il set-domain del nostro bundle perché l’user-defined permette a Privoxy di sapere quali siano i contenuti bloccati (una sorta di adblock in miniatura).
Per aggiungere un sito specifico, inseriamo sotto { allow-ads } il sito che desideriamo proteggere dal block seguito da un punto (.sciax2.it) quindi riavviamo Privoxy.
Privoxy è un root-server, ricordiamolo, tutti i dati inviati a Tor non oltrepassano la Exit Node ma vengono rinviati con un modulo ancor più criptato a Privoxy, che li esamina e li modifica prima di inviarli completamente in rete.
Ora passiamo al mio preferito: Polipo.
Polipo nelle versioni attuali di Tor si comporta un po' diversamente da come accordato agli inizi, è infatti passato da un progetto assestante ad una specie di protesi artificiale che accompagna la nostra cipolla in tutte le nuove release. Per questo motivo bisogna prima riconfigurare l'avvio automatico settato di default in Tor e poi reinstallare Polipo in maniera del tutto distaccata da Tor stesso.
Polipo è il più piccolino fra i suoi "connazionali", utilizza la versione integrata dell'HTTP/1.1 per uno stream e un pipelining che supporta anche in locale (e che se lo si fa giochicchiare con Squid è ancora più divertente perché entrambi hanno un completo supporto all'IPv6 e con un po' di immaginazione li si può utilizzare per ridurre ancor di più la latenza dei vari servizi).
Da terminale, diamo:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
quindi inseriamo al posto della configurazione che trovate, quella che vedete in questo git:
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
Facciamo partire il daemon dando:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
creiamo la directory delle cache dando:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
e quindi installiamo la nuova configurazione:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
poi, se proprio vogliamo – per evitare problemi ed inconvenienti con le porte principali, in /etc/polipo/config inseriamo:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
e finisce qui.
Come penultimo stadio di protezione io mi sono sempre affidato anche a DansGuardian, che è una buonissima alternativa a tanti web content filter che si trovano un po’ dappertutto. Unire questi tre progetti (Squid/Polipo, Privoxy e DansGuardian) è una grande accoppiata.
Praticamente la famiglia perfetta. :soso:
Ricordiamo che DansGuardian utilizza la porta 8123 quindi dovrà essere riconfigurata per Polipo.
Scarichiamolo dando:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Ora dovremmo cambiare le porte per renderle compatibili con Squid e Polipo.
Cerchiamoci le stringhe denominate filterport e proxyport e cambiamo le porte con:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
E adesso daremo il default “proxy” per entrambi i daemon utente e gruppo, questo servirà ad evitare il login della rete – quindi spreco di tempo – tutte le volte che si avvia un processo su Tor.
quindi alla fine dell’elenco inseriamo queste due stringhe:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Attiviamo adesso Squid da far congiungere con Polipo e DansGuardian.
Squid è l'ex IRCache e sono personalmente contento di aver conosciuto i soli due sviluppatori italiani,
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
e Perfavore,
Entra
oppure
Registrati
per vedere i Link!
.E' composto da una repo centrale con il codice in FreeBSD quindi è, ovviamente, aperto a tutti.
Squid funziona semplicemente: basa la sua proxy-list su una autenticazione degli utenti tramite gli schemi Basic e Digest, poi li valida in SASL e partendo dal reverse proxy li monitora.
Praticamente filtra i contenuti che, basandosi una lista infinitamente grande e sempre aggiornata, possono o non possono sembrare fraudolenti e quindi li ricalca con una sfera protettiva che, nel gergo tecnico, viene denominata layer Comm I/O (livello commutativo ad input output).
Installiamolo dando:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
che Squidcrea la sua cache in /var/cache/squid, a differenza di Polipo o di DansGuardian che utilizzano la root principale
ora configuriamolo andando in:
/etc/squid/squid.conf
trovando e modificando questi valori:
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
il primo http_access è la lista controllo che dà l'autorizzazione ad utilizzare il proxy, di default soltanto il localhost è accettato ad accedervi, ma per motivi di testing noi lo cambieremo. Il secondo dà una configurazione anti-testing che vieta a chiunque di accedere al nostro proxy.
Come ultima istanza, cambiamo il visible_hostname.
Cerchiamocelo e diamo il nome che vogliamo, il più fantasioso possibile.
visible_hostname eryuga
Questo sarà il nome che comparirà nello status e nel messaggio d’errore.
Et voilà, avremo il nostro amato Tor Bundle personalizzato nei minimi dettagli e pronto per navigare ed esasperare il governo degli Stati Uniti D’America.
Cosa sono i siti .onion, quanti sono e come aprirne uno?
Dichiarare che un sito in Tor sia un sito web qualsiasi è quasi compromettente per certi versi.
Innanzitutto la gestione richiede un approccio e una consapevolezza molto differente, gli strumenti fondamentali per la creazione di un .onion molto spesso non sono gli stessi che un utente medio utilizzerebbe per la creazione di un dominio qualsiasi in clearnet e questa è una considerazione da fare e da non prendere sottobraccio.
La natura di un .onion è cifrata, così come tutto il suo interno, l’URL è basato su una strumentazione TLD generalmente non-mnemonica di 16 caratteri alfa-semi-numerici che si generano automaticamente basandosi su una chiave pubblica spedita dalla Exit Node.
Questi 16 caratteri sono per lo più formati da lettere dell’alfabeto non-ASCII e numeri decimali da 2 a 7 cifre che in totale rappresentano 80-bit numerici in base32.
In Tor negli ultimi dieci anni sono stati aperti più di 810 milioni di siti e chiusi quasi altrettanti.
Probabilmente la visione globale di questo insieme è imprescindibile in quanto si arriverebbero a numeri incontrastabili, praticamente il 90% in più della nostra attuale comprensione dell’Internet – quindi molto più di una decina di miliardi di siti e pagine non rintracciabili.
Il procedimento per la creazione di un sito .onion può sembrare complicato e di una sofisticatezza elevata, ma fondamentalmente il lavoro è da ridursi a due semplici ed efficaci alternative.
La prima è Tor, la seconda è un server.
Esatto, bastano queste due cose e il gioco è fatto.
Un sito .onion non basa la propria sopravvivenza verso un server esterno, il sito che creerete resterà in locale sul vostro computer e soltanto da Tor potrà essere visualizzato, pur mantenendosi integro nel vostro sistema – la modificazione e l’aggiornamento verrà infatti “addomesticato” in quanto la velocità non sarà quella a cui sareste abituati in clearnet – immagino voi lo sappiate.
Inutile dirvi che il computer sulla quale hosterete il vostro .onion dovrà essere una bambola vudù da sacrificare, spoglio di ogni provvista ed unicamente selezionato per il vostro sito. Questo perché utilizzare un computer che utilizzate da tanto tempo, con un disco rigido che vi ha assistito per anni ed un hardware non propriamente nuovo può risultare pesantemente rischioso in quanto le fonti di tracciabilità in questi ultimi dettagli potrebbero essere maggiori.
Cominciamo.
Scegliamo uno dei vari server, fra Apache, Savant, THDD, Wamp e tanti altri io ho sempre basato i miei piccoli progetti su quest’ultimo.
Rechiamoci su Wamp, se siete su Windows prima scarichiamo ed installiamo Visual Studio da qui:
– In Windows alcune .dll potrebbero mancare ed installare l’ultima versione di VS è utile –
Quindi installiamo il tutto e torniamo su Wamp.
Scarichiamolo da qui:
Ora installiamolo.
Per la guida completa a questa specifica creazione – non è per niente difficile, anzi – vi lascio questo sito in basso che velocemente vi spiegherà tutto.
Farlo io implicherebbe una grossa scomodità e questo è anche uno dei motivi per la quale non ho inserito alcuna immagine in questa guida – cosa che dovrei fare se volessi anche spiegarvi questo.
Questo è il sito, e ringrazio citando la fonte:
Innanzitutto la gestione richiede un approccio e una consapevolezza molto differente, gli strumenti fondamentali per la creazione di un .onion molto spesso non sono gli stessi che un utente medio utilizzerebbe per la creazione di un dominio qualsiasi in clearnet e questa è una considerazione da fare e da non prendere sottobraccio.
La natura di un .onion è cifrata, così come tutto il suo interno, l’URL è basato su una strumentazione TLD generalmente non-mnemonica di 16 caratteri alfa-semi-numerici che si generano automaticamente basandosi su una chiave pubblica spedita dalla Exit Node.
Questi 16 caratteri sono per lo più formati da lettere dell’alfabeto non-ASCII e numeri decimali da 2 a 7 cifre che in totale rappresentano 80-bit numerici in base32.
In Tor negli ultimi dieci anni sono stati aperti più di 810 milioni di siti e chiusi quasi altrettanti.
Probabilmente la visione globale di questo insieme è imprescindibile in quanto si arriverebbero a numeri incontrastabili, praticamente il 90% in più della nostra attuale comprensione dell’Internet – quindi molto più di una decina di miliardi di siti e pagine non rintracciabili.
Il procedimento per la creazione di un sito .onion può sembrare complicato e di una sofisticatezza elevata, ma fondamentalmente il lavoro è da ridursi a due semplici ed efficaci alternative.
La prima è Tor, la seconda è un server.
Esatto, bastano queste due cose e il gioco è fatto.
Un sito .onion non basa la propria sopravvivenza verso un server esterno, il sito che creerete resterà in locale sul vostro computer e soltanto da Tor potrà essere visualizzato, pur mantenendosi integro nel vostro sistema – la modificazione e l’aggiornamento verrà infatti “addomesticato” in quanto la velocità non sarà quella a cui sareste abituati in clearnet – immagino voi lo sappiate.
Inutile dirvi che il computer sulla quale hosterete il vostro .onion dovrà essere una bambola vudù da sacrificare, spoglio di ogni provvista ed unicamente selezionato per il vostro sito. Questo perché utilizzare un computer che utilizzate da tanto tempo, con un disco rigido che vi ha assistito per anni ed un hardware non propriamente nuovo può risultare pesantemente rischioso in quanto le fonti di tracciabilità in questi ultimi dettagli potrebbero essere maggiori.
Cominciamo.
Scegliamo uno dei vari server, fra Apache, Savant, THDD, Wamp e tanti altri io ho sempre basato i miei piccoli progetti su quest’ultimo.
Rechiamoci su Wamp, se siete su Windows prima scarichiamo ed installiamo Visual Studio da qui:
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
– In Windows alcune .dll potrebbero mancare ed installare l’ultima versione di VS è utile –
Quindi installiamo il tutto e torniamo su Wamp.
Scarichiamolo da qui:
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
Ora installiamolo.
Per la guida completa a questa specifica creazione – non è per niente difficile, anzi – vi lascio questo sito in basso che velocemente vi spiegherà tutto.
Farlo io implicherebbe una grossa scomodità e questo è anche uno dei motivi per la quale non ho inserito alcuna immagine in questa guida – cosa che dovrei fare se volessi anche spiegarvi questo.
Questo è il sito, e ringrazio citando la fonte:
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
La "guida" finisce qui, ci ho messo due giorni a compierla e chiedo scusa all'utente citato ad inizio pagina per averci messo così tanto.
Spero vi sia state d'aiuto. Per qualunque domanda, io sono qui.