- tor-dev - lists.torproject.org

oss-fuzz Coverage
by Tom Ritter 29 Aug '18

29 Aug '18

tor is in OSS-Fuzz, and I recently found this very slick dashboard that shows you just what coverage tor is getting out of it: https://storage.googleapis.com/oss-fuzz-coverage/tor/reports/20180829/linux… Thought I'd share in case others hadn't seen it (I think it's fairly new.) -tom

1 0

Highlights from ACM SIGCOMM
by Iain Learmonth 27 Aug '18

27 Aug '18

Hi All, I attended ACM's SIGCOMM last week. A few things caught my attention that I thought might be of interest here: "CircuitStart: A Slow Start For Multi-Hop Anonymity Systems" Christoph Döpmann and Florian Tschorsch. Link: https://dl.acm.org/authorize?N666917 "Design of SOCKS Version 6" Vladimir Olteanu and Dragoş Niculescu. Link: https://dl.acm.org/authorize?N666057 Related Internet Draft: https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/ One thing about their design for SOCKS 6 is that is has options, and those options could be used to specify some sort of isolation property instead of overloading username/password. Thanks, Iain.

1 0

routing security handling in the tor network
by nusenu 27 Aug '18

27 Aug '18

Hi, I looked at the routing security state of the >3k BGP prefixes that make up the tor network [1]. I believe it is important for tor to have a discussion on how the network should deal with relays that will increasingly be only partially reachable due to the increase of RPKI route origin validation (ROV) in big IXPs (AMS-IX to name one). to quote the relevant part from [1]: > “Virtual” Route Origin Validation in the Tor Context > > The are two good reasons why Tor should care about relays located in > RPKI ‘Invalid’ prefixes: > > It will eventually break the “the Tor network is a full mesh” > assumption. Relays in such RPKI ‘invalid’ prefixes with no > alternative valid route will not be reachable from ASes performing > ROV, but the Tor network assumes that every relay can reach every > other relay. When ROV breaks that assumption it is better to exclude > these relays than to keep only partially reachable relays. An RPKI > ‘Invalid’ route might as well be an actual BGP hijacking attempt and > why not stop that? > > The obvious place to enforce ROV for the Tor network would be the Tor > directory authorities that would run RPKI validators and vote for > relays accordingly. At this point this is no more than an idea. There are certainly some challenges and trade-offs when doing ROV from a non-BGP-router perspective, but they are solvable. There is no need to panic - this affects less than 5 relays currently but we should have a discussion and reach some form of consensus on the topic to move forward instead of waiting until it significantly affects reachability. Would be nice to have an initial discussion even before writing a proposal to gather opinions if that would be actually worth doing. kind regards, nusenu [1] https://medium.com/@nusenu/how-vulnerable-is-the-tor-network-to-bgp-hijacki… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 1

Re: [tor-dev] Relay diversity master thesis
by Robin Descamps 22 Aug '18

22 Aug '18

Hello, I would like to share with you the master thesis I wrote this year on a topic concerning diversity in Tor, that I evoked earlier this year. I would like to thanks all the dev that have shared feedback with me about my thesis plan. This work may not be perfect, but could start/influence the research in the future hopefully. Here is the abstract and the access link: Tor is the most popular anonymous communication system nowadays, that set up a excellent compromise between anonymity and performance. However, Tor is by design vulnerable to end-to-end correlation attacks. Many techniques have been and are being developed in order to mitigate these attacks. This master thesis objective is to define the utility of a new relay, and to give a measure of its contribution to the diversity of the network. This is achieved with a modified version of the TorPS , which simulate the Tor network against both relay and network adversaries. More diversity means less end-to-end correlation attacks possible by the latter. At the end, we would like the volunteers to be aware of the utility they bring to the Tor network security with a certain relay configuration. https://dial.uclouvain.be/memoire/ucl/fr/object/thesis%3A14661<https://dial.uclouvain.be/memoire/ucl/fr/object/thesis:14661> Thanks, Robin Descamps Le 22 déc. 2017 à 01:23, Robin Descamps <robin.descamps(a)outlook.com<mailto:robin.descamps@outlook.com>> a écrit : Hello, I already sent this message to the metrics team, but they advice me to address it to the dev team, which seem to be more relevant. I realise this year a master thesis, in the Université catholique de Louvain in Belgium, about measuring the utility brought to the Tor network diversity by adding a new relay, according to its configuration. I added to this message my master thesis plan, as well as a poster that presents a summary of the key elements. May I ask you advices/feedback about this master thesis plan? Since I would like this project to bring a real contribution to the Tor development, I want to make sure that all the steps I will perform are useful and/or worth it. The master thesis plan: https://drive.google.com/open?id=1XEOSS29owavKJ_cJJAVaPiJe34Ez6XXx The poster: https://drive.google.com/open?id=1BlF2U-Kexyz6ihVSqvsVHv4PUsvXATc4 Thanks, Robin Descamps

