English version below

[IT]

Cosa sta succedendo?

Presto smetteremo di offrire i nostri servizi anche su un Hidden Service Tor dedicato. Non vi preoccupate! Riuscirete ancora ad usare Tor con A/I, solo non passando per l’Hidden Service.

Abbiamo dovuto riconoscere che da un po’ di tempo non stiamo gestendo al meglio il nostro Hidden Service, e che non possiamo permetterci lo sforzo abbastanza considerevole di migliorare questa gestione. Questa decisione è stata ampiamente discussa all’interno del collettivo e siamo giunti alla conclusione che la soluzione migliore per noi e per i nostri utenti sia la dismissione dell’Hidden service.

Le ragioni che sottendono questa decisione sono squisitamente tecniche e le spieghiamo in dettaglio più avanti nel post, per quell@ abbastanza interessat@, ma si riducono a questo: abbiamo costruito la nostra infrastruttura di autenticazione in un modo che rende complicato supportare contemporaneamente “lo spazio dei nomi internet” e “lo spazio dei nomi .onion“. Questo sistema di autenticazione è fondamentale, perché offre una serie di meccanismi di sicurezza implementati dai browser moderni che riteniamo importante avere. Farli funzionare in entrambi i “mondi” ci richiederebbe un considerevole impegno a fronte di quello che crediamo sia un miglioramento limitato.

Potete ancora usare Tor con A/I (e vi incoraggiamo a farlo), visitando direttamente i nostri servizi www.autistici.org, mail.autistici.org o il nome appropriato, invece di usare il nostro vecchio indirizzo .onion, ricordando però di validare il certificato SSL!

Per la spiegazione tecnica dettagliata, continuate a leggere!

Perché ora?

Nessuno dei problemi di cui discuteremo più avanti è una novità, sono già stati ampiamente discussi e le persone che lavorano con Tor ne sono ben al corrente. Quindi perché questa decisione da parte nostra proprio adesso? In effetti il momento coincide con la dismissione dei vecchi Hidden Service V2, condizione che ci ha fatto valutare nuovamente la condizione del nostro Hidden Service che è stato ampiamente trascurato a seguito dell’ultima revisione architetturale dei nostri servizi di qualche tempo fa. Il nostro Hidden Service era in pessime condizioni: la sovrapposizione che ha con il layer SSL incoraggiava gli utenti a tenere pratiche di sicurezza malsane (ad esempio, ignorare completamente tale layer), e comunque il sito web non era utilizzabile attraverso l’indirizzo .onion. Abbiamo deciso di sistemare definitivamente questa situazione.

Qual è il problema?

In ciò che segue, assumiamo che abbiate una certa familiarità con concetti tecnici quali HTTP, cookie, funzionamento interno del browser, ecc.

Il cuore del problema nasce dallo stretto accoppiamento tra il dominio di sicurezza del browser e lo spazio dei nomi (quello internet e quello .onion accennato prima) usato per accedere ai servizi. La problematica nasce quando si prova a servire entrambi gli spazi di nomi contemporaneamente come nel caso di gruppi che, come noi, offrono gli stessi servizi via Internet e via Hidden Service.

Consideriamo il sistema di autenticazione che stiamo usando. Esso fornisce una funzionalità di single sign-on e, come molti servizi simili, si basa molto fortemente sui cookie e, ancora più problematicamente, sui redirect HTTP. Se l’endpoint che deve essere autenticato non ha cognizione dello spazio di nomi utilizzato per raggiungerlo, esso redirigerà ciecamente l’utente non autenticato verso il servizio di login su Internet (e non su quello .onion), commettendo una violazione di dominio che potrebbe essere molto indesiderata per l’utente. Aggiungere questa logica (la capacità di distinguere lo spazio dei nomi di origine) ad ogni endpoint autenticato necessita di una quantità di lavoro molto significativa da parte nostra, senza contare l’aumento di complessità del sistema. La conseguenza sarebbe di finire con due sistemi di autenticazione separati (e fondamentalmente incompatibili, come spiegato più avanti).

Questo stesso sistema di autenticazione offre la possibilità (e incoraggia) ad usare dei cosiddetti hardware token (dispositivi fisici) per l’autenticazione a due fattori. Anche questi dispositivi sono strettamente legati al dominio del sito visitato, quindi un utente dovrebbe registrare il proprio hardware token due volte per i due spazi di nomi. Ma questo non è possibile, perché all’atto della prima registrazione il sistema avrebbe già associato un hardware token all’account [to be clarified], quindi per poter fare il login adesso via Hidden Service c’è bisogno di un hardware token legato allo spazio dei nomi in chiaro. Problemi simili li avrebbero i password manager.

