- tor-dev - lists.torproject.org

Linting the ' iff ' ism...
by grarpamp 17 Jul '15

17 Jul '15

There are about 350 places in tor and torspec that are afflicted by this ism, other locations surely exist... find . -type f -exec egrep -i ' ' {} \+

3 3

Fwd: Changes to ExoneraTor for this week's TWN
by Karsten Loesing 15 Jul '15

15 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, Jens asked me to forward this email here, so that other people can follow the recent changes we made to ExoneraTor. https://exonerator.torproject.org/ Harmony did a wonderful job summarizing these changes even more in this week's TWN issue. Thanks, harmony! Of course, if you're curious about the details, be sure to check out the commits and/or tickets: https://gitweb.torproject.org/exonerator.git/ https://trac.torproject.org/projects/tor/query?status=!closed&component=Exo… All the best, Karsten - -------- Forwarded Message -------- Subject: Changes to ExoneraTor for this week's TWN Date: Wed, 15 Jul 2015 12:51:17 +0200 From: Karsten Loesing <karsten(a)torproject.org> To: harmony <harmony01(a)riseup.net> CC: Tor Assistants <tor-assistants(a)lists.torproject.org> Hi harmony, here's a quick overview of improvements made to ExoneraTor in the past days in no specific order: - Restrict searches to dates: Rather than allowing searches by timestamp we restrict searches to full dates. Most people don't understand timezones nor that all our dates and times are in UTC. Letting them specify a precise time makes it more likely that they'll search for the wrong thing. The timezone problem doesn't go away by limiting searches to full days (if their incident happened on February 17 at 9pm EST, would they know that it was already February 18 in UTC?). But we can easily widen searches to +/- 1 day. The technical details still contain hours. - No raw descriptors anymore: We stopped processing server descriptors and linking raw descriptors in the latest version of ExoneraTor. The idea was to simplify the service and make it useful for the average user who doesn't care about this level of detail. And it's a good opportunity to prevent the database from growing even larger. - No target addresses and ports anymore: If there's a result to the question "Was there a Tor relay running on this IP address?", do not offer a subsequent form to answer the question "Was this relay configured to permit exiting to a given target?". The second search increases complexity of searches a bit, and it's unlikely that people would interpret results correctly. The technical details now contain an "Exit" column that indicates whether a relay permitted transit of Tor traffic to the open Internet at that time. - New non-technical explanations of Tor and ExoneraTor: We rewrote the text that explains what Tor is and what ExoneraTor does, and we tried to make it as non-technical and still accurate as possible. - Translations: There's now a translation to German, and we're currently making plans for adding more translations. The difficulty is that we'll want those translations to also be as non-technical and still accurate as possible. - New design: We're now using a basic Bootstrap design which is already much cleaner than the previous design, but which still leaves room for improvement. Hope I didn't miss anything important. Please feel free to pick whatever you find most important, and feel free to rephrase as needed. Sorry, gotta run! Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVplkAAAoJEJD5dJfVqbCrJDkH/3ie20NA7cCgLtwbpPwuJHdR EXgRQ/sBHzPHUNV+NmesG95jcKfUe/XcEDFYisa/ayrwWpTap+cOek7/02uM4RD/ J3Ik0xk7m0Cwo2nxPWhHYOtmF97Yv33zE26rbh6+Fix7b9O5xNgTLJ53k3rvhNKy xRKm5DM6blXYppJpeYdmTP0k1wJdiy/qsETScKWldBGlOtXdmNKwrncxZ+tg5Z2b 57VZvXSUKx0rRTCh2LuOYUcmyLuX9XqpJOKrdwQ+BcATETuaklWLEH55iSJN1d/h GNsVrhPgEz/VwKzJ472s+Xssrgmh7lk80sIoYxGn46J6VLg80a8GJVCo2qznNQ8= =+3gk -----END PGP SIGNATURE-----

1 0

packaging advice needed
by Magnus Hedemark 15 Jul '15

15 Jul '15

Hello, I have set up a Jenkins CI server and have it tracking the Tor project's git repository. I'm going to be building packages for the OmniOS platform, which is not yet supported. I tried searching the site for advice for packagers but haven't found any. If I've overlooked it, I'd appreciate a nudge in the right direction. More specifically, I'd like to better understand the release and patch workflow that is followed so that I can build the right commits at the right time. I'll have one job tracking the master branch for those who want to test potentially unstable software, but I have another job intended to promote "stable" packages. By the way, this is all a precursor to a set of articles showing how to create network-isolated hidden services inside of illumos zones. I think OmniOS has a lot of untapped potential to help hidden service operators. TIA, Magnus Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland.

