- tor-dev - lists.torproject.org

Proposal 285: Directory documents should be standardized as UTF-8
by Nick Mathewson 10 Jan '18

10 Jan '18

Filename: 285-utf-8.txt Title: Directory documents should be standardized as UTF-8 Author: Nick Mathewson Created: 13 November 2017 Status: Open 1. Summary and motivation People frequently want to include non-ASCII text in their router descriptors. The Contact line is a favorite place to do this, but in principle the platform line would also be pretty logical. Unfortunately, there's no specified way to encode non-ASCII in our directory documents. Fortunately, almost everybody who does it, uses UTF-8 anyway. As we move towards Rust support in Tor, we gain another motivation for standarding on UTF-8, since Rust's native strings strongly prefer UTF-8. So, in this proposal, we describe a migration path to having all directory documents be fully UTF-8. 2. Proposal First, we should have Tor relays reject ContactInfo lines (and any other lines copied directly into router descriptors) that are not UTF-8. At the same time, we should have authorities reject any router descriptors or extrainfo documents that are not valid UTF-8. Simultaneously, we can have all Tor instances reject all non-directory-descriptor directory documents that are not UTF-8, since none should exist today. Finally, once the authorities have updated, we should have all Tor instances reject all directory documents that are not UTF-8. (We should not take this step until the authorities have upgraded, or else the behavior of updated and non-updated clients could be distinguished.) 2.1. Hidden service descriptors' encrypted bodies For the encrypted bodies of hidden service descriptors, we cannot reject them at the authority level, and so we need to take a slightly different approach to prevent client fingerprinting attacks. First, we should make Tor instances start warning about any hidden service descriptors whose bodies, post-decryption, contain non-utf-8 plaintext. At the same time, we add a consensus parameter to indicate that hidden service descriptors with non-utf-8 plantexts should be rejected entirely: "reject-encrypted-non-utf-8". If that parameter is set to 1, then hidden service clients will not only warn, but reject the descriptors. Once the vast majority of clients are running versions that support the "reject-encrypted-non-utf-8" parameter, that parameter can be set to 1.

5 6

Re: [tor-dev] [tor-project] Intent to Minimise Effort: Fallback Directory Mirrors
by teor 09 Jan '18

09 Jan '18

Hi all, I'd like to move this thread to the tor-dev list. I made a list of Core Tor tickets at the end of this email. Let's talk about them on tor-dev. Here's some background: Rebuilding the fallback list takes a lot of effort! So I'm picking up this tor-project thread while the latest fallback rebuild is fresh in my mind. The rebuild took a day or two of my time for regular changes. And another day or two for once-off changes. We made a few changes to streamline the process: * atagar and I wrote scripts that make it easier to generate fallback lines, and get operator contact details [0] * pastly, atagar and irl helped out with code reviews and list format changes, which should make the list easier to read and parse * pastly and nickm helped out with fallback list updates and backport Having this help meant that I had time to make the process better. Thanks! But there's still more we can do: > On 29 Aug 2017, at 11:12, teor <teor2345(a)gmail.com> wrote: > >> On 28 Aug 2017, at 18:15, Linus Nordberg <linus(a)torproject.org> wrote: >> >> teor <teor2345(a)gmail.com> wrote >> Sat, 26 Aug 2017 22:39:52 +1000: >> >>> So I can't see any reasons to keep running opt-ins. >> >> Are we listing non-exits? > > Yes. Non-exits and under-used exits are the best fallback directory > mirrors, because they are under less load. > >> I suppose those might see a radical change in >> their "IP reputation" when they end up on the blocklists after the next >> ransomware attack. Exits are already in the lists. > > Yes, there is a higher risk that a fallback will end up on one of these > lists. But all public Tor relays are at risk of ending up on a list like > this. Because of the higher risk, we will continue to ask relay operators to opt-in [1]. So we need to find people to help with this process every 6-12 months. And make it more efficient. >> On 28 Aug 2017, at 19:34, Silvia [Hiro] <hiro(a)torproject.org> wrote: >> >> On 26/08/17 15:44, nusenu wrote: >>>>> use ContactInfo >>>>> as a way to collect the intention of relay operators to opt-in/opt-out >>>>> of the fallback directory mirrors list. >>>> This is a good idea, *if* we still think an opt-in is necessary. >>> >>> Isn't that way to collect operator intentions also useful in opt-out >>> mode? (instead of continuing to use emails) Or how do you plan to >>> collect the opt-out info? >> >> Why are emails preferred over other methods? Another options would be >> wrapping a script that ops can run to create a cyberpunk trac ticket and >> opt-out. This is probably easier than merging emails. But maybe we do >> not want to handle this through trac. >> >> I'd be happy to help w/ that eventually, and the fallback script. > > This is a good idea. > > At the moment, I take emails sent to me or tor-relays, and turn them > into trac comments or trac tickets. If we put it directly on trac, > anyone could handle the ticket. The most time-consuming part of the rebuild is the opt-in process. Here's what we do at the moment: [2] 0. Send an email to tor-relays to ask operators to opt-in 1. Run a script to find fallbacks whose details have changed, and email tor-relays to ask operators if their details are permanent Here are the most time-consuming steps: 2a. Receive personal emails and emails to the list with fallback details 2b. Generate an updated fallback line for each relay [0] 2c. Update the whitelist And these steps are quick: 3. Run the update script to generate a new list 4. Write a changes file 5. Announce the new list 6. Backport the list to all supported Tor versions Here are some things I'd like to change: Just have relay fingerprints in the fallback whitelist [3] The fallback script checks relay details, but it can just rely on Onionoo to say when the address last changed. This removes step 1 and step 2b. Add a torrc option and descriptor line to opt-in as a FallbackDir [4] This is inspired by nusenu's "ContactInfo" idea, and Hiro's "bot" idea. Having a descriptor line and torrc option gets us a more reliable implementation, and it's easier for relay operators to use. And there's no need for an email bot or trac bot. This removes step 2a and step 2c, for tor versions with this feature. For tor versions without this feature, we can use the simpler fingerprint list. Make the hard-coded authorities into a separate include file with a standard format [5] We'll also change the fallback file format (again, sorry!) to make them consistent. This makes it easier for stem, metrics-lib, and other Tor implementations to use the same authorities and fallbacks. This makes step 5 easier (for libraries that use fallbacks). Let's discuss these changes on the tor-dev list! T [0]: https://gitweb.torproject.org/tor.git/tree/scripts/maint/generateFallbackDi… https://gitweb.torproject.org/tor.git/tree/scripts/maint/lookupFallbackDirC… [1]: https://trac.torproject.org/projects/tor/ticket/24789 [2]: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectory… [3]: https://trac.torproject.org/projects/tor/ticket/24838 [4]: https://trac.torproject.org/projects/tor/ticket/24839 [5]: https://trac.torproject.org/projects/tor/ticket/24818 -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

