tor-dev

tor-dev@lists.torproject.org

3581 discussions

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 10 Jul '15

10 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 09 Jul '15

09 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 09 Jul '15

09 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 09 Jul '15

09 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 09 Jul '15

09 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

3rd status report for OnioNS
by Jesse V 09 Jul '15

09 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone, I have been making significant progress on the Onion Name System project, and it's really coming down the home stretch here. * I have been focusing on a four-party system: a hidden service operator, an authoritative server, a name server (mirror), and a client. Thus two servers are involved, so the responsibility is split. * The mirror can now subscribe to the authoritative server for events, thus it receives new Records (claims on domain names) and new signatures on the data structures. The design now prevents the mirror from lying to the client. * After some discussions with others at PETS, I have split my software into four separate repositories and four different packages: tor-onions-hs, tor-onions-client, tor-onions-server, and tor-onions-common. The first three now have a very focused responsibility and have dependencies on the -common package, a shared library that handles configuration parsing, talking to Tor, and other generic tasks. This also means that hidden service operators need only install the -hs package, which reduces the amount of code running on their protected server. * I have organized all the tickets on Github into their respective repository and assigned most of them to milestones to indicate how soon I will be tackling them. * I have also successfully integrated the software into the Tor Browser such that when the Tor Browser starts, Tor and the OnioNS software launch behind the scenes and in the correct order. My modification is a binary substitution rather than recompiling the Tor Launcher, but the result appears to be reliable and greatly simplifies the client end of things. * In the last status report, I discussed work on logging. I have made significant progress on this task, which is now a critical item because the software now runs in the background when launched from the Tor Browser, so normal stdout is not seen. The software logs to <Tor Browser dir>/Browser/TorBrowser/Data/OnioNS/ * I saw DonnchaC's alpha release. I am really working on making a prototype that everyone can beta test. The packaging and integration into the Tor Browser should make this very straightforward, but I need to have all the configurations in place and a few more bugs worked out before then. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJVnnvTAAoJEK2XNk/CC+yATgQH/RSG1rNzUIF9pkyPQFl0YYHP fbor9zzdRXeHIADrnnn4trg4epGW43SCLJ2bpFiI7/keYTe6FFABE8j0W0mB8RbQ cIERbDmfGFBgrPrx0sPxMHj99637sF2j3igIxdln5rtqbvOuXLrgI3F+a6fWdCmr 6GFgTaurGexrCI5ybvqcaMz6p2/eRDuTl+k51gz6cWPzV7mzdCzzU9Gl1miqpS6M UB/RsjMwgGJDpcS/b0hlIXU6Zcsc1Kk3pP+czj99JsychHEUHZFSNB5qsVsDDCHq h/BS44O/v+x2aJg1ZwL6hn02ghn0HE9hapIglERQFLxZ/pQvTsVJzUL2gaL5L8I= =BC+c -----END PGP SIGNATURE-----

1 0

Summer of Privacy: Enhance GetTor
by ilv 07 Jul '15

07 Jul '15

Hello people, I just wanted to let you know that this summer I'll be working in improving the current GetTor. I've wrote about this before here [0] and I detailed my plan for the summer here [1]. Thanks to the nice will of the people running this program and my mentors, I'm starting with a different schedule ("Winter schedule" [2]), which started yesterday :) If you have comments or new ideas about GetTor, I'd love the hear it. Best regards, Israel Leiva. [0] https://lists.torproject.org/pipermail/tor-dev/2015-April/008718.html [1] https://people.torproject.org/~ilv/sop_proposal_2015.html [2] https://trac.torproject.org/projects/tor/wiki/doc/gsoc

1 0

Re: [tor-dev] onionoo: new field: measured flag (#16020)
by l.m 07 Jul '15

07 Jul '15

Hi nusenu, Since you posted to tor-dev I guess you're asking for community input too. About your use cases, Onionoo is for obtaining data about running relays, not tor network health, or BWAuth activity. You can answer this question by looking at the latest consensus data from CollecTor, counting relays, and unmeasured. So this use case is out of the scope of Onionoo use. Your second use case doesn't help the operator debug. What does not being measured mean in the context posed by the ticket? (whichever, boolean or int) a) the relay was not measured b) the relay was supposed to be measured but didn't respond c) the relay was supposed to be measured but the measurement was blocked due to network interference d) the relay was measured but the threshold number of measurements was not obtained ... and so on. Not being measured doesn't help with debugging. The only thing which matters is being `measured` in which case a relay has consensus weight. The only data which can be relied upon, and which is also a property of a running relay that has been measured is consensus weight. You can track this using the Weights document. I hope that helps --leeroy

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev