- tor-dev - lists.torproject.org

txtorcon support for Twisted 12, 13, 14
by meejah 20 Jan '17

20 Jan '17

I am considering dropping support for Twisted 12, 13 and 14 in the next txtorcon release. Also, TLS support (i.e. pyOpenSSL) will become mandatory as well (that is, the dependency will be on twisted[tls]). Twisted 12 is only there because of Debian wheezy. Twisted 13 is for wheezy-backports and 14 is for jessie ("stable"). jessie-backports has 16.2.0 and stretch has 16.6.0 Hence I do not believe upgrading this dependency will be a problem for Debian packaging. I do not know the implications for other distributions. Feedback requested if this will negatively affect you! -- meejah

2 2

Release: sandboxed-tor-browser-0.0.3
by Yawning Angel 18 Jan '17

18 Jan '17

Hello, I just tagged sandboxed-tor-browser 0.0.3. Binaries will be built when the next Tor Browser build happens (soon). The dependencies (both build and runtime) have changed, end users should install `libnotify` in the unlikely event that it is not already present, though basic functionality should not be broken even if it is missing. The major changes since last version are: * 32 bit x86 support has been deprecated. * Numerous installer/updater improvements including periodic background update checks (requires libnotify for notifications) and using `.onions` when fetching installer/updater metadata. * Fixes for various crash/functionality bugs, including problems relating to certain versions of bubblewrap failing to launch with errors related to `setsid`[0]. Full details are available in the ChangeLog, and the code is still at https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/ Regards, -- Yawning Angel [0]: If people are encountering this, particularly with the Debian package, either upgrade `sandboxed-tor-browser` to the new release, or update bubblewrap to 0.1.7 or later.

1 0

RFC: Tor long-term support policy
by Nick Mathewson 18 Jan '17

18 Jan '17

Hi, all! This is a draft for a tor long-term support policy for the program "tor". Please let me know what you think. It's based on earlier work and surveys, but it isn't final till we say it is, and it needs more commentary. Please keep in mind that dropping support for any old release is an inconvenience to some nice busy people, and that supporting any old release is an inconvenience to other nice busy people. Therefore, "don't inconvenience anybody" is not a viable goal here: instead we are stuck with a balancing act. Also please remember the bikeshed. ;) http://bikeshed.com/ == Background == In the past, Tor has had no actual policy for how long we support older releases of the core "tor" network program. We've aimed for informal rules like "support old releases as long as it isn't too much trouble," or "support old releases as long as a lot of people really need it," but these aren't working so well with our new release schedule. The good thing about our new release schedule is that we try to put out two stable release series per year, when previously we were finishing release series once every ~18 months. But this means that, to support the last N years of releases, we need to support three times as many older release series as we did before. This won't scale, and probably isn't a good use of our time. Therefore, we're adopting a practice from several other free software projects with a rapid release schedule: we are going to support some Tor releases for different amounts of time than others. == Levels of support == Here's the plan. * Every new release series will be supported for at least nine months after it becomes stable, and for at least three months after another release series becomes stable. Example: * The first 0.2.8.x stable release was released in August 2016. So it will be supported until at least 9 months later, in May 2017. But if the first 0.2.9.x stable release had not been released until April 2017, we'd keep supporting 0.2.8.x for another 3 months past that point, to July 2017. * Occasionally, we will designate some Tor release series as "long-term support" releases. These will be supported for an amount of time to be announced in advance -- typically, for 3 years. * For the release series that exist today, we will support them according to the schedule at the end of this document. == What does support entail? == For all supported releases, we intend: * Information needed to connect to the Tor network (directory authorities, fallback directories, geoip tables) will be kept up-to-date. * Important security issues will get fixed. * Major stability issues will get fixed. * Portability regressions will get fixed. * Portability bugs to major supported platforms will get fixed. For the most recent supported stable release only: * Misleading documentation will get fixed. * Smaller bugs that significantly impact user experience will get fixed. We do NOT expect: * That directory authorities will be able to run any but the two most recent stable releases. * That unsupported releases will all work on the Tor network. * That unsupported releases will all fail to work on the Tor network. * That older supported releases will provide the same privacy as the newer ones. == The obligatory disclaimer == This document is about plans, not promises. We'll try hard to follow through on these plans, but it's always possible that something unexpected will happen and we'll need to choose between following this policy to the letter and maintaining our users' security. If that happens, we'll aim for protecting our users. == Plan for current releases == 0.2.4.x, 0.2.6.x, and 0.2.7.x, will all receive at least one more stable release. Support for them will end on 1 August 2017. 0.2.8.x will be supported until 1 January 2018. 0.2.5.x is retroactively declared an LTS release, and will be supported until 1 May 2018. 0.2.9.x is an LTS release, and will be supported until at least 1 January 2020.

