- tor-dev - lists.torproject.org

Student project to work on IPv6 support (was: [tor-relays] About relay size)
by Santiago R.R. 06 Dec '17

06 Dec '17

(Moving this thread from tor-relay) El 03/10/17 a las 14:25, teor escribió: > > > On 3 Oct 2017, at 10:57, Roman Mamedov <rm(a)romanrm.net> wrote: > > > > On Tue, 3 Oct 2017 09:53:46 -0400 > > teor <teor2345(a)gmail.com> wrote: > > > >>> For interposing dual-protocoled nodes along the way, how many do there > >>> have to be for it to become "not too limiting"? > >> > >> This is one of the questions we need researchers to answer. > > > > I can't help but feel you are overcomplicating this. > > > > Clients create a circuit by randomly picking 3 nodes out of the all-nodes > > pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over > > IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are > > IPv4-only, the whole selection can be thrown away and repeated. > > > > That way IPv6-only relays could get some usage on a totally random basis, with > > no compromises and no restraining "of the next hop based on the previous one", > > not hurting anonymity. Clients just need to know which nodes are IPv4-only, > > IPv6-only or dual-stack, to not attempt unworkable combinations, discarding > > them instead. > > Discarding unworkable combinations and restraining node choices seem > equivalent to me, although the relay weights may be different. > > > And as there are more and more dual-stack or IPv6-only relays, the "throw > > away" step will be needed less and less often. > > If you think this will work and is safe for client anonymity, then the next step > is to write a tor proposal. Having a concrete design could help with > analysing the anonymity implications as well. > > I think IPv6-only relays are a lower priority than better IPv6 and dual-stack > client support, and IPv6-only bridge support But we could do both in the > same release. Hello tor-dev, With my colleague JC Bach (in CC), we have proposed a last-year student project to address IPv6-related issues in Tor for the upcoming semester, at IMT Atlantique engineering school. There will be two students working on it. It is hard to say now how far we will arrive, especially because this is our first approach to Tor entrails. So this message is to say we have good chances to come back here looking for help :-) Cheers, -- Santiago

2 4

Rebooting work on proposal #247 (guard discovery)
by George Kadianakis 06 Dec '17

06 Dec '17

Hello Mike, I'm finally getting out of the prop224/microdescriptor bug pile, and getting more time to start working on guard stuff like prop247 again. I'm planning to spend a few days next week to regain knowledge on prop247. I'll check out the notes from the Wilmington hackfest, re-read my old simulator's code, etc. I know you have thought more about prop247 the past months, and it would be great if you could brief me up on any updates that I should know about. Specifically I'm wondering if you have any new insights on how the proposed prop247 changes interact with Tor's guard algorithm (prop271)? Also any other things I should know about from your work on the performance simulator? Perhaps ideas about performance, topology or path restrictions? I'm hoping that such updates might help me boot up faster! Cheers! :-)

2 2

Names for your Onions: Onion addresses in SSL certificates
by heddha 06 Dec '17

06 Dec '17

Dear list, I wrote an addon as a PoC for idea 3 of the blogpost in [0]. The idea was to extend the Tor Browser by a means of reading out the C/O/S/L fields of the SSL certificate, and, if a website contains an onion address in one of those fields, to automatically redirect users to it. As the web-extensions API doesn't contain a means of reading out certificate information [1], I implemented it as an add-on. You can find it here: [2]. As stated in the blog post, all fields mentioned above could theoretically be filled with an onion address. Unfortunately, I found a large drawback: A certificate from Letsencrypt doesn't contain the C/S/O/L fields, as Letsencrypt performs a validation of required fields only, and the subject field isn't required. All unvalidated fields are by default not included in the certificate [3]. It is therefore not possible to include an onion address in the proposed fields using Letsencrypt; these are only filled when extended validation is performed (during which the correctness of the entries seems to be validated as well). Non-organisational suppliers of websites will therefore not be able to include their onion addresses in their normal certificate, which will most likely limit the amount of certificates containing onion addresses to a few larger organisations (if any). To make this idea actually usable for a large amount of people, one would have or to use another field, the content of which is neither checked nor deleted from a certificate, or introduce a new field =) Kind regards, heddha [0]: https://blog.torproject.org/cooking-onions-names-your-onions [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1322748 [2]: https://github.com/heddha/sslOnions [3]: https://community.letsencrypt.org/t/maintain-subject-records-country-etc-in…

1 0

Start contributing to Tor
by Aruna Maurya 04 Dec '17

04 Dec '17

I am new to the community and would like to contribute and help along. I did a complete read up on how the Tor browser works, but I would like to delve in more and get acquainted with the code base, so that I understand and learn a lot in the process. I already cloned and built the Tor(core) and TorBrowser from source for easy understanding and primarily as it would help me to reproduce bugs as I work on them. Any further guidance is appreciated. Thankyou for spending the time to read this through. -- Regards, Aruna Maurya, CSE,B.tech, Blog <https://themindreserves.wordpress.com/> | Medium <https://medium.com/@arunamaurya>