2 2

Relay diversity master thesis
by Robin Descamps 07 Jan '18

07 Jan '18

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

3 2

Re: [tor-dev] A suggestion for differential private statistics gathering
by teor 07 Jan '18

07 Jan '18

Hi Eyal, Thank you for letting us know about your research. You've emailed an internal discussion list, so I'm going to direct all responses to the public tor-dev@ list. That is the list where we discuss changes to Tor. Please see my response below: > On 7 Jan 2018, at 20:31, Eyal Ronen <eyal.ronen(a)weizmann.ac.il> wrote: > > I am a PHD student, and have just published online a paper, that shows a protocol that I think might be relevant to the TOR network. > The protocol allows a server to privately learn information from a client, and is resilient to a situation where a malicious adversary wants to temper with the statistics. > The main use case in our paper is learning popular passwords, Are you aware of this password list? (It has no privacy apart from hashing the passwords, because the passwords are already publicly available in data breaches.) https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-… > but we believe that it might also be usable for other cases in the TOR network. As we do not know the needs and challenges in the TOR network, we would greatly appreciate any feedback from the TOR metrics community. I would be interested in an explanation of the tradeoffs between the 16 and 32 bit versions of the protocol. In particular, we may not be able to provide servers with 4 GB of RAM for the 32 bit protocol. What would we lose with a 16 bit version? Is a 24 bit version possible? > The paper is titles "How to (not) share a password: Privacy preserving protocols for finding heavy hitters with adversarial behavior" and can be found at https://eprint.iacr.org/2018/003 > > The abstract is: > "Bad choices of passwords were and are a pervasive problem. Most password alternatives (such as two-factor authentication) may increase cost and arguably hurt the usability of the system. This is of special significance for low cost IoT devices. > > Users choosing weak passwords do not only compromise themselves, but the whole eco system. For example, common and default passwords in IoT devices were exploited by hackers to create botnets and mount severe attacks on large Internet services, such as the Mirai botnet DDoS attack. > > We present a method to help protect the Internet from such large scale attacks. We enable a server to identify popular passwords (heavy hitters), and publish a list of over-popular passwords that must be avoided. This filter ensures that no single password can be used to comprise a large percentage of the users. The list is dynamic and can be changed as new users are added or when current users change their passwords. We apply maliciously secure two-party computation and differential privacy to protect the users' password privacy. Our solution does not require extra hardware or cost, and is transparent to the user. > > The construction is secure even against a malicious coalition of devices which tries to manipulate the protocol in order to hide the popularity of some password that the attacker is exploiting. We show a proof-of-concept implementation and analyze its performance. > > Our construction can also be used in any setting where one would desire to privately learn heavy hitters in the presence of an active malicious adversary. For example, learning the most popular sites accessed by the TOR network." Tor Proposals There is a current proposal to add privacy-preserving statistics to Tor using a scheme that's based on PrivCount: https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-with… PrivCount is limited to counters with integer increments, so we can't easily find the most popular site (the mode), or calculate the median. We discussed the proposal on tor-dev@, and decided that we could add more sophisticated statistics later. We would appreciate your feedback on the proposal. In particular, please let us know if there is anything we should change in the proposal to make it easier to extend with schemes like yours in future. Here is the proposal thread: https://lists.torproject.org/pipermail/tor-dev/2017-December/012699.html Anyone is welcome to submit Tor proposals, the process is described here: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt Related Research There was a paper at CCS 2017 that sounds very similar to your scheme: Ellis Fenske, Akshaya Mani, Aaron Johnson, and Micah Sherr. Distributed Measurement with Private Set-Union Cardinality. In ACM Conference on Computer and Communications Security (CCS), November 2017. Source: http://safecounting.com/ Can you explain how your scheme differs from PSC? There's a forthcoming paper at NDSS 2018 that measures a single onion site's popularity with differential privacy using PrivCount: Inside Job: Applying Traffic Analysis to Measure Tor from Within 25th Symposium on Network and Distributed System Security (NDSS 2018) Rob Jansen, Marc Juarez, Rafael Galvez, Tariq Elahi, and Claudia Diaz Source: https://onionpop.github.io/ But the measurement was limited to one site, because PrivCount can't calculate the modal value from set of samples. So I can see the advantages of a scheme like yours over PrivCount. Your Own Research And finally, if you do want to do research on the public Tor network, I would recommend contacting the Tor Research Safety Board for advice: https://research.torproject.org/safetyboard.html T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

