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.
[IT]
