April 2015 - tor-dev - lists.torproject.org

Re: [tor-dev] Experimenting with private tor setup
by teor 22 Apr '15

22 Apr '15

> Date: Tue, 21 Apr 2015 02:13:48 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > I've been experimenting with a private tor setup - I've managed to setup a > couple directory authorities, six routers/exit nodes (which seemed to be > the minimum to bootstrap everything), and a client. With the latest versions of tor and chutney, the "basic-min" configuration bootstraps a testing tor network with 3 authorities (non-exits), 1 exit relay, and 1 client. I'm pretty sure this is the minimum number of tor instances to bootstrap, as bootstrapping requires each relay to create a 3-hop path through other relays which have already bootstrapped (or, in this case, the 3 authorities, which assume their own reachability). I'm not sure if you're using chutney to set up your network. chutney simplifies the setup of local tor networks using a templating and launch system. The latest version can be downloaded using: git clone https://git.torproject.org/chutney.git > Its a pretty normal > setup (aside from everything running on my development box) and passes > traffic as expected. > > So I'm wondering what would happen if I set TestingTorNetwork to 0, so I > picked one onion router instance and made that change. > > Because its all running on one box I had to keep some of the special > settings: > DirAllowPrivateAddresses 1 > EnforceDistinctSubnets 0 > AuthDirMaxServersPerAddr 0 > AuthDirMaxServersPerAuthAddr 0 > ExtendAllowPrivateAddresses 1 > > And that almost works, I got this far: > > Apr 21 00:50:09.000 [notice] Bootstrapped 100%: Done > Apr 21 00:50:09.000 [notice] Now checking whether ORPort > xxx.18.110.101:5106 is reachable... (this may take up to 20 minutes -- look > for log messages indicating success) > Apr 21 01:10:09.000 [warn] Your server (xxx.18.110.101:5106) has not > managed to confirm that its ORPort is reachable. Please check your > firewalls, ports, address, /etc/hosts file, etc. > Apr 21 01:30:09.000 [warn] Your server (xxx.18.110.101:5106) has not > managed to confirm that its ORPort is reachable. Please check your > firewalls, ports, address, /etc/hosts file, etc. > > It looks like the "is reachable" is determined by opening a circuit. > > I see this message several times in the logs: > > Apr 21 01:38:56.000 [info] channel_tls_process_netinfo_cell(): Got good > NETINFO cell from xxx.18.110.101:5002; OR connection is now open, using > protocol version 4. Its ID digest is > 41373151BCC461FEFEFCC1BAF6DCEFD89922014C. Our address is apparently > xxx.18.110.101. > > I don't see any warnings or errors, it looks like the circuits are being > opened successfully. Any ideas why this doesn't translate to getting past > the ORPort being reachable test? If you're using a version of tor before 0.2.6.1, then it's possible that bug #13924 may be the culprit: https://trac.torproject.org/projects/tor/ticket/13924 "Reachability testing and channel is_local assume private addresses are local" (and therefore discount the local/private addresses for the purposes of reachability testing). Alternately, you could have discovered a similar bug which occurs when all tor instances in a network are on the same, public IP address. Please feel free to log a bug if this behaviour is still showing up in tor versions after 0.2.6.1 - and reference #13924 so we know the history of the issue. https://trac.torproject.org/projects/tor/newticket You could also disable reachability testing entirely using: AssumeReachable 1 TestingTorNetworks also allow you to skip several boring minutes of bootstrap by just voting everything a guard and an exit (only in recent versions of tor): TestingDirAuthVoteExit * TestingDirAuthVoteHSDir * Let us know how you go. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 2

Experimenting with private tor setup
by CJ Ess 21 Apr '15

21 Apr '15

I've been experimenting with a private tor setup - I've managed to setup a couple directory authorities, six routers/exit nodes (which seemed to be the minimum to bootstrap everything), and a client. Its a pretty normal setup (aside from everything running on my development box) and passes traffic as expected. So I'm wondering what would happen if I set TestingTorNetwork to 0, so I picked one onion router instance and made that change. Because its all running on one box I had to keep some of the special settings: DirAllowPrivateAddresses 1 EnforceDistinctSubnets 0 AuthDirMaxServersPerAddr 0 AuthDirMaxServersPerAuthAddr 0 ExtendAllowPrivateAddresses 1 And that almost works, I got this far: Apr 21 00:50:09.000 [notice] Bootstrapped 100%: Done Apr 21 00:50:09.000 [notice] Now checking whether ORPort xxx.18.110.101:5106 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Apr 21 01:10:09.000 [warn] Your server (xxx.18.110.101:5106) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Apr 21 01:30:09.000 [warn] Your server (xxx.18.110.101:5106) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. It looks like the "is reachable" is determined by opening a circuit. I see this message several times in the logs: Apr 21 01:38:56.000 [info] channel_tls_process_netinfo_cell(): Got good NETINFO cell from xxx.18.110.101:5002; OR connection is now open, using protocol version 4. Its ID digest is 41373151BCC461FEFEFCC1BAF6DCEFD89922014C. Our address is apparently xxx.18.110.101. I don't see any warnings or errors, it looks like the circuits are being opened successfully. Any ideas why this doesn't translate to getting past the ORPort being reachable test?

