- tor-dev - lists.torproject.org

[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

[release] Onionoo 6.2-1.16.0
by Iain Learmonth 08 Aug '18

08 Aug '18

Hi, Onionoo's protocol was extended and has a minor version jump to 6.2. Download available at: https://dist.torproject.org/onionoo/6.2-1.16.0/ Protocol changes (also summarized in [0]): Added an "as" field to details document, deprecated the "as_number" field, added an "as_name" parameter to search for relays by AS name, and added support for comma-separated lists in the "as" and the "lookup" parameters. Software changes are summarized in the changelog [1]. The changes are already deployed on all onionoo.torproject.org instances. Unfortunately there are two known bugs affecting this release that were not fixed before deployment: Timestamps in graph history documents are incorrectly formatted which is currently breaking graphs in relay search. No data is lost and the graphs will reappear once this is resolved. (See #27039 [2]) Reverse DNS names are still being looked up slowly and so are missing for most relays. (See #27050 [3]) Please direct comments and questions to the metrics-team mailing list [4]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://metrics.torproject.org/onionoo.html#versions_6_1 [1] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [2] https://bugs.torproject.org/27039 [3] https://bugs.torproject.org/27050 [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Reviewing Trac #18642 (Teach the OOM handler about the DNS cache)
by neel＠neelc.org 06 Aug '18

06 Aug '18

Hi tor-dev@ mailing list, I have a patch for Bug #18642 (Teach the OOM handler about the DNS cache) which I would like reviewed. The URL is here: https://trac.torproject.org/projects/tor/ticket/18642 (https://trac.torproject.org/projects/tor/ticket/18642) Originally, dgoulet chose he would review, but after no response on the patch, he has emailed me that he's on vacation until the 16th of August, hence the reason why I'm emailing here. I am really keen on getting this patch in, and if there's any Tor developer here, could someone please review and merge it? Thank You, Neel Chauhan === https://www.neelc.org/

3 3

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

06 Aug '18

We at Whonix are currently porting to (non-VM) physical builds on arm64 - specifically RPi3. While this is great for headless applications we are interested in GUI user adoption. Without Tor Browser for arm64 this won't be as safe as it can be. Can you please consider releasing builds for this hardware platform?

2 1

Tor Relay Guide Disagreements
by nusenu 03 Aug '18

03 Aug '18

Hi Vinícius, (moving this discussion to the tor-dev mailing list since this isn't limited to the OpenBSD ticket scope https://trac.torproject.org/projects/tor/ticket/26619#comment:14 ) Vinícius wrote: > you [nusenu] took over /FreeBSD, /BSDUpdates, and /OpenBSD and enabled the 'read- > only' mode all by yourself without even consulting the original author or > anyone else [...] > is there any particular reason why you enabled the read-only mode on > /FreeBSD, /BSDUpdates, and /OpenBSD? I think this a pretty odd behavior. > I'm sorry. if you do want to own all these pages (and many other more), > please tell us. The Tor Relay Guide wiki page [1] has been 'read-only' pretty much since we launched it, it has been decided a few months ago in [0]. Anyway read-only mode shouldn't affect you personally. Since you are listed on the tor people page I assume you can simply ask for the permissions to edit 'read-only' pages. I'd still ask you to open tickets for changes like your change to the FreeBSD page instead of applying them directly so we can discuss them before applying and to avoid the necessary efforts. On 2018-07-10 I split out the OS specific instructions into their subpages: /DebianUbuntu /FreeBSD ... because of this move content that was previously read-only until then became writable but that wasn't an intentional step. On 2018-08-02 you changed the FreeBSD page [4], here are two lines (examples) of your replacements: my text: change the nickname "myNiceRelay" to a name that you like Change the email address bellow and be aware that it will be published got replaced with: CHANGE THE NICKNAME WRITE YOUR EMAIL ADDRESS I'm not sure I would consider these replacements an improvement since they remove information without giving any reasoning for removing it in the comment. Besides the removal of information this also introduces inconsistency in the torrc file we used so far in the guide. I reverted your change and addressed the issue you brought up (net.inet.ip.random_id ordering, /etc/pkg/FreeBSD.conf modification) and made the content read-only again (like it was until 2018-07-10). > ggus is that page's [/OpenBSD] author and he allowed me to edit the contents of that > page (the same is also applied to the /FreeBSD page; There has been no comment by ggus on #26619 (/OpenBSD) for a month so I went ahead and assigned it to me, but I'll pull out of that ticket now. https://trac.torproject.org/projects/tor/ticket/26619 ggus didn't create /FreeBSD [3]. > should we always open tickets with suggestions? - sadly it > also sounds extra odd, because when I did open tickets (#27006 and > #27007), a few minutes later you changed contents all by yourself #27006 is about /DragonFlyBSD I've never touched that page? https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DragonFlyBSD?ac… #27007 was about creating /NetBSD - which you did. I didn't consider my change - where I replaced the ORPort to use 443 (because we used that port everytime that works out of the box on a platform) to be part of the "create the /NetBSD page": https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/NetBSD?action=d… Going forward I'd propose the following to minimize the fraction and overhead: I assume you maintain: /TorRelayGuide-ptbr /TorRelayGuide/OpenBSD /TorRelayGuide/NetBSD /TorRelayGuide/DragonFlyBSD I'll keep maintaining: /TorRelayGuide /TorRelayGuide/DebianUbuntu /TorRelayGuide/CentOSRHEL /TorRelayGuide/Fedora /TorRelayGuide/FreeBSD /TorRelayGuide/openSUSE All pages should be read-only and writable to authorized users/maintainer, but feel free to have the pages you maintain world writable. All non-maintainer changes are expected to go through a ticket. After a timeout of 7 days with no maintainer response the ticket opener might proceed with applying the proposed change. I'll propose a list of requirements for a platform to be listed on the main page. kind regards, nusenu [0] https://trac.torproject.org/projects/tor/ticket/24497 [1] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide [2] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD [3] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?action=… [4] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?sfp_ema… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2

WTF-PAD and the future
by George Kadianakis 03 Aug '18

03 Aug '18

Hello Mike, I had a talk with Marc and Mohsen today about WTF-PAD. I now understand much more about WTF-PAD and how it works with regards to histograms. I think I might even understand enough to start some sort of conversation about it: Here are some takeaways: 1) Marc and Mohsen think that WTF-PAD might not be the way forward because of its various drawbacks and its complexity. Apparently there are various attacks on WTF-PAD that Roger has discovered (SENDME cells side-channels?) and also the deep learning crowd has done some pretty good damage to the WTF-PAD padding (90%-60% accuracy?). They also told me that achieving needed precision on the timings might be a PITA. 2) From what I understand you are also hoping to use WTF-PAD to protect against circuit fingerprinting and not just website fingerprinting. They told me that while this might be plausible, there is no current research on how well it can achieve that. Are we hoping to do that? And what research remains here? How can I help? Which parts of the Tor circuit protocol are we hoping to hide? 3) Marc and Mohsen suggested using application-layer defences because the application-layer has much better view of the actual structures that are sent on the wire, instead of the black box view that the network layer has. In particular they were mainly concerned about onion services fingerprinting because they are part of a restricted closed world, whereas they were less concerned about the entire internet because of its vast size. They suggested that we could investigate using the service-side "alpaca" library for onion services (e.g. as part of securedrop?) which should resolve the most pressing concern of HS identification. 4) They also told me of research by Tobias Pulls which eliminates the needs for histograms in WTF-PAD and instead it samples from the probability distribution directly. They think that this can simplify things somewhat. Any thoughts on this? Let me know what you think. I still don't understand the entire space completely yet, so please be gentle. ;) Cheers! :)