3 4

Running Tor with a 15MB memory limit
by Nathan Freitas 04 Dec '17

04 Dec '17

I am currently supporting the iCepa project, an effort to get Tor to run as a Network Extension VPN on iOS. https://github.com/iCepa/iCepa The good news is that, after a long time, we have the whole thing somewhat working. The bad news is that after browsing a few pages through Tor, the extension is shutdown due to going over the extremely tiny 15MB available heap. More on this at: https://forums.developer.apple.com/thread/73148 https://developer.apple.com/documentation/networkextension My question is, does anyone else have experience running Tor within some extreme memory limits? Any guidance on configuring torrc for this? Any thoughts on build flags or changes that might reduce memory usage? We have already identified that the new compression features available in recent versions of Tor consume more memory, and we may have to disable those for now, for instance. Thanks for any thoughts! +n

2 1

Privacy Pass
by bancfc＠openmailbox.org 29 Nov '17

29 Nov '17

Hi. Are there any plans to include Privacy Pass addon in Tor Browser by default? Privacy Pass is the result of some great work by Ian and his team at University of Waterloo to spare Tor users the torture of solving infinite captchas from Cloudflare.[0][1] [0] https://privacypass.github.io/team/ [1] https://blog.cloudflare.com/privacy-pass-the-math/

4 3

[release] [protocol] Onionoo 4.4-1.8.0
by iwakeh 28 Nov '17

28 Nov '17

Hi there! Onionoo's protocol was extended and has a minor version jump to 4.4. Download available at: https://dist.torproject.org/onionoo/4.4-1.8.0/ Main protocol changes (also summarized in [0]): The version field, which was introduced in 4.1, is now available for bridges, too. The "recommended_version" parameter is provided as an additional search parameter. Details can be found in [1a], [1b], and [2]. The changes are already deployed on all onionoo.torproject.org instances and the update included an upgrade of the geoip data used in Onionoo. Reminder: a major *upcoming version* jump 5.0 lies ahead. Take note of the field "next_major_version_scheduled":"2017-12-17" in documents. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://metrics.torproject.org/onionoo.html#versions_4_4 [1a] https://metrics.torproject.org/onionoo.html#details_relay_recommended_versi… [1b] https://metrics.torproject.org/onionoo.html#details_bridge_recommended_vers… [2] hhttps://metrics.torproject.org/onionoo.html#parameters_search [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Tor and DNS
by N6Ghost 24 Nov '17

24 Nov '17

hi all, saw an open item in the tor projects, about dns and other resource record types. this got me thinking about just trying to understand Tor and DNS. for what I gather so far, is Tor and dns is only about "a" records and quad records "aaaa", thats pretty much it. i think PTR also but just whats need for hostname lookup. I am assuming this means tor clients, and tor browsers but have yet to validate that. any other info on this would be helpful. still trying to dig around and find where the data may be. -N6Ghost

1 0

rendezvous on non-OR circuit with purpose Acting as rendevous
by Ian Goldberg 23 Nov '17

23 Nov '17

I just restarted my node, and saw this in the log: Nov 23 14:07:21.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending) What does this mean? I'm a little worried someone out there is playing games with the protocol...

2 1

Proposal: Move IPv6 ORPorts to the Microdesc Consensus
by teor 21 Nov '17

21 Nov '17