6 6

[collector] CollecTor Release 1.1.2
by iwakeh 17 Jan '17

17 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! another CollecTor version is available: https://dist.torproject.org/collector/1.1.2/ The release provides the following changes * CollecTor now uses the correct type annotation "@type tordnsel 1.0" for exit lists again [0], and * The build process now complies to a Metrics java standard build environment [1]. In addition, the main CollecTor instance and collector.sky-ip.org mirror provide correct exit-lists again as of today. See our mirror list [2]. Other mirror operators should upgrade and process their mirrors exit-lists. A script for the latter is available in the release tarball. Please direct comments and questions to the metrics-team mailing list [3]. And, of course, bug reports [4] or feature requests [5] can be filed in trac. Cheers, iwakeh [0] https://trac.torproject.org/projects/tor/ticket/21195 [1] https://trac.torproject.org/projects/tor/ticket/20596 [2] https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Operati… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team [4] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… [5] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYfk1MAAoJEPeEx9Sa/gvijAwQAII81X0vWPLA7YbecHQLZJTA LJqH3ODOpJAZZIrLuk+W4QUlyA/W1EmvSFCbDjUabnsc5d76lKzKJLGu9DlPDJSw Gwb4UBQp+9Gi8wyaYLqHCoRJiGf+JvZnHAQK9/FvBQUDYkyz0ghTuGHLn/JGmNPV w220fdPOZ7kEfYzuqFT8vY4eZBKxL7uLbaiU2GbYfykV3be34q9rUjmDtWoPHQ5u FfFbzdQxDFaeRTKiWhXOG1He2epKeZezxZJBUQTotpSotaTjH3NFP+oJCsPUmPej G5td1glJ2kBcl+b61TXtVMaCUVgw9otx9bsogQnY2ceTCL8iR5M2eNP1queI6gZ8 NgPh8KGsjXMmYlPmER1UedaBgf8YcYdlKchUtMLuWVPPX0QTaAdC3eLtuLNPxOWX +lbFkCiH9hJ+1i4TktJ/XiBf0lBBvZCzkSBA5U0N0LEMTSkBIv9oh5wnP/AtoFLN DFAtnHsOLXPz8mTtvBivHzTurwIL83FHs64Bm4nh2uPQ4iX/P1JzWLaIo8tGOVEO pAJtEZGAzKMWTb96kIsLehXKgRTPAR+LAeWirwa+yY65YuhKNCKWz0jbG9s/6NAv HggzcltuHibgr64D8LhlgSY6om9zwtEGH3NG26Zcd1pZAbQkIlr4c6qcKQF4C0AB s+YXdtoVFpOfc3TiEEli =DvuO -----END PGP SIGNATURE-----

1 0

txtorcon 0.18.0
by meejah 12 Jan '17

12 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 txtorcon 0.18.0 is released, improving error-reporting when you have SAFECOOKIE or COOKIE authentication turned on but can't read the file. * https://github.com/meejah/txtorcon/issues/200 You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.18.0 https://github.com/meejah/txtorcon/releases/tag/v0.18.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.18.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.18.0.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 12be80f1d5e2893378c6e8c752cf159479f868f8424e16b34b75cd679a0ab171 dist/txtorcon-0.18.0.tar.gz cffe063dbcedd9d344e88a572c0de39b0390562165a865efa27019260c2119f6 dist/txtorcon-0.18.0-py2-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYdp4sAAoJEMJgKAMSgGmnxCIH/iiFJdYtbSnShAktDrwMuL6K tJN+AALrr6zIydjIVG4pNuGydoxqtmrpb/12xNn/c7noEWZpuuHd+hn/PRn+XNaA Gh+q4922VKs3ZCFYFClVAkZFtT5iug7EKnB6n0IKt4Z+rVAzRTCpHqgnCmmavHP1 s55jkYc+emC/jzGag22sD7HnPYHjkuKV+qy1Y6mF1//oD9FFhJUXvn5FVjf9cNb/ xta7HB3AMXp/8qdpURPJaJBjWOg1BxSVBngZXYiUJkkoOReOJU1ngDoU0J7VjQJq Uyi2ijwylUnK6/7qLLS8pwyX/UmWgV7NeQgIr00Shsm7Jv+zkk0QhXbnwJo8pRQ= =oJqn -----END PGP SIGNATURE-----

