- tor-dev - lists.torproject.org

HTTPS Everywhere harmful
by Maciej Soltysiak 25 Apr '15

25 Apr '15

http://www.w3.org/DesignIssues/Security-NotTheS.html Maciej

4 3

Impending Facebook Onion-Site Certificate Changes
by Alec Muffett 24 Apr '15

24 Apr '15

Hello All! Details: https://www.facebook.com/facebookcorewwwi/posts/703469239759799 <https://www.facebook.com/facebookcorewwwi/posts/703469239759799> Summary: new EV-style SSL certificate rolls out to facebookcorewwwi.onion next week. - alec — Alec Muffett Security Infrastructure Facebook Engineering London

1 0

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

23 Apr '15

> Date: Wed, 22 Apr 2015 01:05:44 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > On Tue, Apr 21, 2015 at 9:01 AM, teor <teor2345(a)gmail.com> wrote: > > > > 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. … > > > 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 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). … > I found the problem here: > https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383f… > > The check for channel_is_local returns true because my dev box has an > 172.16/12 address: > > https://github.com/torproject/tor/blob/725d6157df150ec9151450dc2422d9838c20… > > And thats what is keeping everything from working. The 172.16/12 block is a private address block. https://en.wikipedia.org/wiki/Private_network tor assumes that connections from private addresses are local. It doesn't update its reachability self-testing flag unless it gets a connection from a non-local address. This restriction is relaxed when TestingTorNetwork is set, as many test networks use private address blocks. > I commented out that > address block and now orport, dirport, and bandwidth tests are running. Commenting out a private address range is a dangerous change that has at least the following security implications: * "ExitPolicyRejectPrivate 1" won't stop clients exiting to the block you've commented out (warning, you have this set to the default, 1) * "ExtendAllowPrivateAddresses 0" won't stop clients extending to the block you've commented out (but you have this set to 1) * "DirAllowPrivateAddresses 0" won't exclude directory nodes with IPs in the block you've commented out (but you have this set to 1) As long as you trust your entire network, including any clients that can connect to any open ports, this should not be a problem. But please don't use versions of tor with this change on the public Tor network, you'd be opening yourself up to attack. It appears that my original fix to bug #13924 didn't anticipate anyone using "ExtendAllowPrivateAddresses 1" without "TestingTorNetwork 1". I'll submit a patch which swaps TestingTorNetwork for ExtendAllowPrivateAddresses. This will preserve the existing fix, because "TestingTorNetwork 1" implies "ExtendAllowPrivateAddresses 1". The relevant line is here: https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383f… In the interim, if you'd like a safer option, you could make the same code change to that line, or disable reachability testing entirely using "AssumeReachable 1". 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 3

Re: [tor-dev] tor-dev Digest, Vol 51, Issue 34
by Rekha Tokas 23 Apr '15

23 Apr '15

Can I get the list of websites which are blocking tor traffic to view or edit their page ?? On 23 Apr 2015 17:30, <tor-dev-request(a)lists.torproject.org> wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Experimenting with private tor setup (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Apr 2015 21:27:40 +1000 > From: teor <teor2345(a)gmail.com> > To: "tor-dev(a)lists.torproject.org" <tor-dev(a)lists.torproject.org> > Subject: Re: [tor-dev] Experimenting with private tor setup > Message-ID: <4942EA68-C681-4223-8A3B-A5E0C97E296F(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > > Date: Wed, 22 Apr 2015 23:14:07 -0400 > > From: CJ Ess <zxcvbn4038(a)gmail.com> > ? > > I think that just leaves a couple questions for now: > > > > - I know the directory authority's certificate needs to be > > renewed periodically (looks like 12 months default). Since it asked for a > > password that is something I need to do manually then send a HUP, > correct? > > Later on I'll try to hack generating a cert with days or hours of time > just > > to see what happens, but would like to know what the correct way to > handle > > it is. > > Yes, you will need to generate new authority certificates when they expire. > > Look at "man tor-gencert" for more details - you may be able to enter a > blank password, or generate a new certificate and send a HUP on a cron job. > Alternately, look at the chutney source code for how it's done there. (This > isn't my area of expertise.) > > > - All of my routers have done the bandwidth tests, but I see this warning > > on the DAs with each vote: > > > > Apr 22 22:39:41.000 [warn] Consensus with empty bandwidth: G=0 M=5 E=0 > > D=243 T=248 > > > > Is this something that will fill out as the uptime of the instances > > increase? Or is this something I should look into? > > I think you need to run a separate bandwidth authority to get bandwidths > in your consensus. This probably isn't necessary for your purposes, as your > instances are all on the same host. > > It's also not something that chutney does, and chutney networks function > fine. > > 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 >

1 0

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

23 Apr '15

> Date: Wed, 22 Apr 2015 23:14:07 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> … > I think that just leaves a couple questions for now: > > - I know the directory authority's certificate needs to be > renewed periodically (looks like 12 months default). Since it asked for a > password that is something I need to do manually then send a HUP, correct? > Later on I'll try to hack generating a cert with days or hours of time just > to see what happens, but would like to know what the correct way to handle > it is. Yes, you will need to generate new authority certificates when they expire. Look at "man tor-gencert" for more details - you may be able to enter a blank password, or generate a new certificate and send a HUP on a cron job. Alternately, look at the chutney source code for how it's done there. (This isn't my area of expertise.) > - All of my routers have done the bandwidth tests, but I see this warning > on the DAs with each vote: > > Apr 22 22:39:41.000 [warn] Consensus with empty bandwidth: G=0 M=5 E=0 > D=243 T=248 > > Is this something that will fill out as the uptime of the instances > increase? Or is this something I should look into? I think you need to run a separate bandwidth authority to get bandwidths in your consensus. This probably isn't necessary for your purposes, as your instances are all on the same host. It's also not something that chutney does, and chutney networks function fine. 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

1 0

Summer of Privacy: Enhance GetTor
by ilv 22 Apr '15

22 Apr '15

Hi people, My name is Israel Leiva. I'm a student of BSc. in Computer Science at Universidad de Santiago de Chile. I'm also the maintainer of GetTor and one of the students selected for Tor Summer of Privacy. This summer I'll be working on GetTor, improving what I did in last year's GSoC and adding new stuff. In short, I will: * Improve stats and debugging. * Deploy more providers: GDrive, GitHub. * Enable more distributions channels: XMPP, Twitter. * Create tests for GetTor. * New features, like send mirrors list and localized Tor Browser. I started to work on most of this stuff in last year's GSoC, and I will finish it during this TSoP. For more details, you can read my proposal 'Enhance GetTor' on [0]. My mentors will be Sukhbir and Nima. I'm really happy to be working at the Tor Project again and I hope to do my best. If you have comments or new ideas about [0], I'm all ears [0] https://people.torproject.org/~ilv/sop_proposal_2015.html Have a nice day! --ilv

1 0

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