Hi all, We would like to move IPv6 ORPorts from microdescriptors to the microdesc consensus. This makes it easier for IPv6 clients to bootstrap and choose reachable guards. The proposal is inlined below, it is also available with the corresponding dir-spec updates in my torspec branch bug23826-23828 on GitHub: https://github.com/teor2345/torspec.git The tor code that implements these new consensus methods is in my tor branch on bug23826-23828 on GitHub: https://github.com/teor2345/tor.git The parent ticket for these related changes is #20916. The code changes are being tracked in #23826 and #23828, and the spec changes and proposal in #23898: https://trac.torproject.org/projects/tor/ticket/20916 If we've spoken about this, and I've left you out as an author, please let me know! Here is the proposal text: Filename: xxx-ipv6-in-micro-consensus.txt Title: Move IPv6 ORPorts from microdescriptors to the microdesc consensus Author: Tim Wilson-Brown (teor) Created: 18-Oct-2017 Status: Open Target: 0.3.3.x 1. Summary Moving IPv6 ORPorts from microdescs to the microdesc consensus will make it easier for IPv6 clients to bootstrap and select reachable guards. Since consensus method 14, authorities have voted for IPv6 address/port pairs (ORPorts) in "a" lines. Unreachable IPv6 ORPorts are dropped from the full consensus. But for clients that use microdescriptors (the default), IPv6 ORPorts are placed in microdescriptors. So these clients can only tell if an IPv6 ORPort is unreachable when a majority of voting authorities mark the relay as not Running. This proposal puts reachable relay IPv6 ORPorts in an "a" line in the microdesc consensus. This allows clients to discover unreachable IPv6 ORPorts, even if a minority of voting authorities set AuthDirHasIPv6Connectivity 1. 2. Proposal We add two new consensus methods, here represented as M and N (M < N), to be allocated when this proposal's implementation is merged. These consensus methods move IPv6 ORPorts from microdescs to the microdesc consensus. We use two different methods because this allows us to modify client code based on each method. Also, if a bug is discovered in one of the methods, authorities can be patched to stop voting for it, and then we can implement a fix in a later method. 2.1. Add Reachable IPv6 ORPorts to the Microdesc Consensus We specify that microdescriptor consensuses created with methods M or later contain reachable IPv6 ORPorts. 2.2. Remove IPv6 ORPorts from Microdescriptors We specify that microdescriptors created with methods N or later do not contain any IPv6 ORPorts. 3. Retaining Existing Behaviour The following existing behaviour will be retained: 3.1. Authority IPv6 Reachability Only authorities configured with AuthDirHasIPv6Connectivity 1 will test IPv6 ORPort reachability, and vote for IPv6 ORPorts. This means that: * if no voting authorities set AuthDirHasIPv6Connectivity 1, there will be no IPv6 ORPorts in the consensus, * if a minority of voting authorities set AuthDirHasIPv6Connectivity 1, unreachable IPv6 ORPort lines will be dropped from the consensus, but the relay will still be listed as Running, * if a majority of voting authorities set AuthDirHasIPv6Connectivity 1, relays with unreachable IPv6 ORPorts will be dropped from the consensus. We will document this behaviour in the tor manual page, see #23870. 3.2. Full Consensus IPv6 ORPorts The full consensus will continue to contain reachable IPv6 ORPorts. 3.3. Clients that use Full Descriptors Tor clients that use full descriptors already ignore unreachable IPv6 ORPorts, and have done so since at least 0.2.8.x. 4. Impact and Related Changes 4.1. Directory Authority Configuration We will work to get a super-majority (75%) of authorities checking relay IPv6 reachability, to avoid Running-flag flapping. To do this, authorities need to get IPv6 connectivity, and set AuthDirHasIPv6Connectivity 1. 4.2. Relays and Bridges Tor relays and bridges do not currently use IPv6 ORPorts from the consensus. We expect that 2/3 of authorities will be voting for consensus method N before future Tor relay or bridge versions use IPv6 ORPorts from the consensus. 4.3. Clients 4.3.1. Legacy Clients 4.3.1.1. IPv6 ORPort Circuits Tor clients on versions 0.2.8.x to 0.3.2.x check directory documents for ORPorts in the following order: * descriptors (routerinfo, available if using bridges or full descriptors) * consensus (routerstatus) * microdescriptors (IPv6 ORPorts only) Their behaviour will be identical to the current behaviour for consensus methods M and earlier. When consensus method N is used, they will ignore unreachable IPv6 ORPorts without any code changes. 4.3.1.2. IPv6 ORPort Bootstrap Tor clients on versions 0.2.8.x and 0.2.9.x are currently unable to bootstrap over IPv6 only connections when using microdescriptors. This happens because the microdesc consensus does not contain IPv6 ORPorts. When consensus method M is used, they will be able to bootstrap over IPv6 only connections using microdescriptors, without any code changes. 4.3.2. Future Clients 4.3.2.1. Ignoring IPv6 ORPorts in Microdescs Tor clients on versions 0.3.3.x and later will ignore unreachable IPv6 ORPorts once consensus method M or later is in use. (See #23827.) 4.3.2.2. IPv6 ORPort Bootstrap If a bootstrapping IPv6-only client has a consensus made with method M or later, it should download microdescriptors from one of the IPv6 ORPorts in that consensus. Previously, IPv6-only clients would use fallback directory mirrors to download microdescs, because there were no IPv6 ORPorts in the microdesc consensus. (See #23827.) 4.3.2.3. Ignoring Addresses in Unused Directory Documents If a client doesn't use a particular directory document type for a node, it should ignore any addresses in that document type. (See #23975.) 5. Data Size This change removes 2-50 bytes from the microdescriptors of relays that have an IPv6 ORPort, and adds them to reachable IPv6 relays' microdesc consensus entries. As of October 2017, 600 relays (9%) have IPv6 ORPorts in the full consensus. Their "a" lines take up 19 KB, or 33 bytes each on average. The microdesc consensus is 1981 KB, so this represents about 1% of its uncompressed size. Most tor clients are already running 0.3.1.7, which implements consensus diffs. We expect that most directory mirrors will also implement consensus diffs by the time 2/3 of authorities are voting for consensus method M. So we expect that this change will have a minimal impact, which is made even smaller by compression and consensus diffs. 6. External Impacts We don't expect this change to impact Onionoo and similar projects, because they typically use the full consensus. Metrics doesn't currently graph IPv6 usage in Tor, but would like to in future. -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

3 4