Call for review of Tor Relay Guide (#24497)
by nusenu 05 Jan '18

05 Jan '18

Hi, since the instructions on the website on how to setup a Tor relay are lacking information and clear guidance we have been working on improving it. The current version lives in the wiki and it reached a point where it makes sense to get reviews. https://trac.torproject.org/projects/tor/wiki/TorRelayGuide If there are major changes you would like to see please discuss them on the ticket before proceeding in the wiki: https://trac.torproject.org/projects/tor/ticket/24497 looking forward to your feedback and reviews! thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

#24526: neeeds review: require ContactInfo+MyFamily for multi-relay operators
by nusenu 04 Jan '18

04 Jan '18

Hi, it would be great if someone could review this change so we can move forward on this topic: https://gitweb.torproject.org/nickm/tor.git/commit/?h=bug24526&id=fbb6f9a18… https://trac.torproject.org/projects/tor/ticket/24526#comment:7 thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Re: [tor-dev] Did tor-wiki-changes ML break?
by Damian Johnson 03 Jan '18

03 Jan '18

Hi nusenu. Yup, a CenturyLink technician is coming in a few hours to restore my connection. Note to self: losing home internet connectivity sucks. Cheers! -Damian from a coffee shop On Jan 3, 2018 2:38 AM, "nusenu" <nusenu-lists(a)riseup.net> wrote: Hello Damian, Damian Johnson: > Hi nusenu. Yup, I was just thinking about that. CenturyLink did some > work on my apartment's connection yesterday that knocked it offline. > Probably just needs the router to be rebooted but I'm visiting with > family through new years so the r2e instance will be unavailable until > then. are you planing to bring this functionality back any time soon? thanks for considering it, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_ _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

2 1

Did tor-wiki-changes ML break?
by nusenu 03 Jan '18

03 Jan '18

Hi Damian, it appears to be the case that wiki changes are no longer send to this ML. Could you have a look? https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-wiki-changes thank you! nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

3 7

trac.tpo issues
by nusenu 24 Dec '17

24 Dec '17

Hi, in the last few days trac says occasionally "Service Unavailable" and right now trac times out. Since we are currently (attempting to) work on a wiki page, this is somewhat blocking our edits. Has trac some known issue? I'm looking forward to a reachable and stable trac :) thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Rust rewrite help
by Ivan Mandura 24 Dec '17

24 Dec '17

Hello, My name is Ivan and I would like to help out with Rust rewrite. I'm a huge fan of both Rust and TOR. Recently, I spent some time in China and it made me realize the importance of a project like TOR. Have experience with low-level code, being in DB industry for a few years now. Any pointers would be of huge help :) Thanks, Ivan

3 4