- tor-dev - lists.torproject.org

Namecoin resolution for Tor Prop279
by Jeremy Rand 05 Nov '17

05 Nov '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Tor devs, I've written up some documentation on using Namecoin with Prop279. This can be used for human-meaningful onion service names, as well as standard Namecoin A/AAAA/CNAME records. In theory, this can also be used with arbitrary non-Namecoin naming systems that speak the DNS protocol, although I haven't attempted to do so. Documentation is here: https://www.namecoin.org/docs/tor-resolution/ You can test it with this URL: http://federalistpapers.bit/ Curious what you all think of it -- please feel free to give feedback. Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ/5k5AAoJELPy0WV4bWVwlSEQAIeF5fiZUBsaiCGyxaDAz97b l4KVyEKAcPOKCvjryKMqGjxHJPfw9uJJY4x0hD4taXYHszfAMBayOs8EkWHd/eFq 3FDAGW2VaS29k9+y+URiIa9gI3H2et+HgwTOxwCk1O/B2l/2TmWWdGnyh8UCr1a1 yibzBRcamaaMyWwDg7gK0ZvN0WPGwCXiFxVC3fT37dKW2Ve9PwvqZEfsZ/i7eVN1 1Vb+o1Q11qe70yx7XQv3KUFpccU1UsIlR/C0hp0ISxAjV5CpMnN8Lu3/E8s0ViFL Z3PKL/cpbRltaPPdv8U0mMLy3KY+/u4yRtl2lmHejsNnCwA9gBrZ3XY9A81ZX/wD QKVBvHf7tO1FlbwKnz0Vb4aY2Ls09vRlXKAQ3zEWtXAT9pofH/dadfI3LYKykeAd +vuDjDOfsGrIVarn0vWqoVwf43P9iDuaDmk0hNDkbBieEcjIOYbuy3xXiMFxMjpF Na0StOMYsI1xSlyUqq6+MT5MRrGmh7zk5d8/PYAEdQM8mPJ6wOzgN98sEoGfZLE+ s1rbeZdMiJqne18G9ulUCh4DPOTyZ4K36oJoUAtr/JSt5IO9vGIrTElbw3BjYm6T 7bTeawoWoX+Lx+BJW+dDq57J2r91wwFZdHAqlbQhWvUi8IynVOVqsZUJbw+g9ioP BAzC5zPauEzD2/awtx/5 =0kqw -----END PGP SIGNATURE-----

1 0

v3 hidden services: inconsistencies between spec and implementation
by inkylatenoth 03 Nov '17

03 Nov '17

Whilst implementing v3 hidden services myself I found some inconsistencies between the specs and the current implementation. I wanted to share these in case someone from the Tor organization wants to update the specs and/or the implementation. # rend-spec-v3.txt ## 2.4 * after decrypting the `superencrypted' object from a descriptor, the resulting document does not end with the NL character. This means that it does not strictly conform to the document meta-format described in section 1.2 of dir-spec.txt. ## A.2 * the blinded key param is defined as H(BLIND_STRING | A | s | B | N). In practice I found that I had to add a null byte after BLIND_STRING in order to reach the same value as the C implementation: param = H(BLIND_STRING | INT_1(\x00) | A | s | B | N) In all other cases where a string constant is used like this (e.g. computing the nonce N above), I found that the trailing null byte is not required. * when clamping the blinding factor, the second bitwise operation is `param[31] &= 127' in the spec but `param[31] &= 63' in the C implementation. These are equivalent in practice when followed by the third operation (`param[31] |= 64'), but it might be nice to use a consistent representation for the benefit of human readers. # 220-ecc-ids-keys.txt # 2.1 * 'The signature is formed by signing the first N-64 bytes of the certificate prefixed with the string "Tor node signing key certificate v1".' I found this to be false; the signatures only validate without the string prefix. ## A.1 * I realized that the certificate types here are outdated. The signing-key extension is listed as type [04], when in rend-spec-v3.txt and the C implementation it is type [08].

3 3

Reporting Relay Bandwidth Less Often
by teor 01 Nov '17

01 Nov '17