2 2

Unable to access '#tor-dev' IRC Channel
by KUSHAL BORKAR 20 Aug '18

20 Aug '18

Greetings All, This is to inform you that, I, Kushal Borkar, IRC Alias 'Lashuk', am unable to access the '#tor-dev' IRC channel. I tried using Pidgin Internet Messenger to properly connect to the channel but I face the same problem: "Cannot join #tor-dev: Registration is required." I also checked whether I'm linked to the internet and also verified by using the command "/msg NickServ IDENTIFY". I cannot access the '#tor-dev' IRC channel on OFTC neither using my registered nick on desktop client nor through the web interface. I also tried OFTC IRC Service to check my Nickname which indicated me "An error occurred fetching the nickname data. It may be private or there may be a problem with the server." I eagerly want to discuss the specific project "Ahmia - Onion Service Search" and would like to know about the Outreachy Internship which starts from December to March. I politely request you all help me and direct me in the right direction in order to start thinking about what I could do for Tor. With Regards, *Kushal Borkar* *B.Tech - 4th Year,Electronics and Communication Engineering,IIIT Chittoor,Sri City-517588* Email Id*: kushal.b15(a)iiits.in <kushal.b15(a)iiits.in>*

2 1

[release] Onionoo 6.2-1.17.1
by Iain Learmonth 17 Aug '18

17 Aug '18

Hi, A patch release has been made for Onionoo to fix errors with the searching for relays with unknown AS numbers. Additionally, we announce today the fixes from version 6.2-1.17.0 which were released yesterday but not deployed as this additional patch was ready for release and so we postponed. This fixes issues with slow reverse DNS lookups. Download available at: https://dist.torproject.org/onionoo/6.2-1.17.1/ Software changes are summarized in the changelog [0]. The changes are already deployed on all onionoo.torproject.org instances. Not all reverse DNS names will be looked up immediately, but should all be present once the updater has run at least once 13 hours after the upgrade. Please direct comments and questions to the metrics-team mailing list [1]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Alternative directory format for v3 client auth
by George Kadianakis 14 Aug '18

14 Aug '18

Hello haxxpop and David, here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: https://github.com/torproject/torspec/pull/23 Thanks for making me edit the spec because it made me think of various details that had to be thought of. Let me know if you don't like it or if something is wrong. Cheers!

3 8

[release] Onionoo 6.2-1.16.1
by Iain Learmonth 13 Aug '18

13 Aug '18

Hi, A patch release has been made for Onionoo to fix an error in the serialization of history documents. Download available at: https://dist.torproject.org/onionoo/6.2-1.16.1/ Software changes are summarized in the changelog [0]. The changes are already deployed on all onionoo.torproject.org instances. In order to benefit from this fix immediately you may wish to follow the advanced instructions listed below. If you do not do this, then after a week you should find that the problem is resolved, it will just happen more slowly as the documents are rewritten. 1. Checkout commit 18e5c04 in karsten's task-27039 branch https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-27039… 2. Run ant jar to build the jar file at generated/dist/onionoo-6.2-1.16.0-dev.jar. (You will not need the war file built.) 3. Upload this jar file along with the jar and war files for the 6.2-1.16.1 release. 4. Wait for hourly updater to end. 5. Stop hourly updater and the web server. 6. Run java -jar onionoo-6.2-1.16.0-dev.jar --rewrite-only. 7. Remove the intermediate jar file to avoid confusion. 8. Re-start the web server and the hourly updater using the files from the 6.2-1.16.1 release. Please direct comments and questions to the metrics-team mailing list [1]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

[release] Onionoo 7.0 will be released after September 3, 2018
by Karsten Loesing 09 Aug '18

09 Aug '18

Hello tor-dev@, yesterday we announced Onionoo protocol version 6.2 that we released a few days before on August 3, 2018. One month later, after September 3, 2018, we're going to release Onionoo protocol version 7.0 which will make a couple backward-incompatible changes: - extend the "version" parameter to support lists and ranges, - remove redundant "1_week" and "1_month" graphs from clients documents, - change "3_months" graphs to "6_months" graphs in all documents containing history objects, - remove the "fingerprint" parameter, and - remove the previously deprecated "as_number" field from details documents. You can find more details on the Onionoo protocol page: https://metrics.torproject.org/onionoo.html If you're using any of these fields or parameters, be sure to either update your Onionoo client to support the new protocol version, or pester your Onionoo client developer to do that for you. On behalf of the Tor metrics team, Karsten

2 2

Tor Browser for arm64/v8 on RPi3
by procmem 08 Aug '18

08 Aug '18

@intrigeri I'll post there. Thanks for the heads up.

1 0