- tor-dev - lists.torproject.org

Remaining 4 bits in prop224 addresses
by Jesse V 06 Jan '17

06 Jan '17

Hello all, I've been closely following the other Proposal 224 threads regarding the next-generation of onion services. I'm glad to see that we have a timeline and plan for migrating the network. One unresolved point is what to do with the remaining 4 bits in the longer addresses. Section 1.2 in the 224 document states "Note that since master keys are 32 bytes long, and 52 bytes of base 32 encoding can hold 260 bits of information, we have four unused bits in each of these names." It seems a waste for these to be zeroed out. The four bits could also be used to hold client-side flags, but I'm not aware of any applicable client settings that could be used here. I suggest that we use them as a checksum. (wasn't this proposed in Arlington?) Since speed isn't a priority, aside from Adler-32 or some CRC function, we could also hash the 32-byte key and use the first four bits of the hash. I think a checksum is best because it helps ensure data integrity when the address is shared online, copy/pasted, or physically written down. Bitcoin addresses contain a checksum as well for exactly this reason. They use a combination of SHA-256 and RIPEMD-160 to compute the checksum component. Source: 1) https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addres… 2) https://bitcoin.stackexchange.com/questions/32353/ What do we think about a checksum, or do we have other plans here? I ask because once we nail down the address format, I can add support for 224 into my Onion Name System. -- Jesse

4 7

Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?
by nusenu 03 Jan '17

03 Jan '17

Sebastian Hahn wrote (2016-12-08): >> On 08 Dec 2016, at 14:03, nusenu <nusenu(a)openmailbox.org> wrote: >> >> Dear tor directory authorities, >> >> TLDR: Would you blacklist relays with end-to-end correlation capabilities? > > > I do not think that this is worthwhile. It establishes a precedent where > setting your contact info is something that gets you banned, potentially > incorrectly because it's unauthenticated, whereas we're unable to identify > people who actually maliciously run several relays without such indicators. > > Additionally, it's yet one more thing to update the dirauths' configs > for, but with rather more overhead as we might get multiple mails back > and forth about how MyFamily is annoying to maintain, how they're just > trying to help, etc. All not so bad arguments. > > If we did this, also why would we blacklist the nonexit relays? That > seems to not make sense, as a relay operator could have multiple relays > that act as guard and exit simultaneously. I think we'd need to > blacklist at least all the exit relays, if not all of them. BadExiting > them would then be the more sensible choice. Scarcity of resources has > in the past led us to bad designs like Valid/Invalid relays etc, which > causes way more annoyances than good things. I understand dir auth operators have limited resources, but if you (most of the dir auths) agree that blacklisting specific relays to protect tor end users makes sense: Would you agree on handling a limited amount (6?) of such 'end-to-end' cases per year? I.e. one case every 2 months if the operator has a guard probability >0.1% and exit_probability >0.1% and didn't fix the problem within a month after getting contacted? Note: Luckily the list of such known potential operators is currently very short (<5). In the past month I had some positive effect when trying to contact relay operators [1], but unfortunately the biggest operators (by consensus weight) are not to motivated to fix their configuration in a reasonable time frame. thanks, nusenu [1] https://lists.torproject.org/pipermail/tor-relays/2016-December/011520.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011507.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011476.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011486.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011521.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011426.html

1 0

Interested in contributing to Tor Project - IP Hijacking detection for Tor relays
by Nikhil 29 Dec '16

29 Dec '16