1 0

Possible anomaly in meek user graph circa April 15, 2015
by David Fifield 21 Apr '15

21 Apr '15

The latest meek user graph shows two recent large increases. The first increase from 2000 to 3000 is around April 9. The second from 3000 to 5000 is all on April 15. The first increase makes sense; it corresponds with the removal of a bottleneck on meek-azure: https://lists.torproject.org/pipermail/tor-dev/2015-April/008637.html The second one happens all in one day and I don't have an explanation for it. Here are the day-by-day numbers, the same numbers from which the graph is derived: ↓↓ 2015-04-09,bridge,,meek,,,,2584,54 2015-04-10,bridge,,meek,,,,3363,54 2015-04-11,bridge,,meek,,,,3392,51 2015-04-12,bridge,,meek,,,,3531,52 2015-04-13,bridge,,meek,,,,3344,49 ← 2015-04-14,bridge,,meek,,,,5385,53 ← 2015-04-15,bridge,,meek,,,,5113,52 2015-04-16,bridge,,meek,,,,4990,52 2015-04-17,bridge,,meek,,,,5173,51 2015-04-18,bridge,,meek,,,,5422,33 I at first suspected conflation with the statistics of some other transport, like we observed with meek and websocket back in September 2014. https://lists.torproject.org/pipermail/tor-dev/2014-September/007483.html There is a nearly simultaneous increase in obfs4 (also attached); I didn't see anything similar in any other transports. However I checked Onionoo and the only bridges running meek are ones I know about, and they aren't running any other transports. https://onionoo.torproject.org/details?type=bridge {"nickname":"UtahMeekBridge","hashed_fingerprint":"88F745840F47CE0C6A4FE61D827950B06F9E4534","or_addresses":["10.45.162.225:8000"],"last_seen":"2015-04-20 19:48:46","first_seen":"2014-10-24 20:37:04","running":true,"flags":["Fast","Guard","Running","Stable","Valid"],"last_restarted":"2015-04-13 19:14:56","advertised_bandwidth":6517470,"platform":"Tor 0.2.5.12 on Linux","transports":["meek","meek"]}, {"nickname":"TorLandMeek","hashed_fingerprint":"55CD4494A9EC14B74A677A7B7DD356E3417F9E69","or_addresses":["10.60.60.122:443"],"last_seen":"2015-04-16 17:45:30","first_seen":"2015-04-15 18:44:44","running":false,"flags":["Valid"],"last_restarted":"2015-04-15 18:24:47","advertised_bandwidth":3540992,"platform":"Tor 0.2.5.10 on Linux","transports":["meek"]}, {"nickname":"starman","hashed_fingerprint":"AA033EEB61601B2B7312D89B62AAA23DC3ED8A34","or_addresses":["10.243.156.101:9002","[fd9f:2e19:3bcf::24:d1d2]:9002"],"last_seen":"2015-04-20 19:48:46","first_seen":"2014-09-16 06:37:04","running":true,"flags":["Fast","Guard","Running","Stable","Valid"],"last_restarted":"2015-04-09 16:19:58","advertised_bandwidth":2434220,"platform":"Tor 0.2.5.12 on Linux","transports":["meek","meek"]}, {"nickname":"TorLandMeek","hashed_fingerprint":"3FD131B74D9A96190B1EE5D31E91757FADA1A4F3","or_addresses":["10.116.43.196:443"],"last_seen":"2015-04-20 19:48:46","first_seen":"2014-10-14 06:37:04","running":true,"flags":["Fast","Guard","Running","Stable","Valid"],"last_restarted":"2015-04-15 19:02:22","advertised_bandwidth":4125225,"platform":"Tor 0.2.6.7 on Linux","transports":["meek"]}, David

1 0

Visualization of the lizard Sybil attack
by David Fifield 20 Apr '15

20 Apr '15