1 0

txtorcon 0.18.0
by meejah 12 Jan '17

12 Jan '17

1 0

SipHash Impact on TCP ISN skew fingerprinting
by bancfc＠openmailbox.org 11 Jan '17

11 Jan '17

SipHash a fast PRF by DJB has been adopted upstream across the Linux networking stack landing in 4.11. It deprecates a lot of ancient and broken crypto like MD5 for initial sequence number hashes. Its my guess that that timer values added in ISNs should now be indistinguishable from the rest of the hashed secret outlined in RFC-6528.[1] Can anyone knowledgeable in reading kernel code [2] please confirm that this kills clock skew extraction [3] and fingerprinting [4] described in Steven Murdoch's papers? Its one of the advanced attacks we've been following for some time now and would be good to write it off. *** [1] https://tools.ietf.org/html/rfc6528 [2] http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00076.html [3] http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ih05coverttcp.pdf (pages 7-8) [4] http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ccs06hotornot.pdf

2 1

ExcludeExitNodes and ExcludeNodes but no "ExcludeEntryNodes"?
by nusenu 09 Jan '17

09 Jan '17

Hi, is there a possibility to blacklist guard relays (only in that position) from a client perspective? I didn't find one in the torrc man page. It is generally a bad idea to create custom tor client footprints by excluding relays but maybe it is less bad to exclude a certain relay just in the guard position than to exclude it completely via ExcludeNodes + StrictNodes since guards are used for a longer timeperiod. thanks, nusenu

2 1

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

Is it safe for second_elapsed_callback() to be called less often?
by Michael Rogers 07 Dec '16

07 Dec '16

Hi, When running hidden services on Android I've found it's necessary to hold a wake lock to keep the CPU awake. Otherwise Tor's second_elapsed_callback() doesn't get called once per second. When the CPU eventually wakes and the callback is called, if 100 seconds or more have passed since the last call, second_elapsed_callback() calls circuit_note_clock_jumped(), which marks any dirty circuits as unusable. If I understand right, this will have the effect of breaking any existing connections to the hidden service and making the service unreachable until it's built new intro circuits and published a new descriptor. #8239, #16387 and #19522 might help to reduce the downtime by improving our chances of reusing the same intro points, but we'd still lose the existing circuits. It would be nice if we could avoid this downtime without holding a permanent wake lock, which has a big impact on battery life. A possible workaround would be to use Android's alarm API to wake the controller process once per minute. The controller process can acquire a wake lock for a couple of seconds to allow second_elapsed_callback() to be called, then release the lock until the next alarm. However, it's pretty clear that Tor wants the callback to be called once per second and gets nervous if that doesn't happen, so I wanted to ask about the implications of calling the callback once or twice per minute before pursuing this idea further. Is it in any way sane? Another possibility would be to look into how Libevent's timers work. Perhaps we can ensure that the timers wake the CPU on Android, so second_elapsed_callback() and any other timer-based functions get called without keeping the CPU permanently awake? Thanks, Michael

3 3

sketch: An alternative prop224 authentication mechanism based on curve25519
by Nick Mathewson 06 Dec '16

06 Dec '16

Hi! I thought I'd write this up while it was fresh in my mind. It could be used as an alternative method to the current proposed client authentication mechanism. We could implement both, or just this, or just the other. My description here will be a bit terser than we'd want in a proper proposal, but I wanted to share it. This design is based on George Kadianakis's client authentication design; it won't make sense unless you've read it. ============= Let every client generate a curve25519 keypair, and tell the hidden service operator about the public key. This keypair takes the place of the long-term shared secret. For some client C, denote the secret key as x_X and the public key as X_C. For every descriptor, the hidden service generates a fresh keypair <y, Y>, and includes Y in the the outer encrypted layer. Now, for each client, the hidden service computes curve25519(X_C, y) and uses this as the input for two KDF functions. Call these outputs K1_C and K2_C. The hidden service generates an auth-client line for each client as follows: "auth-client" SP client-id SP encrypted-cookie This is the same as in George's proposal, except that client-id is derived from a truncated version of K1_C, and the encrypted-cookie portion is encrypted based on K2_C. When the client receives the descriptor, it decrypts the outer layer, then sees the value of Y that the hidden server advertised. It computes curve25519(Y, x_c), and derives K1_C and K2_C. It uses K1_C to find the appropriate entry on the list, and then uses K2_C to decrypt it and find the descriptor cookie. ============= Advantages: * managing public keys can be easier than managing shared secrets. * The encoding is slightly shorter, since no IV is needed, since K2 is different every time. * probably others? Disadvantages: * Curve25519 costs more computationally than non-public-key operations * probably others? -- Nick