Hi all, We would like to make Tor relays report their bandwidth statistics every 24 hours, rather than every 4 hours. We believe that this is a safer interval for clients. It makes it harder to discover the guards of clients that use a lot of bandwidth, particularly onion services. Here's how this kind of guard discovery can happen: * a client repeatedly downloads a large file, or an onion service becomes very popular, or is repeatedly asked for a large file * the traffic statistics for the client's guard increase dramatically in the next 4 hours * an adversary watches the traffic statistics across the whole network, and finds the ones with dramatic increases Increasing the bandwidth statistics interval slows down this attack: * it requires more bandwidth to produce a 24 hour spike * each statistics interval is longer, so it takes more time to be sure of the guard One of the impacts of this change is that relay bandwidth graphs are less detailed. We will encourage relay operators to view detailed graphs using local tools like Nyx or Munin or similar, because this is safer for clients. We are tracking this work in this trac ticket: https://trac.torproject.org/projects/tor/ticket/23856 Tim -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

2 3

Fwd: Fennec now builds with clang instead of gcc
by Nathan Freitas 29 Oct '17

29 Oct '17

For those working on Tor Browser for Android... ----- Original message ----- From: Nathan Froyd <nfroyd(a)mozilla.com> To: "dev-platform" <dev-platform(a)lists.mozilla.org>, mobile-firefox-dev(a)mozilla.org Subject: Fennec now builds with clang instead of gcc Date: Sun, 29 Oct 2017 19:15:50 -0400 Hi all, Bug 1163171 has been merged to mozilla-central, moving our Android builds over to using clang instead of GCC. Google has indicated that the next major NDK release will render GCC unsupported (no bugfixes will be provided), and that it will be removed entirely in the near future. Switching to clang now makes future NDK upgrades easier, provides for better integration with the Android development tools, and brings improvements in performance/code size/standards support. For non-Android platforms, the good news here is that compiling Fennec with clang was the last major blocker for turning on C++14 support. Using clang on Android also opens up the possibility of running our static analyses on Android. If you run into issues, please file bugs blocking bug 1163171. Thanks, -Nathan _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev

1 0

[release] CollecTor 1.4.1, Onionoo 4.2-1.6.1
by iwakeh 27 Oct '17

27 Oct '17

Hi there! three new releases are available: https://dist.torproject.org/collector/1.4.1/ https://dist.torproject.org/onionoo/4.2-1.6.1/ These releases enable CollecTor and Onionoo to handle unusually structured (but valid) descriptors (cf. change-logs [0], [1]). For Onionoo this prevented updates, which are running again now as all instances use the new version now. So, all clients like Atlas receive fresh data again. The CollecTor fix was deployed first on all tp.o instances and no data was lost. Thanks to all who waited patiently for Atlas to receive new data! And, to all who kindly reported the problems they noticed! Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [1] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.2-1… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

onionoo.tpo stuck at 2017-06-12 12:00?
by nusenu 26 Oct '17

26 Oct '17

Hi, just wanted to let you know that the delta between relays_published and current time is unusually high. https://onionoo.torproject.org/details?limit=0 {"version":"4.0", "relays_published":"2017-06-12 12:00:00", -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 4

Re: [tor-dev] https://gitlab.com/torproject
by Hans-Christoph Steiner 25 Oct '17

25 Oct '17

Hans-Christoph Steiner: > > > Nick Mathewson: >> On Wed, Aug 10, 2016 at 5:01 AM, Hans-Christoph Steiner >> <hans(a)guardianproject.info> wrote: >>> >>> FYI I registered https://gitlab.com/torproject to claim the name in the >>> gitlab namespace. I'm happy to hand it over to a more official Tor >>> person if anyone wants. Or just let me know if anyone ever wants to >>> actually use it. >>> >>> I've been using gitlab for a while now with F-Droid, and its quite nice. >>> Guardian Project is going to move our stuff there too. >>> >>> .hc >> >> Sure, I'd be happy to take it. >> >> We've been using gitlab's code review feature a fair bit, and though >> we don't plan to stop self-hosting our repositories, we do rather like >> having a better way to review big branches. > > Hey Nick, > > Sorry I was on vacation when I received this, and it got lost in the > fray. Send me your gitlab username, and I'll turn this over to you. > > .hc > I granted nickm_tor full ownership to https://gitlab.com/torproject I'm happy to answer questions about gitlab, especially gitlab-ci. I use it a lot with https://gitlab.com/fdroid. gitlab-ci is really great. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