4 3

Re: [tor-dev] Tor Browser videos Automation
by Isabela 12 Jul '15

12 Jul '15

+ tor-dev Sorry for the noise, but thought of expanding the audience a little, maybe someone the time to take look into this, or might know what is going on. Any help is appreciated, we are trying to finish this project and this has been blocking us. Thanks! Sherief Alaa: > On Mon, May 18, 2015 at 3:49 PM, Mark Smith <mcs(a)pearlcrescent.com> wrote: > >> On 5/17/15 6:54 AM, Sherief Alaa wrote: >> >>> Hi Georg/Mark, >>> >>> I am working on the new Tor Browser videos this month (or at least a >>> process to produce them in an automated manner). I am contacting you >>> because I am running into a problem that you may know how to solve >>> because I think it's browser related. >>> >>> Karsten insisted that I have to run a local copy of torproject.org >>> <http://torproject.org> using a web server while the automated script >>> runs since we can't estimate or depend on the connection speed. The >>> major blocker in this is that the browser redirects to >>> https://torproject.org/ whenever I try to map 127.0.0.1 to >>> torproject.org <http://torproject.org> (or www.torproject.org >>> <http://www.torproject.org>) in my /etc/hosts file. Now I've tried >>> everything that will come up to mind that may solve the problem, such >>> as: flushing DNS cache, clearing history, disabling all addons and more >>> but nothing worked. >>> >>> I also ran Wireshark to inspect DNS packets but the browser doesn't even >>> try to query any DNS server. >>> >>> I've tested on OS X and Ubuntu and both produce the same results. I've >>> also tested multiple browsers (Safari, Chrome and Firefox). Same results. >>> >>> Trivial note: During testing, I could map google.com >>> <http://google.com>, ign.com <http://ign.com> and basically all .coms >>> but never for .orgs like eff.org <http://eff.org> or torproject.org >>> <http://torproject.org> >>> >>> If you have any idea what's going on, please let me know as soon as >>> possible as I am considering running a local nameserver but I am keeping >>> that as a last resort. >>> >> I do not know what is going on. Most likely it is a caching problem (both >> the OS and browser cache DNS info, as you know). But Kathy (CC'd on this >> reply) and I experimented a little on Mac OS 10.9.5 and found like you did >> that some hosts worked and some did not, even after doing dscacheutil >> -flushcache and using Firefox with a new profile. From the command line, >> ping always seems to respect /etc/hosts but other things such as curl do >> not. Which I guess means it is an OS caching issue, or some applications >> have their own DNS resolver that bypasses the OS libraries. >> >> -Mark >> > Ccing Isabela > > > -- > PM at TorProject.org > gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B > @isa

3 4

Two new tech reports on website fingerprinting
by t55wang＠cs.uwaterloo.ca 11 Jul '15

11 Jul '15

I'd like to introduce two new works on website fingerprinting I've written with my supervisor, Ian Goldberg. The first is titled ``On Realistically Attacking Tor with Website Fingerprinting''. We talk about methods to allow website fingerprinting to perform under realistically difficult scenarios. We have a tech report here: http://cacr.uwaterloo.ca/techreports/2015/cacr2015-09.pdf The second is titled ``Walkie-Talkie: An Effective and Efficient Defense against Website Fingerprinting''. We propose a new website fingerprinting defense that is practically efficient and provably effective. We have a tech report here: http://cacr.uwaterloo.ca/techreports/2015/cacr2015-08.pdf Our code for both of those works are here: https://crysp.uwaterloo.ca/software/webfingerprint/ In the code we have an implementation of a website fingerprinting attack that can take a long series of web page accesses (as one packet sequence) as input, and output if it has recognized any page in the sequence. We also have an implementation of half-duplex communication for Tor Firefox as the core of Walkie-Talkie. Tao Wang

3 2

Env variables for chutney
by Cory Pruce 10 Jul '15