8 20

TBB Isolation Impact on Alternative Anon Nets
by bancfc＠openmailbox.org 06 Dec '16

06 Dec '16

TBB sandboxing is a great hardening measure. I was wondering if there are side-effects such as breaking setups that involve using anonymous networks other than Tor. Such as: https://thetinhat.com/tutorials/darknets/i2p-browser-setup-guide.html As a workaround we can document how to toggle the TBB variable to disable this. Of course the best solution is having the isolation compatible with alternative setups if you consider this (minority) use-case worthy of your effort.

2 1

Scheduling future Tor proposal reading groups
by George Kadianakis 04 Dec '16

04 Dec '16

Hello people, in the beginning of 2016 we started organizing little-t-tor proposal reading groups in IRC, where we would discuss the current status of Tor proposals and coordinate on how to move them forward. You can see a list of previous such meetings here: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Meeting… Unfortunately at some point, 2016 started showing its true self, and we kind of stopped doing those meetings in March. But they were useful, and we should probably start doing them again! I went through the mailing list and found a few interesting subjects that could benefit from group discussion. Here are some ideas: - Post-Quantum key exchanges for Tor There are a few proposals falling under this topic that were developed in the past months. Here are a few: https://gitweb.torproject.org/torspec.git/tree/proposals/263-ntru-for-pq-ha… https://gitweb.torproject.org/torspec.git/tree/proposals/269-hybrid-handsha… https://gitweb.torproject.org/torspec.git/tree/proposals/270-newhope-hybrid… https://lists.torproject.org/pipermail/tor-dev/2016-October/011553.html I'm far from an expert on this field, so I'm not sure about the current status of this project and the right direction to approach it. However, it seems that there have been enough developments here lately that a group discussion might be useful. - A name system API for Tor This is a proposal suggesting a single API that allows us to integrate secure name systems with Tor hidden services: https://lists.torproject.org/pipermail/tor-dev/2016-October/011514.html The proposal received useful feedback in and out of the mailing list. It seems that implementing the proposal as part of a Tor controller might be an easier way to test it. Some discussion on future directions might be helpful here, as this is something that will be needed sooner than later. - New topics in Next Gen Hidden Services We've done multiple IRC meetings on prop224, but it keeps on growing as it's being developed. Here are a few topics that might be worth discussing as a group: - Control port API for hidden services (https://trac.torproject.org/projects/tor/ticket/20699) - torrc UX for hidden services (https://lists.torproject.org/pipermail/tor-dev/2016-November/011661.html) - torrc/control UX for hidden service client auth (https://lists.torproject.org/pipermail/tor-dev/2016-November/011617.html) - UX for offline keys (https://trac.torproject.org/projects/tor/ticket/18098) - UX of hidden services on Tor Browser - Prop271: Another algorithm for guard selection We've also done a few IRC meetings on future guard algorithms, but we are now closer to completing that project than ever. After we have a few results and statistics of the new guard algorithm, it might be worth scheduling a meeting to discuss how well it works and ways to improve it. - And here are some more misc projects that might be worth discussing further: - The Tor browser sandbox that Yawning is developing and UX implications? - prop273: Exit relay pinning for web services ? Please let me know if you are excited talking about any of these topics (feel free to +1 in private email if you feel it's too spammy), or if there are any topics I forgot to mention. If we get enough participation we can schedule the first such meeting for December. Thanks!

5 4

Hidden Services and identity-based encryption (IBE)
by bancfc＠openmailbox.org 04 Dec '16

04 Dec '16

Read the Alpenhorn paper. Really neat stuff. It is able to guarantee forward-secrecy for identities and metadata and doesn't need out-of-band identity sharing. Can any of this stuff be borrowed for HSs? https://vuvuzela.io/alpenhorn-extended.pdf

2 1

Should Whonix recommend against using multiple workstations behind the same Tor-Gateway in all situations?
by Patrick Schleizer 03 Dec '16

03 Dec '16