Hi, I am Nikhil. R, a student from India. You can know more about me from here[1] and here[2]. I have been running a Tor relay for sometime and now I am interested in contributing to the Tor Project. Specifically, I would like to work on IP Hijacking detection for Tor relays. I understand this does not involve directly with the Tor core hence I think this project is ideal in getting my feet wet with the Tor Community and get me started for further contributions to the Tor Project. BGP hijacking is difficult without inside help from ISP's(I think ?) but state run adversaries don't necessarily have this problem. This has a great risk of exposing all Tor clients or even mess around with the name resolution in exit relays. I have also read about incidents where an attacker using BGP hijacking, hijacked a portion of a Bitcoin mining pool traffic to pay himself instead of the people contributing the processing power. I feel BGP has major security implications in this aspect and a monitoring service is necessary. There are many monitoring services and we can possibly leverage one of them for the routing data. The main motive of the service would be to find anomalies/ malicious changes in the routing information compared to previous snapshots of the same. How do we actually do this comparison ? Any pointers for that ? The project also mentions that the service should be Tor-aware. What exactly does this mean ? Does it mean that, it should monitor all tor relays ip addresses ? It would be wonderful if you could elaborate on the project in a little more detail. I am a beginner in this area and please excuse me if any of the above questions are too stupid. Regards, Nikhil. R [1]:https://in.linkedin.com/in/rnikhil275 [2]https://rnikhil275.github.io

1 0

Can I modify obfs4 proxy code for my purpose?
by trmobid＠tutanota.com 22 Dec '16

22 Dec '16

Hi. I have some questions about modifying codes. 1. I wanna build a password protected obfs4 proxy sever with my VPS. I don't need that much privacy in terms of MITM for this. I just wanna know if it is ok to build such server in Tor network. 2.I wanna overrides some Javascript API with add-on. but... I just tried this with latest Torbrowser. it seems like I can't overrides some API's. Because same add-on I made worked on normal Firefox browser. I wanna avoid some fingerprint tracking recently discovered. Is there any reason to block overrides by add-on? Or am I missing something? I wanna know which is best way to do this. add-on or Torbrowser itself. Thanks.

2 2

prop224: What should we do with torrc options?
by David Goulet 20 Dec '16

20 Dec '16

Hi everyone! We are soon at the stage of implementing the service part of proposal 224 (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing here ticket #18054. In a nutshell, we need to figure out the interface for the torrc file[1]. We currently have some options to configure an hidden service and the question is now how do we proceed on using those for next version? Instead of listing all options and going in an endless loop of possibilities, I'll outline what we've discussed so far between some of us. In the following, "v2" is current hidden service and "v3" is the next generation detailed in prop224. 1) Once v3 is released, from that point on _no_ v2 service will be allowed to be created by "tor" itself. It will always be possible to do it by hand by creating an RSA key and putting it in the service directory (see 3 below). The reasoning for this is that we really want to phase out as quickly as possible the v2 protocol for privacy and security reasons. 2) All the current torrc options will be kept for v3 as they all apply in terms of format. (One exception might be the client authorization.) 3) When tor is loading config for a service: if a v2 key is found that is an RSA key, we treat that service as v2, print a deprecation warning and continue. if a v3 key is found, use v3, all is good. if no key is found, consider a new service and generate v3 (ties to 1 above). 4) Over time, extra option might appear and they will be ONLY for v3 unless for force majeur security madness. One of those options that we want to add is this one as offline key will be a reality with v3: "HiddenServiceOfflineKey 1" It will indicate tor to _not_ generate the master identity key and will require the user to put the public key in the HiddenServiceDir. Note that with all of the above it will be possible to have one of your application on both v2 and v3 address. Here is a snippet as an example: # v2 HiddenServiceDir /srv/hs/v2 HiddenServicePort 80 localhost:80 # v3 HiddenServiceDir /srv/hs/v3 HiddenServicePort 80 localhost:80 The important part here is the different directories but the port points to the same place. Ok here it is. Please comment, improve, or propose! :) Cheers! David [1] https://www.torproject.org/docs/tor-manual.html.en (see HIDDEN SERVICE OPTIONS)

10 42

automatically detect many new identical/similar bridges
by nusenu 16 Dec '16

16 Dec '16

Hi, in the context of [1] I'm wondering if it makes sense to add bridge support to ornetradar. If there is any value to automatically detect multiple new bridges: - Do bridges publish ContactInfo in their descriptor? If not: Why not? (it shouldn't disclose their bridge location) another raw idea: - would the bridge auth be willing to publish a randomly generated AS identifier (regenerated daily) that allows new bridges added on the same day to be grouped by that identifier without directly disclosing the AS itself. Note: This introduces a confirmation opportunity, where attackers can learn the AS in which a new bridge is added if they added a bridge in the same AS on the same day. To reduce this problem it could be a hourly generated identifier. regards, nusenu [1] https://lists.torproject.org/pipermail/tor-project/2016-December/000851.html