Al momento quindi fornire i nostri servizi via Hidden Service non è praticabile. Questa necessità di duplicare completamente il sistema di autenticazione risulterebbe in un sistema mal funzionante nel migliore dei casi e in uno insicuro nel peggiore. Ci siamo chiesti, di fronte alla considerevole quantità di lavoro necessaria per affrontare i problemi illustrati poc’anzi, se ne valesse la pena. Negli ultimi 10 anni l’ecosistema SSL delle Certification Authority è significativamente migliorato, sia perché molte più persone si affidano all’integrità dell’infrastruttura di certificazione sia grazie alla nascita di servizi come Letsencrypt. Forse affidarsi ad SSL è diventato meno irragionevole di un tempo.

Considerando le nostre risorse limitate, preferiamo non supportare il caso d’uso dell’Hidden Service, piuttosto che farlo in maniera impropria o errata. Questa decisione non è stata presa a cuor leggero, alcun@ di noi sono avid@ utenti di Tor.

Ritorneremo periodicamente su questa decisione e sui compromessi affrontati prima, e saremo felici di riconsiderare la nostra decisione, se le circostanze (tecniche e non solo) cambieranno in futuro. Se per esempio il naming layer API venisse nativamente supportato da Tor e da Tor Browser Bundle, potremmo più facilmente riconsiderare la nostra posizione.

Grazie per la pazienza e per il supporto.

Domanda: posso ancora usare Tor per connettermi ai vostri servizi?

Certamente! Stiamo solo sospendendo il nostro Hidden Service (servito su .onion). Sui vostri client che usano Tor, potete benissimo continuare ad usare i nostri servizi, solo sostituendo il .onion con i nomi dominio internet www.autistici.org, mail.autistici.org o il nome appropriato, e ricordando di validare i certificati SSL.

Domanda: e per quel che riguarda i servizi non web

L’obiezione è lecita: perché ritirare l’Hidden Service anche per quei servizi che non usano HTTP come trasporto (come ad esempio la chat XMPP e i servizi mail via IMAP/SMTP)? La dimensione del problema qui è minore, ma alcuni dei problemi menzionati prima si applicano anche in questo caso, in maggior parte a causa della sovrapposizione tra il layer SSL e quello Hidden Service per la gestione della fiducia. Preferiamo avere un unico approccio consistente nell’uso dei nostri servizi via Tor.

[EN]

What is happening

We will soon stop offering our services on a dedicated Tor Hidden Service address. Don’t worry, you will still be able to use Tor with A/I, just without the Hidden Service!

We’ve come to recognize that for a while now we haven’t been doing a great job at running Hidden Services, and that we can’t afford the (considerable) effort to do it well. This decision has been debated for some time in the collective, and we came to the conclusion that dismissing the Hidden Service is the best way forward for us and for our users.

The reasons behind this decision are technical and are explained in detail below, for those interested enough, but they boil down to this: we have built our authentication system in such a way that it would be difficult and cumbersome to support both “the Internet name space” and “the .onion name space”. We consider the authentication system very important, it offers a lot of modern browser safety features we care about. Making it function properly in both “worlds” would take considerable amount of work, for what we think would be very little gain.

You can, and should, still use Tor with A/I, just by using www.autistici.org, mail.autistici.org or the appropriate service name in place of the old .onion address, and remembering to validate the associated SSL certificates.

For the detailed technical explanation, see below!

Why now?

None of the following issues are new, as they all have been discussed already and the people working with Tor are familiar with them. So why are we taking this decision now? Well, the timing is coincidental with the deprecation of V2 Hidden Services, which made us consider again the state of our Hidden Service, which had been largely neglected since our latest architectural changes of a few years ago. This state wasn’t good: the overlap of Hidden Services and SSL encouraged the adoption by users of bad security practices (by ignoring the SSL layer), and the web site wasn’t functional at all. We decided that this situation had to be cleared up.

What is the problem

We’re going to assume familiarity with the technical concepts discussed here such as HTTP, cookies, inner workings of the browser, etc.

The problematic issues stem from the strict coupling between the browser’s security domains, and the namespace used to access the websites (the Internet one, or the .onion one). The issues arise once one tries to serve both namespaces at once, as it is the case for groups like ours who are offering the same services both on the Internet and on a Hidden Service.

Let’s consider the authentication system we are using. It provides single sign-on functionality, and like many similar systems, it relies heavily on cookies and, more problematically, on HTTP redirects. If the endpoint under authentication is not aware of the namespace used to reach it, it will blindly redirect the user to a non-onion login server, committing a domain violation which may be very undesirable for the user. Adding this awareness logic to each and every authenticated endpoint is a significant amount of work, and a noticeable increase in the overall complexity of the system. We would fundamentally end up with two separate (and largely incompatible, see below!) authentication systems.