TLDR: Should Whonix recommend against using multiple workstations behind the same Tor-Gateway in all situations? Long: We at Whonix are currently wondering if we should recommend against using multiple workstations behind the same Tor-Gateway. It's not something we are looking forward to do since it severely decrease usability and may not actually increase anonymity. That's why we're asking. (Usability would decrease because: multiple-gw multiple-ws mapped 1:1 is more difficult to explain and set up than single-gw multiple-ws; more VMs to [maybe configure for bridges multiple and] upgrade multiple times; more RAM usage; taking more disk space; setup taking more time; and perhaps more.) Whonix does use a control port filter. By default, only the most essential Tor control commands are whitelisted such as authenticate, quit, signal newnym, getinfo net/listeners/socks, getinfo status/circuit-established and protocolinfo to make Tor Brower work without any errors. teor recently wrote: > We don't even recommend running a SOCKS client and a hidden service on the same instance. Okay, makes sense. We'll update our documentation to reflect that advice. Not too long ago Tor got some improvements: * The number of Tor entry guards was reduced from 3 to 1. * And guards are kept for longer. (Longer guard cycling period.) If we encourage multiple Tor-Gateways, we subvert these improvements. * a) I think guard related attacks are much more serious since they lead to deanonymization, which speaks for single-gw multiple-ws setups. * b) Drawback is that caching issues in single-gw multiple-ws setups can lead to linking multiple workstations together. I think a) is more serious than b). So for now I guess single-gw multiple-ws is still better than multiple-gw multiple-ws mapped 1:1. Perhaps we could equate the following two? single-gw multiple-ws * perhaps some discovery attacks even with a filter multiple-gw multiple-ws mapped 1:1 * Even VM-level isolation is not proof against some attacks What is worse...? * a) single gateway sharing vs * b) using multiple-gw multiple-ws mapped 1:1 and thereby subverting number and duration of entry guards Even in a multiple-gw multiple-ws mapped 1:1 setup, would these multiple instances of Tor be really isolated from each other? Doesn't this presuppose a perfectly contained VM? By perfect I mean to limit the system resources any workstation / gateway can take. We are not there yet to limit CPU load / network load / I/O (hdd) load / graphic calculation load (/ RAM load?). (Because [not all] virtualizers support that [easily]. [...]) (And one compromised workstation then could stress system resources which would then make the anonymity of another gateway suffer.) So far we can see four options for implementation / user recommendation: * single-gw multiple-ws * multiple-gw multiple-ws mapped 1:1 ** For multiple-gw multiple-ws mapped 1:1 setups it might be theoretically an option to have them manually use the same Tor entry guard? That also does not seem too great, since Tor guard selection then would be manual? (Cloning a gateway not a reliable solution to keep entry guards, since Tor will change them after some time and then they will differ.) * single-gw with multiple-ws while recommending against running multiple workstations for activities of different trust levels / pseudonyms at the same time * Yet another option might be to run multiple Tor instances on the same gateway. Tor's systemd service supports that. (Would use separate Tor data dirs, thereby different Tor entry guards.) ** If you recommend we should use multiple Tor instances, should we try to configure them to use the same Tor entry guard or bridge? A list with all pros and cons for either option based on what we learned recently on this list has been created: https://www.whonix.org/wiki/Dev/Multiple_Whonix-Workstations

1 0

Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities
by teor 03 Dec '16

03 Dec '16