5 8

Release: sandboxed-tor-browser 0.0.2
by Yawning Angel 14 Dec '16

14 Dec '16

Hello, I tagged sandboxed-tor-browser 0.0.2 (0.0.1 is also tagged, but it has a few issues), so this is the obligatory release announcement. Official binaries should be available sometime next week, so I strongly suggest that people wait till then, unless they feel confident in installing the build time dependencies, and building the binary. This is the non-developer alpha version of the sandboxing approach outlined in: https://lists.torproject.org/pipermail/tor-dev/2016-September/011444.html A lot has changed since then, the primary changes are numerous improvements to the sandbox, the addition of graphical UI, and the removal of the "you need a tor daemon as a system service" requirement. It is still very much an alpha (up from a proof of concept tech demo), so there will be rough edges and bugs, some potentially major. Features: * A Gtk+3 based UI for downloading/installing/updating Tor Browser, configuring tor, and launching the sandboxed browser. Think `tor-browser-launcher`, that happens to run Tor Browser in a bunch of containers. * Linux seccomp-bpf + namespace based containers for Tor Browser, that attempts to prevent/mitigate exploits and reduce the amount of personally identifiable information to a minimum, centered around bubblewrap (runtime dependency). Known system incompatibilities: * 64 bit kernel, 32 bit userland is not supported. * X32 (x86_64 with 32 bit pointers) is not supported. If you have to ask what this is, and how it's different from normal 32 bit x86, you don't have it. * Systems that do not store the dynamic linker/loader cache in `/etc/ld.so.cache` in glibc 2.2 format are not supported. * Ubuntu does not have a sufficiently recent bubblewrap package available for any current release, up to and including `yakkety` (16.10). The package that is available in `universe` SHOULD NOT be installed, and WILL NOT work. Errata: * On systems where gstreamer libraries are pulled in as part of the base firefox runtime dependencies, the libraries can find their way into the sandbox without the need for explicit user intervention, if "Extra Audio/Video Codecs" is enabled in the sandbox configuration. As far as I am aware, and on the systems I have tested, none of the modern distributions have system libraries built this way. If the sandbox manages to launch Tor Browser with the option disabled, you are not affected by this. The exact functionality, usage, and caveats are documented at: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux The code is at: https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/ Regards, -- Yawning Angel

3 3

Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?
by nusenu 09 Dec '16

09 Dec '16