The same authentication system makes use (and encourages) of hardware tokens for 2FA. These are also strictly bound to the web site’s domain name, so a user would need to register the same hardware token twice, once on the public site, once on the onion site. Except that they won’t, because now there’s a hardware token required for the second login, which can’t be validated on the other site yet! Password managers will have a similar problem.

Another surprising aspect in which namespace binding breaks our single sign-on system concerns logouts: the duplication of authentication systems would mean that, if you are logged in on both the public web site and the onion one, logging out from one will not log a user out from the other. This is not surprising if one considers that there is nothing that says that these two authentication systems are in fact related to the same website.

So, at the moment, serving our website over Hidden Service is not really an option. This complete duplication of the authentication system would result in a badly-functioning system at best, an insecure one at worst. When facing the considerable amount of work that it would take to solve the above-mentioned issues, and even if one is willing to ignore the impact of the associated increased complexity, it is worth asking if it would be worthwhile at all? In the last decade the SSL ecosystem of Certification Authority has significantly improved, both because a lot more people rely on the integrity of the certificate infrastructure and because of the appearance of services like Letsencrypt, so perhaps relying on SSL is less unreasonable now than it used to be.

Considering our limited resources, we prefer to not support the Hidden Service use case for the time being, rather than doing it badly and in a broken fashion. This decision has not been taken lightheartedly. Some of us are avid Tor users and support this technology.

We will periodically re-evaluate the trade-offs mentioned above, and will happily reconsider our decision if the circumstances (technical or otherwise) change in the future. For example, we will reconsider our decision if the naming layer API is supported natively by Tor and the Tor Browser Bundle.

Thanks for your patience and support.

Q: Can I still use Tor to connect to your services?

Absolutely yes! We are just suspending the .onion Hidden Service. Just use the Internet names for our services, www.autistici.org, mail.autistici.org or the appropriate service name in place of the old .onion address, with any Tor-enabled client, and remember to validate the associated SSL certificates.

Q: What about non-web services

The objection is legit: why take away the hidden service endpoint for those services that are not HTTP-based (like, for example, the XMPP chat service or the IMAP/SMTP email services). The problem space here is simpler, but some of the concerns mentioned above apply to these services too, mostly due to the overlap of the Hidden Service and SSL trust layers. And we would like to have one single consistent approach for using our services over Tor.

Starting with today, most of our services are reachable via a tor hidden service that is located at the address:

wi7qkxyrdpu5cmvr.onion

This service is still experimental (and may thus break from time to time); however you should be able to reach most of our services (site, user panel, webmail, irc server, jabber server) via this address by using an opportunely configured client.

—

Da oggi, la maggior parte dei nostri servizi sono raggiungibili tramite hidden service tor all’indirizzo

wi7qkxyrdpu5cmvr.onion

Questo servizio è attualmente in fase sperimentale (e quindi potrebbe non funzionare a tratti o su alcuni servizi); tuttavia dovreste essere in grado di raggiungere la maggior parte dei nostri servizi (sito, pannello utente, webmail, irc, jabber) da questo indirizzo con un client opportunamente configurato.

Sulla lista hackmeeting si e’ sviluppato un breve thread su un argomento interessante che avevo rimosso dalla testa, la crittografia omomorfica. Si tratta in pratica di trovare un sistema matematico computazionalmente efficiente per fare in modo che una modifica su un certo dato cifrato si rifletta sul dato in chiaro in maniera coerente: cifro P per ottenere C, moltiplico C per 2, se decifro 2C devo ottenere 2P. Il che renderebbe possibile modificare il dato in chiaro in maniera coerente senza prima decifrarlo e ricifrarlo in seguito.

Questa e’ la tesi che un paio di anni fa ha riportato in auge questa concetto

http://crypto.stanford.edu/craig/craig-thesis.pdf