> On 3 Dec. 2016, at 11:48, Bungeetaco <bungeetaco(a)protonmail.com> wrote: > > Hi there, I have added the following line to the torrc of all my tor nodes and reloaded the daemons: > > MyFamily 629FE436746E0AACDFC93D2DA70B5E269F7ADC79,DA5B2F8C1C7E901374C8A200277A3C927176BF0F,A894ABB7B1A990B5F10BA9CBE668E27BE6C7FEDF > > Been running my two exit nodes for a year now with good management, and I haven't got raided so far so I guess I'm doing this the right way. Glad you guys are reaching out about issues that are easily fixable by operators instead of just blacklisting nodes at random. > If something else needs my attention, feel free to let me know. I love this project ^w^/. Thanks for fixing this so quickly. It should be distributed to all clients within the next few hours. You can check it worked using the "Family Members" on: https://atlas.torproject.org/#details/629FE436746E0AACDFC93D2DA70B5E269F7AD… It will take at least 15 minutes to appear on atlas, and maybe even 75 minutes, if your relays sent updated descriptors after 50 minutes past the hour. Tim > >> -------- Original Message -------- >> Subject: Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities >> Local Time: December 2, 2016 7:15 PM >> UTC Time: December 3, 2016 12:15 AM >> From: teor2345(a)gmail.com >> To: Bungeetaco <bungeetaco(a)protonmail.com> >> tor-dev(a)lists.torproject.org <tor-dev(a)lists.torproject.org> >> >> >> > On 3 Dec. 2016, at 11:11, Bungeetaco <bungeetaco(a)protonmail.com> wrote: >> > >> > >> > >> > >> > >> > >> > Hi there! I would be more than glad to apply the appropriate modifications to my relay if it means increased security for the users ;D. I care about the security and privacy of the people who pass through my relays, and I take pride in supporting a project which empowers people so much. I decided to run a Middle and 2 exit nodes because I wanted to provide diversified support to the Tor network, I did not intend to jeopardize anyone's privacy or security. >> > >> > Would I need to add the fingerprints of my others nodes in my torrc configuration files? If so, please let me know how to accomplish this and I'll push an update on all my servers ASAP. The last thing I want is create a security risk for the users and/or distrust. >> > >> > Thanks for letting me know about this btw! >> >> Hi Bungeetaco, >> >> On each relay, add a line to the torrc that says: >> >> MyFamily fingerprint,fingerprint,fingerprint,... >> >> Where the fingerprints are the fingerprints of each of your relays. >> >> Tim >> >> > - Bungeetaco >> > https://bungeetaco.com/ >> > >> >> -------- Original Message -------- >> >> Subject: Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities >> >> Local Time: December 2, 2016 5:39 PM >> >> UTC Time: December 2, 2016 10:39 PM >> >> From: teor2345(a)gmail.com >> >> To: tor-dev(a)lists.torproject.org >> >> abuse(a)torworld.org, tor(a)digineo.de, Viktor Nikolov <vnikolov(a)vnikolov.cz>, Nicholas Merrill <nick(a)calyx.com>, bungeetaco(a)protonmail.com, Dmitrii Tcvetkov <demfloro(a)demfloro.ru>, abuse(a)to-surf-and-protect.net, bad-relays(a)lists.torproject.org >> >> >> >> Dear relay operators who are CC'd, >> >> >> >> 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. >> >> >> >> > On 3 Dec. 2016, at 08:50, nusenu <nusenu(a)openmailbox.org> wrote: >> >> > >> >> > 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) >> >> >> >> This is a useful check, but it is insufficient. >> >> Can you please produce a similar list for middles and exits by the same >> >> operator? >> >> >> >> (Controlling the middle and exit leads to a guard identification >> >> attack.) >> >> >> >> There's also an attack when an operator controls a guard and a middle. >> >> But that's harder to resolve, albeit much more common. >> >> >> >> > 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] >> >> >> >> Have you tried emailing them individually? >> >> I've typically got better results that way. >> >> >> >> > 2) build tools to easily/automatically manage MyFamily >> >> > done[2], but it is unlikely to be used >> >> >> >> Maybe one solution is to build a generic tool that works with more than >> >> just ansible? >> >> >> >> > 3) assign them the badexit flag >> >> > since exits are a scarce resource, not very wise >> >> >> >> +1 >> >> >> >> > 4) assign them the badguard flag >> >> > there is no such thing ;) >> >> >> >> We have written patches that take away the guard flag. >> >> This would be possible, but it doesn't resolve the issue, because they >> >> will still be used as middle relays. >> >> >> >> However, taking away the guard flag would fix the guard/middle case, >> >> because then all the relays would only be used as middle relays. >> >> >> >> > 5) blacklist the entry guards (that are outside the configured family) >> >> >> >> Yes, this is the best option, because it protects clients from >> >> selecting relays from that operator as either guard or middle. >> >> >> >> (However, operating a bridge and an exit still has the same issue, and >> >> there is no MyFamily for bridges, because that de-anonymises them. As >> >> do the bridge/middle and guard/middle cases. So maybe we should >> >> consider the risks of each case, and whether we want to educate or ban.) >> >> >> >> And, of course, it's worth noting that the ContactInfo might be >> >> incorrect, so we would have to do this on a case-by-case basis, and >> >> convince the directory authority operators it's a sensible thing to do. >> >> >> >> (If someone is using others' ContactInfo, those relays should be >> >> banned.) >> >> >> >> > 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. >> >> >> >> No, this field is not mutually authenticated, unlike MyFamily. >> >> This leads to an attack where bad relays bias client path selection >> >> using ContactInfo. >> >> >> >> > [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. 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