> I do not think that this is worthwhile. It establishes a precedent where > setting your contact info is something that gets you banned, potentially > incorrectly because it's unauthenticated, whereas we're unable to identify > people who actually maliciously run several relays without such indicators. "actually maliciously" somehow implies that openly run groups (all relays have the same contact info) are certainly not malicious because they do not try to hide? (set contact info) While I even assume that this is true for most such operators, it does not have to be the operator itself as soon as his admin machine gets compromised. Since openly run groups are not blacklisted there is no reason for someone with malicious intents to to even try to hide. > If we did this, also why would we blacklist the nonexit relays? That > seems to not make sense, as a relay operator could have multiple relays > that act as guard and exit simultaneously. Exit relays with the guard flag have usually a guard probability of 0% according to onionoo. Since exit capacity is harder to get I was suggesting to blacklist the guard-only relays of such groups, so the exit capacity could still be used while breaking the end-to-end capabilities (if we can assume onionoo's guard_probability to be correct). also see: https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html

2 1

Re: [tor-dev] please update your MyFamily
by Sec INT 09 Dec '16

09 Dec '16

Think I'm on dev-tor list now - sorry for spamming - all family info should be up to date now regards Mark B > On 8 Dec 2016, at 14:07, Sec INT <sec.int9(a)gmail.com> wrote: > > Should all be correct now > > regards > > Mark B > > >> On 8 Dec 2016, at 11:56, nusenu <nusenu(a)openmailbox.org> wrote: >> >> Dear snaptorg tor operator, >> >> >> teor wrote [1]: >>> TL;DR: we're talking about blacklisting your non-exit relays, >>> because they don't have MyFamily set correctly. >>> >>> If you'd like help configuring MyFamily correctly, please let us know. >> >> >> If you are wondering which relay is misconfigured, the last column >> (MyFamilyCount) should say at least 7 (or 8 if you plan to recycle your >> Creanova relay key). >> >> https://atlas.torproject.org/#details/9BFBF1EA78A3FC1A790F7A7789F074338E7F8… >> >> +---------------------+--------------+------+-------+---------------+ >> | first_seen | nickname | exit | guard | MyFamilyCount | >> +---------------------+--------------+------+-------+---------------+ >> | 2016-12-03 23:00:00 | SnapTorCAN | 0 | 0 | 5.0000 | >> | 2016-11-28 14:00:00 | SnapExitUS | 1 | 1 | 7.0000 | >> | 2016-11-28 11:00:00 | SnapExitBULG | 1 | 0 | 7.0000 | >> | 2016-11-27 00:00:00 | SnapTorBANG | 0 | 0 | 8.0000 | >> | 2016-11-26 23:00:00 | SnapTorSNPR | 0 | 0 | 8.0000 | >> | 2016-11-26 23:00:00 | SnapTorSTRAS | 0 | 0 | 8.0000 | >> | 2016-11-12 00:00:00 | SnapTorFr | 0 | 0 | 8.0000 | >> +---------------------+--------------+------+-------+---------------+ >> >> >> >> [1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html >>

3 2

protecting users from known relay groups with end-to-end correlation capabilities
by nusenu 08 Dec '16

08 Dec '16

Hi, it is a well known fact that MyFamily is a largely ignored setting, luckily this is not a problem in most cases because - all relevant relays are run in a single /16 or - are only guard relays (exit probability = 0*) or - are only exit relays (guard probability = 0*) but there is a limited number of relay groups** that have actual end-to-end correlation capabilities, meaning they are potentially chosen by tor clients for the guard _and_ exit position, even if the odds are (hopefully) not very high. These potentially dangerous relay groups - are run in multiple /16 netblocks - have an exit _and_ guard probability of > 0 (because they run exits and guards) Examples (generated daily): https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… (see CC) How could the risk for tor clients be reduced? (options after enough dir auths came to the conclusion that these relays are in fact operated by a single entity) 1) try to contact the operators and give them time to fix it I've done that multiple times but haven't been successful [1] 2) build tools to easily/automatically manage MyFamily done[2], but it is unlikely to be used 3) assign them the badexit flag since exits are a scarce resource, not very wise 4) assign them the badguard flag there is no such thing ;) 5) blacklist the entry guards (that are outside the configured family) 6) change tor's path selection algorithm to never choose more than one relay with a given non-empty non-default contact string? This would basically turn the ContactInfo field into the PoS token mentioned by Mike in [3]. Since there are a few common contactInfo strings this is probably not the best option without excluding them. [1] https://lists.torproject.org/pipermail/tor-relays/2016-November/010965.html [2] https://github.com/nusenu/ansible-relayor [3] https://trac.torproject.org/projects/tor/ticket/5565 * if we can assume onionoo's values to be accurate and realistic ** they are considered to be operated by a single group due to their contactInfo descriptor field. This string is not verified in any way and can therefore result in false-positives.

2 5