La crittografia omomorfica e’ citata come uno dei dieci punti dello sviluppo prossimo ventuto dalla technology review, ci stanno investendo un po’ tutte le realta’ con interessi nel cloud computing. Da ibm che si e’ comprata direttamente l’autore della tesi, dalla microsoft (https://www.technologyreview.com/computing/38239),  a google (https://code.google.com/p/thep)

Due anni fa il tema era stato trattato dal scheiner nel suo blog in maniera piuttosto critica, sostenendo sostanzialmente che l’argomento era interessantissimo, ma che farne dei lanci commerciali era piuttosto pretestuoso e prematuro.(http://www.schneier.com/blog/archives/2009/07/homomorphic_enc.html)

Un giorno ho portato l’access point di casa in ufficio. Dopo averlo collegato alla rete dell’ufficio ho acceso uno smartphone (privo di GPS) e ho attivato la localizzazione geografica.

Dopo poco lo smartphone ha mostrato sulla mappa, con grande precisione, la posizione di casa mia. Non quella dell’ufficio in cui mi trovavo: quella di casa.

(altro…)

Google prospera dovunque la privacy venga sottovalutata: se il tuo comportamento è simile a quello della maggioranza degli utenti di Internet, Google sa di te molto più di quanto ti piacerebbe anche se usi i suoi servizi senza registrarti. In molti casi, grazie a servizi “invisibili” come Google Analytics, è possibile scoprire quali siti visiti anche senza che li cerchi con il motore di ricerca di Google, e se usi Gmail, anche il contenuto di tutti i tuoi messaggi viene registrato per trasformarti in una profilazione perfetta.

Per evitare che la tua vita venga profilata puoi fare due cose: cancellare i cookies ogni volta che chiudi il tuo browser oppure, se usi Firefox, installare GoogleSharing, un simpatico plugin facile da utilizzare, gratuito e open source che anonimizza qualunque uso dei servizi di Google che non richieda il log-in: ogni volta che usi Google, GoogleSharing devia la tua richiesta su un server separato, dove verrà raccolta assieme a quelle di tutti gli altri utenti prima di essere inoltrata a Google, che in questo modo non potrà capire da quale utente è arrivata la richiesta. (altro…)

Grazie a un tweet di Wu Ming siamo arrivati a scoprire un interessantissimo articolo sul blog degli storici del Friuli Occidentale che insegna come consultare il Casellario Politico Centrale del PNF (Partito Nazionale Fascista). Ovviamente attraverso l’articolo si scoprono un sacco di risorse archivistiche molto poco pubblicizzate, ma molto interessanti dal punto di vista storico e culturale. Ovviamente se ci fosse qualcuno ancora attento a un concetto così obsoleto come quello di storia e memoria, nell’eterno presente del Paese che Non C’è in cui viviamo e non prosperiamo.

Se volete essere gentili andate al link degli storici, altrimenti le istruzioni in breve sono queste: andate sul sito dell’Archivio dei Beni Culturali dello Stato sezione Casellario Politico e cliccate su Ricerca. Da lì potrete vedere se un vostro nonno o un vostro bisnonno erano della vostra stessa opinione riguardo a cosa fare delle camicie nere (un sol fascio e poi… ecc ecc.). Buon divertimento e buon salto nel vostro e nostro passato e presente!

La OpenNet Initiative ha come obbiettivo dichiarato quello di identificare e documentare le procedure di filtraggio e sorveglianza e promuovere un dialogo pubblico sul tema.
In quest’ottica ad inizio marzo ha lanciato Herdict Web, un progetto che si basa sul coinvolgimento del popolo della Rete ed ha lo scopo di monitorare in modo costate e globale l’accessibilità o meno di una risorsa Web.
Ricorrendo ad un addon di firefox si ha il modo di collaborare a tenere aggiornata una mappa che aggrega e compara le segnalazioni sui siti oscurati, mal funzionanti o momentaneamente irraggiungibili.
Uno strumento pratico e collaborativo che permette di riprendere, almeno in parte, il controllo della rete.

Volete sapere quanto siete unici e riconoscibili su internet quando navigate con il vostro browser?
Provate panopticlick e lo scoprirete, oltre a venire informati su come evitare il piu’ possibile questa unicita’.
Ci sono infatti due articoli scritti dall’EFF (questo e questo) che se non avete voglia di leggere perche’ non sapete l’inglese o semplicemente siete pigri si possono riassumere cosi’:

• usate torbutton (ovvero usate TOR, non ci stancheremo mai di ripeterlo)
• abilitate il “privacy browsing mode“

Quest’ultima con un paio di click e’ disponibile su tutti i maggiori browser. Per Firefox a questo link trovate le istruzioni su come abilitarlo. Per gli altri, chiedetelo al vostro motore di ricerca preferito

oggi girando per la rete mi sono imbattuto in un testo che contiene una serie di riflessioni comuni sull’annoso problema di reciproca comprensione tra chi usa Linux e chi ci vorrebbe passare, o si sente ripetere “passa a Linux” e non sa cosa sta scegliendo realmente.
Vi propongo il link all’originale e anche ad una traduzione in italiano.

Su nazione indiana hanno pubblicato la traduzione italiana della guida di Ethan Zuckerman intitolata “Scrivere un blog anonimo con wordpress e Tor”, pubblicata in origine da Global Voices.

Dall’introduzione:
“La libertà di espressione passa anche dalla possibilità di comunicare
proteggendo la propria identità, se necessario. Pubblico perciò qui una
guida tecnica scritta da Ethan Zuckerman per Global Voices, di cui ho
presentato le tecniche durante il convegno e-privacy 2009 a Firenze. ”

Raccogliamo dunque l’invito a leggerla, diffonderla e ripubblicarla partito dal traduttore che ringraziamo.
Per ora leggetela qui.