Check out these pictures of relays in the consensus during November and December. (Warning, the linked images are huge, just look at the downscaled attachments if you want.) November https://people.torproject.org/~dcf/graphs/microdescs/microdescs-2014-11.png (720×13242 pixels) December (spot the anomaly) https://people.torproject.org/~dcf/graphs/microdescs/microdescs-2014-12.png (744×18136 pixels) Each row is one descriptor, and each column is one hour. The rows are sorted so that descriptors with similar uptimes are nearby. The conspicuous narrow vertical stripe in the lower right of the December graph is a few thousand descriptors entering the consensus all at once and then leaving it again. If you want to dig into any patterns you see, the lines of these text files correspond 1:1 to the rows of the images. https://people.torproject.org/~dcf/graphs/microdescs/microdescs-2014-11.txt https://people.torproject.org/~dcf/graphs/microdescs/microdescs-2014-12.txt Source code is in https://people.torproject.org/~dcf/graphs/microdescs/. wget https://collector.torproject.org/archive/relay-descriptors/microdescs/micro… tar xJf microdescs-2014-11.tar.xz tar xJf microdescs-2014-12.tar.xz ./microdescs --output microdescs-2014-11 microdescs-2014-11 ./microdescs --output microdescs-2014-12 microdescs-2014-12 David Fifield

5 7

Urdu & Hindi translations of Tor browser ?
by Griffin Boyce 19 Apr '15

19 Apr '15

Hello all, Whenever I attend events with a large Pakistani or Indian contingent, I'm asked why there isn't an Urdu or Hindi translation of Tor Browser. And I'm not totally sure what to say. There's clearly a large need, given Pakistan's history internet censorship. At a recent event in DC, an activist from Pakistan spoke with me about increased surveillance in recent years, as well as the shocking trend of targeting activists with charges of blasphemy for criticizing the government. (Blasphemy is punishable by death, and those accused frequently do not survive until trial due to mob violence). The situation in India is a bit different, but their need for online privacy much the same as like Pakistan they are subject to mass surveillance. Both populations also have a large number of speakers: ~300M for Hindi and ~66M for Urdu. What do you think? ~Griffin -- “Sometimes the questions are complicated and the answers are simple.” ― Dr. Seuss

4 6

Fwd: Games Without Frontiers: Investigating Video Games as a Covert Channel
by Rishab Nithyanand 19 Apr '15

19 Apr '15

Hey all, I just thought I'd share and get feedback about some recent work from our team at Stony Brook University. I posted this to the tor-talk list earlier and it was suggested to x-post here, too. Title: Games Without Frontiers: Investigating Video Games as a Covert Channel [ http://arxiv.org/pdf/1503.05904v1.pdf ] Abstract: The Internet has become a critical communication infrastructure for citizens to organize protests and express dissatisfaction with their governments. This fact has not gone unnoticed, with governments clamping down on this medium via censorship, and circumvention researchers working tirelessly to stay one step ahead. In this paper, we explore a promising new avenue for covert channels: using video games as a cover protocol. The popularity of platforms like Steam have given rise to a rich population of video games for use as cover. The common properties of games in the same genre simplify the process of adapting channels to evade detection. We demonstrate the feasibility of this approach using two real time strategy games (including a popular closed-source game). We show how common properties of these games can be used to design a coding scheme to translate data into game commands in a way that is general across games and requires little per-game customizations. We evaluate the security of Castle by quantifying its resilience to a censor-adversary, its similarity to real game traffic, and its ability to avoid common pitfalls in covert channel design. We use our prototype to demonstrate that Castle can provide throughput which is amenable to transfer of textual data (\eg e-mail, short articles, etc.). I thought this was a cool idea, and had a lot of fun exploring it. One of the key changes that Castle brings to the PT landscape is easy extensibility and large space diversity -- i.e., it takes very little skill and developer time to port Castle to any of 100's of existing (and perennially releasing) RTS games, in the event that it is detected and blocked for one game. Please check out the paper and feel free to post questions here, or email them to me. Rishab

3 2

Re: [tor-dev] shipping with fallbackdir sources
by teor 18 Apr '15

18 Apr '15