1 0

Request for resource requirement
by Ankit Rathore 24 Oct '17

24 Oct '17

Hello, I am currently working on a project where I require the resource which was originally present at this link https://trac.torproject.org/projects/tor/wiki/sponsors/SponsorD/June2011 The contents of this page are no longer available. It would be really helpful if someone could help me get the original contents of this page Thank you

2 1

Do Tor relays rely on ICMP type 11 (time exceeded / timeout in transit)?
by Igor Mitrofanov 23 Oct '17

23 Oct '17

Hi, On my relays I am dropping any traffic that Tor itself does not rely on. I wonder if I should allow or block incoming and/outgoing ICMP type 11 (time exceeded / timeout in transit)? My host does receive some ICMP type 11 packets, and does seem to send some out, but I am not sure if Tor is the source or destination. Do Tor relays use some 'traceroute'-like mechanism to detect unreachable relays? "netstat -s: ... ICMP input histogram: ... timeout in transit: 1923 ... ICMP output histogram: ... timeout in transit: 1277 " I remember seeing outgoing TCP packets with TTL set to 1 - those were the ones triggering incoming ICMP type 11 packets. Thanks, - Igor

2 2

metrics: collecting circuit build failures from relays to detect network reachability issues and broken relays
by nusenu 19 Oct '17

19 Oct '17

Hello, In [1] David describes his preliminary results from scanning a portion of the tor network to detect connectivity problems (partitions) in the presumed tor mesh network (where every relay is expected to be able to reach every other relay). I believe this information (How far off are we from a complete mesh network?) is crucial for the anonymity properties of the tor network and collecting the data to answer that question should be an integral and continuous part of tor. Actively scanning the tor network for connectivity issues is resource intensive. What if we could collect this data without actively scanning for it? This could be achieved by collecting reachability information passively by relays themselves and uploaded via extra-info descriptors. This data could help reduce the overall scanning effort. So instead of scanning _all_ relays we can reduce the scanning to relays where some threshold of relays consistently said that they are hardly reachable. (to confirm their measurements) Due to the mutual nature of the information collection, single or a minor number of lying relays would not be a big issue. relays could: - aggregate reachability issues over the past 24 hours (or week?) per outbound destination relay (which relay failed what percentage of circuit build attempts) - if a relay failed more than - some threshold value - check if the relay in question: - had his uptime reset during that timeframe (reachability problem expected) - dropped out of consensus during that timeframe - only include it in uploaded data if it didn't drop out of consensus and did not reset his uptime (using a week instead of a day would help with reducing the amount of data that we need to process after collecting it) In addition to that passive collection, relays - when idle/not overloaded - could actively attempt to create circuits to measure their reachability to relays for which they did not collect any any passive data. (maybe limit it to fast and stable destination relays) To reduce the load on the tor network we could limit the active outbound connection tests based on relay flags: - Guard-only relays are more likely to establish outbound connections to non-exit relays - middle-only relays (no guard and exit flag) are more likely to establish connections to exits than to guards - exits are more likely to get inbound connections from non-guards (maybe skip active probes from exits since they are a bottleneck already?) Reachability issues could also be displayed to the relay operator warning them about the potential problem via log entries. So they could actively work on debugging problems themselfes. There is no doubt that this information is also valuable for (powerful) adversaries (it could help them reduce their effort when they know weak spots in the network). So you would have to decide what data you collect an what you would publish (collector.tpo) - even if that means I might never get to see that interesting data ;) This is a medium/long term goal, with the usual steps: - proposal - implementation (- deployment - data collection - the amount of data could be huge - data analysis) If there is a consensus that this makes sense and if someone would actually implement it I would be happy to work/help on a proposal. This entire idea would be an opt-in torrc setting at the beginning and a opt-out feature once we are more confident about its implications and safety. Please let me know what you think about this idea. regards, nusenu [1] https://lists.torproject.org/pipermail/tor-project/2017-October/001492.html related trac tickets: https://trac.torproject.org/projects/tor/ticket/12131 https://trac.torproject.org/projects/tor/ticket/19068 -- https://mastodon.social/@nusenu twitter: @nusenu_

3 2