10 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Tim, I see that I may need to set some environment variables as told by the git readme but the error message is on a different env var: cory@Nulix ~/tor/tor =) make test-network make all-am make[1]: Entering directory `/home/cory/tor/tor' make[1]: Leaving directory `/home/cory/tor/tor' ./src/test/test-network.sh test-network.sh: missing 'chutney' in CHUTNEY_PATH (~/tor/chutney/) make: *** [test-network] Error 1 I also tried modifying my .bashrc so that the CHUTNEY_PATH pointed to the executable but no luck. Do I need to set the chutney path? - - Cory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVluRoAAoJEB7DuCIJauCgUNUQAICDPM+vQ1YPU36B13beWgsX OUN6wQKdjtnRP9aCvusf49vomr+E8g2JcIvR+KiRKTDtnvVUMijsl1TZCmyTptEh 61opZJBweCP78MGuaeMXjJg3Ijw5vFDV6tszJ+Z/5xY/f2PinKO2Db+JWI1/oSP3 kMERE/Va+ehL8u4Nx/meP9VzVQDFZH1nz381FQFAPFYSv9+JR1x4HFGWLElOH0l8 1+hcGhhtRD5mzYoDLIx6Lr/3jIJxmbJiiOmpNQcfW3ISHTrgOB/Wo2n6oO/OcjEk L66YvFpZNYqWQ8ZXf+ZN3cC/+sTpWvYDOcdKv9LJvEmHNSevmU+i2+nMoeanpXzX z5eYNCE9unfitNg6hPoQ8x7wD+LLpBDEA42QoQVzx26WMCk3ziu9JIsI5/VfZ7Is /Ny+gQ4jv1Jlk+SEu6ZmRVuyN8sipXnkseXGcpqVR9HBWe7Hy+RfUpODhR3cOy7o EBClLrP8s4H0PUb2WYU4IQrIp2xy8cqqCIaDhs4XLhdXgaX2667irM9uEPw6ZMhL vceyU0LM0v5O+FfzFtdUC4QwfLAbzbiwRi+w74c6bneWWFTi/w5RRaNUiv/IZVMW XTh22mRIOkZXQ3dTc2TsI4TjhT2U95oMiO8hFjDBTS9RfZk/w+unToyJ2aed4UxK 9WC/r/vqUpgD4mljBr76 =9Cvw -----END PGP SIGNATURE-----

3 15

CollecTor data: mapping bridge-network-status to bridge-server-descriptor to bridge-extra-info
by David Fifield 10 Jul '15

10 Jul '15

I'm trying to use CollecTor data to find out how much bandwidth is offered by different pluggable transports over time. I.e., I want to be able to say something like, "On July 1, bridges with obfs3 offered X MB/s, bridges with obfs4 offered Y MB/s," etc. To do this, I'm mapping through three types of CollecTor documents: bridge-network-status (where the bandwidth is and which links to router digests) bridge-server-descriptor (which links to extra-info digests) bridge-extra-info (where the transports are) I'm having trouble because sometimes, a router digest listed in a bridge-network-status document is not found in the same tarball. https://collector.torproject.org/archive/bridge-descriptors/bridge-descript… Here is an example of what I'm doing, using the above tarball. bridge-descriptors-2015-07/statuses/04/20150704-000350-4A0CCD2DDC7995083D73F5D667100C8A5831F16D This is a bridge-network-status document. One of its entries is: r starman qgM+62FgGytzEtibYqqiPcPtijQ mdOOBxVOTpw8loBezhSDZxLIcXs 2015-07-03 21:39:31 10.174.163.60 9002 0 s Fast Guard Running Stable Valid w Bandwidth=2646 p reject 1-65535 The second base64-encoded string is the router digest. base64decode("mdOOBxVOTpw8loBezhSDZxLIcXs") = 99D38E07154E4E9C3C96805ECE14836712C8717B bridge-descriptors-2015-07/server-descriptors/9/9/99d38e07154e4e9c3c96805ece14836712c8717b Now we go looking for a bridge-server-descriptor with router digest 99D38E07154E4E9C3C96805ECE14836712C8717B, which is in the above file. It has a line: extra-info-digest D69106C8BAF5C0044F7331F24DF77E85BBF84027 bridge-descriptors-2015-07/extra-infos/d/6/d69106c8baf5c0044f7331f24df77e85bbf84027 Now we find a bridge-extra-info with digest D69106C8BAF5C0044F7331F24DF77E85BBF84027 in the above file. It tells us what transports the bridge supports (there are two, one for IPv4 and one for IPv6): transport meek transport meek Here's an example of where it goes wrong. bridge-descriptors-2015-07/statuses/01/20150701-060138-4A0CCD2DDC7995083D73F5D667100C8A5831F16D r Unnamed ABk0wg4j6BLCdZKleVtmNrfzJGI eGIOW1mGM/Dbw+t5bXnR8jdnsoY 2015-07-01 05:56:14 10.123.124.91 443 0 s Fast Running Stable Valid w Bandwidth=156 p reject 1-65535 We are looking for router digest 78620E5B598633F0DBC3EB796D79D1F23767B286: base64decode("eGIOW1mGM/Dbw+t5bXnR8jdnsoY") = 78620E5B598633F0DBC3EB796D79D1F23767B286 But there is no file bridge-descriptors-2015-07/server-descriptors/7/8/78620e5b598633f0dbc3eb796d79d1f23767b286. However, I did find it in the previous month's tarball, https://collector.torproject.org/archive/bridge-descriptors/bridge-descript… bridge-descriptors-2015-06/server-descriptors/8/3/835a43ff89db9c1be8ddf7536d759875878620e7 It seems rare that the bridge-server-descriptor is missing. In the 2015-07 tarball, it happened for 5891/477496 relays (1.2%). An additional 4/477496 (0.0%) had a bridge-server-descriptor but were missing bridge-extra-info. How do you handle cases like this? I had a browse through the Onionoo source code, but did not quickly understand it. Should I just always include the month preceding the earliest month I want to process?