> Date: Sat, 18 Apr 2015 08:51:35 +0200 > From: Peter Palfrader <weasel(a)torproject.org> > >>> On Fri, 17 Apr 2015, Jacob Appelbaum wrote: >>> >>> On 4/17/15, Ian Goldberg <iang(a)cs.uwaterloo.ca> wrote: >>> Remember that the purpose is to help first-time clients, who have never >>> used the Tor network before, fetch their very first consensus. To do >>> that, they'll need addresses to contact bundled into the binary and/or >>> distro without being able to look at a consensus first. Disabling fallback directories in custom Tor networks (Trac #15642) tor currently doesn't disable the list of fallback directories when the DirAuthorities or Alternate{Bridge,Dir}Authorities options are set. This means that any fallback directories will still be used in test, private and custom Tor networks. This could mix descriptors from the public network in with private Tor network in certain circumstances (at the very least, when the private authorities are unreachable). I suspect this is an undiscovered bug in the fallback directories feature. It hasn't really been an issue until now, as the list of fallback directories has been blank. I am also concerned that this general area of the code lacks unit tests, which it might be wise to include before we effectively activate it for the first time. I've created a git branch with a fix in the trac issue #15642 [0]. I've also included unit tests for the function I've modified as a commit in that branch. But there's currently no coverage for the function that adds fallback directories. (In fact, I mock it in my unit tests, because I need it to do *something* so I know if it has been called or not.) Loading from an Authority-Signed file of Fallback Directories The function which loads fallback directories currently loads from a string array inside the function, so it would need to be modified to load from a signed file. I support the security benefits of signed fallback directories enough to write client code and unit tests for it, but I'm not sure how the code for the authorities would work - is the proposal to sign a section of the consensus, and output it as a separate file? If so, we would either need to backport, and/or wait until a majority of the authorities update to tor versions with the feature. And perhaps a majority of clients as well, controlled by a consensus parameter? (Otherwise, using any entry in the file itself would allow clients to effectively be partitioned from the rest of the network by their behaviour.) While I'm making a list, do we need to modify the existing proposal which describes fallback directories? Is this change proposed for 0.2.7? Or all currently supported releases? 0: https://trac.torproject.org/projects/tor/ticket/15642#comment:8 teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

1 0

shipping with fallbackdir sources
by Peter Palfrader 18 Apr '15

18 Apr '15

Hi, so, Tor has included a feature to fetch the initial consensus from nodes other than the authorities for a while now. We just haven't shipped a list of alternate locations for clients to go to yet. Reasons why we might want to ship tor with a list of additional places where clients can find the consensus is that it makes authority reachability and BW less important. At the last Tor dev meeting we came up with a list of arbitrary requirements that nodes should meet to be included in this list. We want them to have been around and using their current key, address, and port for a while now (120 days), and have been running, a guard, and a v2 directory mirror for most of that time. I have written a script to come up with a list of notes that match our criteria. It's currently at https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates It currently produces https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list Discuss :) -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/

3 7

Release: obfs4proxy-0.0.5
by Yawning Angel 17 Apr '15

17 Apr '15

Hello all, I just tagged obfs4proxy-0.0.5, this time with improvements for both clients and servers. All users are recommended to upgrade. Special thanks to mvdan for various code cleanups. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5… Changes in version 0.0.5 - 2015-04-15: - Go vet/fmt fixes, and misc. code cleanups. Patches by mvdan. - Changed the go.net import path to the new location (golang.org/x/net) - Added limited support for detecting if the parent process crashes. - Support for tor feature #15335 (stdin based termination notification). - Moved the leveled logging wrappers into common/log so they are usable in transport implementations. - Added a DEBUG log level. - Use a bundled SOCKS 5 server instead of goptlib's SocksListener. The big features are: - obfs4proxy now tries really hard to detect if the parent process has crashed, using various system specific hacks (and the new and improved tor assisted mechanism in #15335). This should reduce defunct obfs4proxy processes when tor happens to crash without tearing down the obfs4proxy instance. - Instead of using goptlib's SOCKS4a server, obfs4proxy now includes a SOCKS5 implementation, bringing IPv6 support to clients. Note that running IPv6 bridges has always worked (though dual stack configs are currently somewhat broken due to a tor PT configuration protocol limitation). Notes for packagers: - Like in obfs4proxy-0.0.5, one of the upstream dependency locations has changed. (code.google.com/p/go.net -> golang.org/x/net) As far as I am aware, migrating to the new package immediately is not required though, should be done sooner rather than later due to the impending deprecation of code.google.com. To temporarily continue to build against the old go.net dependency, please revert: aed4b723891db1be34eb866a03c62806b58ac148 - It is *strongly* recommended that packages be built against goptlib-0.4 or newer to work around tor bug #15240. Without this workaround, certain bridges will fail to operate correctly when the ExtORPort is enabled (the Tor side fix is in tor-0.2.6.5-rc and newer). Questions, comments, feedback appreciated, -- Yawning Angel

3 3

Summer of Privacy application, Censorship Analyzer
by Miquel Llobet 16 Apr '15

16 Apr '15

Hey tor-dev, I'm a third year Computer Science student interested in doing the Censorship Analyzer project this summer. I just found out about the Summer of Privacy program so I'll do my best to be on time. I find the project very exciting as it can potentially help the TorProject and its users in a big way, specially if we can receive feedback from the tests. I've done a first read of the Censorship Analyzer paper and I'm currently working on the proposal, I expect to submit by tomorrow. As far as coding goes, I played a bit with OONI (did a scan, turns out I'm clean :-) ). and built it from source. What bugs to you recommend to work on as a start? Ideally I can write a patch before the submission is due to attest my skills. Let me know if you have any suggestion or advice on pursuing this project. Best, Miquel

3 3