5 7

Mentorship needed for beginner.
by Yogesh Singh 30 Jul '18

30 Jul '18

Hey, I'm an undergrad with CS majors and have developed interest for networking. I would like to contribute to the Tor projects. It would be of great help if someone could mentor me where to begin with. Regards, Yogesh

2 1

Re: [tor-dev] Entreaty for spreading awareness about ProxAllium, a useful frontend for Tor
by Damon (TheDcoder) 29 Jul '18

29 Jul '18

Thanks for the reply grarpamp! > People are free to create their own wiki account and add descriptions > and links to their tools / projects on the relavant wiki pages. I already have an account in Trac, however I was worried that editing the wiki to mention the appropriate tools would potentially count as advertising, so I didn't consider it before... > You probably want to go a few cycles of feedback and development > with users on the wiki and the tor-talk / tor-relays lists before ready > to having it appear on website "projects" list. I agree, but I am not sure where I should start with getting feedback as it is quite hard to find users of ProxAllium. > Projects that distribute binaries should of course be open source, > and reproducible per build instructions included with their source. This is also one of the cons of the programming language I am using (AutoIt) to develop ProxAllium. AutoIt uses tokenization during compilation which adds random data to the binary thus making it impossible to have reproducible builds. With Regards, Damon H. (TheDcoder) Sent with ProtonMail Secure Email.

2 2

Re: [tor-dev] tor-dev Digest, Vol 90, Issue 37
by flipchan 29 Jul '18

29 Jul '18

Great to hear :) I have created an issue on the project about randomly selecting a format as well as adding a custom format . If anyone have ideas of traffic pattern formats to be added I would love to help develop this , please come with ideas (Y) ~flipchan On July 28, 2018 12:00:03 PM UTC, tor-dev-request(a)lists.torproject.org wrote: >Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-dev digest..." > > >Today's Topics: > > 1. Multiple Formats in Marionette (John Helmsen) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 27 Jul 2018 18:24:07 -0400 >From: John Helmsen <john.helmsen(a)redjack.com> >To: flipchan(a)riseup.net, tor-dev(a)lists.torproject.org >Subject: [tor-dev] Multiple Formats in Marionette >Message-ID: > <CAFtdMkgNJdk5HpboKPczMSCD0+5d77idVutJjdSKcPqijPLSCQ(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >Flipchan, > >Thanks for letting me know about Layerprox. I hadn't heard of it >before. > >Currently, as you probably know, Marionette does one format at a time. >However, Marionette is hierarchical in its format construction, and >therefore we can do random selection between formats by considering >each >format as a 'sub-format' of the overarching format. Look at >web_sess443 in >our current release as a way that this might be done. > >As we continue to go forward we will be updating the formats. Exactly >when >depends on funding and other priorities. We recognize that an update >is >needed. You don't have to wait for us to do them, though. If you make >a >format we would be happy to consider it for integration in the >repository. > >If you want to put a wrapper around Marionette to give it extended >switching ability, we have implemented the PT2.X standard, so feel free >to >integrate it into your code that calls it. Just let us know that you >have >integrated it, so we can add you to our list of people that we have >integrated with. > >-- >John Helmsen >john.helmsen(a)redjack.com >C: (240) 899-5676 >

1 0