3 4

Update: Proposal 237 - All relays are directory servers
by Matthew Finkel 10 Jul '15

10 Jul '15

Hi All, Here's an updated version of prop 237. I rewrote some parts for clarity and brought it inline with the current implementation for #12538. Updated branch on prop237_update in my torspec repo. Thanks! Matt

2 1

tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12
by aexlfowley＠web.de 10 Jul '15

10 Jul '15

Hi devs, User here. teor send me over from IRC. It's regarding to this trac-ticket https://trac.torproject.org/projects/tor/ticket/16518 After upgrading from 0.2.5.12 (git-3731dd5c3071dcba) to 0.2.6.9 (git-145b2587d1269af4) an error occured. I'm on Debian Jessie (stable) on an AMD Athlon 64 X2. Tor won't start and these are the last lines in log: [warn] Couldn't open "/media/cRAID/Tor/lock" for locking: Read-only file system [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. Here's the full log: http://www.file-upload.net/download-10748122/aexllog.gz.html Here's also a pastebin of some shell commands I did for the IRC chat: http://lpaste.net/136099 debug just also contains: [debug] tor_disable_debugger_attach(): Attemping to disable debugger attachment to Tor for unprivileged users. [debug] tor_disable_debugger_attach(): Debugger attachment disabled for unprivileged users. [info] tor_lockfile_lock(): Locking "/media/cRAID/Tor/lock" teor thinks that I "could be experiencing an issue with the tor sandbox and not getting the right paths or, tor is running with insufficient permissions" teor's help and mindfulness was much appreciated. It lasted about 7 days for me to realize that Tor wasn't running. I'm now operating 0.2.5.12 successfully, hoping that it's still secure. Kindest regards

7 12

Today's openssl vulnerability; preliminary analysis wrt Tor
by Nick Mathewson 10 Jul '15

10 Jul '15

tl;dr: CVE-2015-1793 does not appear to affect Tor. Update your OpenSSL anyway; other applications are certainly affected. Hi, all! Here's the announcement for today's major security issue in OpenSSL1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o: https://www.openssl.org/news/secadv_20150709.txt So far, I have only looked at the announcement itself, and the commit messages--not yet the code. But from what I can tell, it should only affect programs that have trusted certificates in their store. Tor itself does not use trusted root certificates, so it is not affected. (Similarly, TorBrowser should not be affected: it uses NSS, not OpenSSL.) Still, you likely have lots of other programs that depend on OpenSSL and trusted certificates to build certificate chains, and those programs _will_ be affected. So, you should probably upgrade OpenSSL as soon as feasible. (I'll spend a little more time patches and reviewing Tor's code to confirm my analysis above, and I invite others to do so as well. I'm in recovery from my vacation today.) best wishes, -- Nick

1 0