- tor-dev - lists.torproject.org

Call for testing/review: obfsclient-0.0.1
by Yawning Angel 25 Aug '14

25 Aug '14

Hello all, I just tagged the obfsclient v0.0.1 (Release) Download at: https://github.com/Yawning/obfsclient/releases/tag/v0.0.1 Major changes since 0.0.1-rc2: * Invalid padding lengths in obfs3/ScrambleSuit handshakes are now correctly handled. * Handshake timeout is now set to a random interval between 60 and 120 seconds. * The ScrambleSuit probability distributions are now closer to what obfsproxy generates. * "--version" will now cause obfsclient to print the version and exit. * Various code cleanups. Some notes about ScrambleSuit: * I reverted the "workaround" I had for bug #11100, so Session Ticket handshakes to bridges running obfsproxy 0.2.6 will fail if they have been running long enough to trigger the bug condition. * Actual protocol behavior is closer to obfsproxy than my previous releases, but still not identical to 0.2.7. the next obfsproxy release will close the difference further. Hopefully it is of some use to people. Special thanks to Fabian Keil for help testing and fixing the various release candidates. Questions, comments, feedback appreciated as always, -- Yawning Angel

2 4

Damian's Status Report - August 2014
by Damian Johnson 24 Aug '14

24 Aug '14

Hi all, getting my status report out of the way a tad early. Deadlines for my day job at Amazon required working a weekend so April was mostly spent just getting caught up on code reviewing contributions... * Nick Mathewson greatly improved Stem's performance at parsing consensus documents. Thanks Nick! (#12859) * Rewrote Nick Hopper's patch for verifying consensus signatures. I'd really love to merge it, but it needs tests first. (#11045) * Code reviewed federico3's addition of better Controller methods for handling hidden service config options. (#12533) * Fixed stylistic issues cited by the newly released pep8 1.5.7, and also corrected a handful of python 3.x test failures. * Code reviewed a BridgeDB change to take advantage of Stem for isis. (#9380) * GSoC finals are finished! This year had a lower pass rate than we usually do (four of our thirteen students didn't pass), but I don't think there's necessarily any lessons to draw. This concludes my backlog of things I owe other people, so next up I'll finally be getting back to arm development! -Damian

1 0

[GSoC] Consensus diffs - Sixth report
by Daniel Martí 24 Aug '14

24 Aug '14

Hello everyone, This is the sixth and last status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. Two weeks ago I had two main tasks left for the project to get to a minimal functioning state. The first was to figure out a clean way to cache old consensuses on disk. The second was to write the fetching of consensus diffs, and the corresponding serving of consensus diffs via spooling. Both of these were done, and last week I was able to launch a small local network via chutney and finally see consensus diffs be properly generated, served, fetched and applied. The hard pencils down date is tomorrow evening. I want to polish things up a bit and try to find last-minute bugs. Of course there will be quite a bit of work left once GSoC is over to get the outcome of this project included in Tor. Other than that, I'm quite happy with how the project turned out. I intend to continue contributing to Tor, at least to the extent of getting the code merged into master and fixing any bugs that may arise until it is suitable for a stable release. I'll continue pushing my work on Github [1] for now. See the "readme" branch for reference on what the consdiff-N branches mean. Regards. [1] https://github.com/mvdan/tor -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

3 2

Reminder: OONI dev meetings Friday 15:00 UTC (17:00 CET)
by Arturo Filastò 21 Aug '14

21 Aug '14

Hello Oonitarians, This is a reminder that the weekly dev meeting will be happening on the #ooni channel on irc.oftc.net this Friday (tomorrow and every following Friday) at 15:00 UTC (17:00 CET). Everyone is invited. ~ Art.

1 0

Fwd: [guardian-dev] Orfox: New Firefox-based Android Private/Secure Browser
by Nathan Freitas 21 Aug '14

21 Aug '14

Nice outcome from GSoC! I think the primary discussion here is whether Tor Browser's existing build system can be extended for Android, and whether "Orfox" should exist at all as separate app/project. -------- Forwarded Message -------- Subject: [guardian-dev] Orfox: New Firefox-based Android Private/Secure Browser Date: Wed, 20 Aug 2014 12:49:33 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> Organization: The Guardian Project To: guardian-dev <guardian-dev(a)lists.mayfirst.org> Based on work done this summer by Amogh Pradeep during his Google Summer of Code stint with me, we now have a real working version of Firefox/Fennec for Android with all the necessary defaults changed to match Tor Browser's defaults as closely as possible. We also remove the Android permissions for things like camera, mic, GPS and turn off webrtc. You can see the primary commits we've made here (many by me, but started successfully by Amogh): https://github.com/guardianproject/gecko-dev/commits/adaa37949dbba690ed0392… We still need to figure out which preferences and features map between the desktop mobile browser and the Android version, so there is quite a bit of work to do. For instance, even though the preference from Tor Browser is set to start in private browsing mode, it doesn't work at all in the Android app. Also, we haven't applied any of the lower level source patches to the gecko engine yet, or included any of the default extensions like HTTPS Everywhere or NoScript. Sorting out and resolving these differences is what is on deck for this fall, and everyone is welcome to join in. In addition, the recent audit work from iSec (https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardeni…) is also on our minds, and figuring out how we can live up to the goals of that study on a mobile device is also very important. The current build successfully passes the DNSLeakTest.com tests and passed the HTML5 video leak issue here: http://xordern.net/why-you-really-shouldn't-use-orweb-anymore.html ip-check.info still doesn't see the browser as being Tor Browser, so there are some differences yet to resolve there. The whole project is automatically building on our jenkins server, and you'll find all the links to APKs and our test build repo below. Over the next few months we hope to launch this as our new official browser for Orbot, and deprecate Orweb as quickly as possible. *** Main project repo: https://github.com/guardianproject/OrfoxFennec Our fork of Mozilla's Gecko-Dev: https://github.com/guardianproject/gecko-dev/tree/adaa37949dbba690ed0392c1f… (which we can rebase on the original as needed) Nightly/dev builds direct APK download here: https://guardianproject.info/builds/OrfoxFennec/ OR our fdroid test build repo: https://dev.guardianproject.info/fdroid/repo?fingerprint=F8ED4C73C125E7A67F… *** +n _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

3 5

GSoC : Rewrite Tor Weather (Status Update 6)
by Sreenatha Bhatlapenumarthi 19 Aug '14

19 Aug '14

Hey folks! This is my 6th and final GSoC status update on the Weather-Rewrite project. Things I worked on since my last update : - Wrote a small python script to clear the subscription data stored in the django models of the weather database before running the standalone scripts. This is particularly useful while testing the site. - Fixed some bugs in the daily script. - Tested the whole thing after removal of the consensus event-listener mechanism with file-based SMTP backend as well as gmail SMTP server with a test email setup. - Modified the standalone daily/hourly scripts to work as custom django management commands as suggested in #10706. - Updated documentation regarding the shift in data backend to Onionoo. - Style-aligned the code base with PEP8. To review the code, check out https://github.com/meejah/tor-weather/tree/develop As a note on collaborating with the Tor community during this summer through GSoC, I want to mention that I had great time with this and will try to keep making meaningful contributions via various development activities. Thank You for the experience. Cheers, Sreenatha

1 0

ooniprobe 1.1.0 is out!
by Arturo Filastò 19 Aug '14

19 Aug '14

Hello beautiful humans! We are very pleased to announce that a new version of ooniprobe is now out. In this new release of ooniprobe we have added a new command line tool for listing the reports that have not been published to a collector and that allows the probe operator to choose which ones they would like to upload. We have also made some privacy improvements to the reports (we will sanitize all things that may look like file paths) and added metadata associated with the maxmind database being used by the probe operator. Here is a more detailed list of what has been done: * Annotate on disk which reports we have submitted and which ones we have not: https://trac.torproject.org/projects/tor/ticket/11860 * Add tool called oonireport for publishing unpublished ooniprobe reports to a collector: https://trac.torproject.org/projects/tor/ticket/11862 * Probe Report does not leak filepaths anymore: https://trac.torproject.org/projects/tor/ticket/12706 * Reports now include version information about the maxmind database being used: https://trac.torproject.org/projects/tor/ticket/12771 * We now do integrity checks on the ooniprobe.conf file so that we don't start the tool if the config file is missing some settings or is not consistent: https://trac.torproject.org/projects/tor/ticket/11983 (thanks to Alejandro López (kudrom)) * Improvements have been made to the sniffer subsystem (thanks to Alejandro López (kudrom)) * Fix the multi protocol traceroute test. https://trac.torproject.org/projects/tor/ticket/12883 Minor bug fixes: * Fix dns_spoof test (by kudrom) https://trac.torproject.org/projects/tor/ticket/12486 * ooni might not look at requiresTor: https://trac.torproject.org/projects/tor/ticket/11858 * ooni spits out gobs of tracebacks if Tor is not running and the OONI config says it will be: https://trac.torproject.org/projects/tor/ticket/11859 * The README for ooni-probe should mention the bugtracker and repository https://trac.torproject.org/projects/tor/ticket/11980 For the moment you can download the new version from pypi here: https://pypi.python.org/pypi/ooniprobe. Soon a there will also be a new debian package for it (thank to Lunar^). As always feedback is greatly appreciated so please submit any bugs you may find to our bug tracker: https://trac.torproject.org/projects/tor/newticket?component=Ooni Have fun! ~ Art.

1 0

Re: [tor-dev] Proposal: All Relays are Directory Servers
by Tim 19 Aug '14

19 Aug '14

On 19 Aug 2014, at 22:00 , tor-dev-request(a)lists.torproject.org wrote: > Date: Tue, 19 Aug 2014 01:32:25 +0000 > From: Matthew Finkel <matthew.finkel(a)gmail.com> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Proposal: All Relays are Directory Servers > Message-ID: <20140819013224.GB3689@localhost> > Content-Type: text/plain; charset=utf-8 > > On Mon, Aug 18, 2014 at 02:17:28PM -0400, Nick Mathewson wrote: >> On Wed, Aug 13, 2014 at 11:53 AM, Matthew Finkel >> <matthew.finkel(a)gmail.com> wrote: > >>> Filename: xxx-directory-servers-for-all.txt >>> Title: All relays are directory servers >>> Author: Matthew Finkel >>> Created: 29-Jul-2014 >>> Status: >>> Target: 0.2.6.x >>> >>> Overview: >>> >>> This proposal aims at removing part of the distinction between the >>> relay and the directory server. Currently operators have the options >>> of being one of: a relay, a directory server, or both. With the >>> acceptance of this proposal the options will be simplified to being >>> either only a directory server or a combined relay and directory >>> server. All relays will serve directory requests. >> >> FWIW, we don't support being only a directory server right now, do we? >> > > Nope, you're right. Bad assumption. > > https://gitweb.torproject.org/tor.git/blob/390728d85644a6c062d6807ffc096343… Looking at the details of parse_ports(), the warning/comment isn't entirely accurate: it seems that any configured "port" is enough to disable the warning (even a DirPort, ControlPort/ControlSocket(!), or ExtORPort). Which is why I'm not seeing it on the directory-only tor instance I have configured. Then again, the core message is accurate - a tor instance that doesn't act as a tor client or relay isn't going to do much. Tim

1 0

Re: [tor-dev] Proposal: All Relays are Directory Servers
by Tim 19 Aug '14

19 Aug '14

> On 19 Aug 2014, at 11:30, Nick Mathewson <nickm(a)freehaven.net> wrote: > > Date: Mon, 18 Aug 2014 14:17:28 -0400 > From: Nick Mathewson <nickm(a)freehaven.net> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Proposal: All Relays are Directory Servers > > >> On Wed, Aug 13, 2014 at 11:53 AM, Matthew Finkel >> <matthew.finkel(a)gmail.com> wrote: >> Hi All, >> >> Below is the proposal for #12538 [0], with some changes after George's >> review and some other revisions. >> >> Feedback welcome! >> >> Thanks, >> Matt >> >> >> [0] https://trac.torproject.org/projects/tor/ticket/12538 > > Thanks! This is now proposal 237. Any revisions should be sent in as > patches against the one in the torspec repository. > >> Filename: xxx-directory-servers-for-all.txt >> Title: All relays are directory servers >> Author: Matthew Finkel >> Created: 29-Jul-2014 >> Status: >> Target: 0.2.6.x >> >> Overview: >> >> This proposal aims at removing part of the distinction between the >> relay and the directory server. Currently operators have the options >> of being one of: a relay, a directory server, or both. With the >> acceptance of this proposal the options will be simplified to being >> either only a directory server or a combined relay and directory >> server. All relays will serve directory requests. > > FWIW, we don't support being only a directory server right now, do we? I've recently configured a tor instance [for HTTP fuzzing] that does nothing but cache the entire directory - all that is required is setting the DirPort non-zero, and the ORPort to 0. No warnings are emitted, and the instance stays stable, up to date with the consensus and descriptors, and answers [local] directory requests [as configured]. Because it's a local/test instance, I have specifically disabled external access. I have also disabled the default relay/directory server behaviour of submitting its own descriptor to the authorities. So I don't actually know if it would submit a descriptor if I enabled that option. However, the man page says that either one of a directory or a router port is sufficient for a server to submit its descriptor to the consensus. I also don't know if clients would connect to a directory server that didn't have an ORPort. Do clients select directory guards based on flags that it's impossible for a directory-only Tor instance to obtain? What about HSDirs? Nick, which of these things did you mean by "support"? Does the consensus include directory-only Tor servers? Do tor clients connect to directory-only Tor servers? Will a directory-only Tor server ever get the flags needed to become a "directory guard"? Will a directory-only Tor server ever get the flags needed to become a HSDir? (I think we agree that a directory-only server is a far less useful configuration of an instance than a router would be.) Tim

1 0

Proposal: All Relays are Directory Servers
by Matthew Finkel 19 Aug '14

19 Aug '14

Hi All, Below is the proposal for #12538 [0], with some changes after George's review and some other revisions. Feedback welcome! Thanks, Matt [0] https://trac.torproject.org/projects/tor/ticket/12538 ----------------------------------------------------------------------- Filename: xxx-directory-servers-for-all.txt Title: All relays are directory servers Author: Matthew Finkel Created: 29-Jul-2014 Status: Target: 0.2.6.x Overview: This proposal aims at removing part of the distinction between the relay and the directory server. Currently operators have the options of being one of: a relay, a directory server, or both. With the acceptance of this proposal the options will be simplified to being either only a directory server or a combined relay and directory server. All relays will serve directory requests. Motivation: Fetching directory documents and descriptors is sometimes a non-trivial operation for clients. If they do not have a consensus then they must contact a directory authority (until directory sources are added or clients are able to use a fallback consensus). If they have a consensus and have at least one entry guard then the client can query that guard for documents. If the document isn't available then after a period of time the client will attempt to retry downloading it. If the entry guard isn't a directory server, as well, a directory server and/or directory guard must be chosen (based on the server having an open DirPort) and queried for the document. At a minimum, this has a potential performance impact, at worst it's another attack vector that allows for profiling clients and partitioning users. With the orthogonally proposed move to clients using a single guard, the potential performance bottleneck and ability to profile users could be exacerbated. If the client selects an entry guard and it is not a directory server then the client may select a distinct directory guard which will leak client behavior to a second node. In the case where the client does not use guards, it is important to have the largest possible amount of diversity in the set of directory servers. In a network where every relay is a directory server, the profiling and partitioning attack vector is reduced to the guard (for clients who use them), which is already in a privileged position for this. In addition, with the increased set size relay descriptors and documents are more readily available and it diversifies the providers. Design: The changes needed to achieve this should be simple. Currently all relays download and cache the majority of relay documents in any case, so the slight increased memory usage from downloading all of them should have minimal consequences. There will be necessary logical changes in the client, router, and directory code. Currently directory servers are defined as such if they advertise having an open directory port. We can no longer assume this is true. To this end, we will introduce a new server descriptor line. "tunnelled-dir-server" NL The presence of this line indicates that the relay accepts tunnelled directory requests. For a relay that implements this proposal, this line MUST be added to its descriptor if it does not advertise a directory port, and MAY be added if it also advertises an open directory port. In addition to this, relays will now download and cache all descriptors and documents listed in the consensus, regardless of whether they are deemed useful or usable, exactly like the current directory servers. All relays will also accept directory requests when they are tunnelled over a connection established with a BEGIN_DIR cell, the same way these connections are already accepted by bridges and directory servers with an open DirPort. Directory Authorities will now assign the V2Dir flag to a server if it supports a version of the directory protocol which is useful to clients and it has at least an open directory port or it has an open and reachable OR port and advertises "tunnelled-dir-server" in its server descriptor. Clients choose a directory by using the current criteria with the additional criterion that a server only needs the V2Dir status flag instead of requiring an open DirPort. When the client chooses which directory server it will query, it checks if the server has an open directory port and uses begindir if it does not have one. Directory servers should not be able to determine which version of Tor the client is using (or a lower-bound on the version), if possible. Continuing to prefer direct directory connections over begin may help mitigate a potential partitioning attack. Security Considerations and Implications: Currently all directory servers are explicitly configured. This is necessary because they must have a configured and reachable external port. However, this is a restriction and results in a reduced number of directory servers on the network. As a result, this could allow an adversary to control a significant fraction of the servers. By increasing the number of directory servers on the network the likelihood of selecting one that is malicious is reduced. Also, with this proposal, it will be more likely that a client's entry guard is also a directory server (as alluded to in Proposal 207). However, the reduced anonymity set caused when the guard does not have, or is unwilling to distribute, a specific document still exists. With the increased diversity in the available servers, the impact of this should be reduced. Another question that may need further consideration is whether we trust bad directories to be good guards and exits. Specification: The version 3 directory protocol specification does not currently document the use of directory guards. This spec should be updated to mention the preferred use of directory guards during directory requests. In addition, the new criteria for assigning the V2Dir flag should be documented. Impact on local resources: Should relays attempt to download documents from another mirror before asking an authority? All relays will now prefer contacting the authorities first, but this will not scale well and will partition users from relays. If all relays become directory servers, they will choose to download all documents, regardless of whether they are useful, in case another client does want them. This will have very little impact on the "typical" relay, however on memory constrained relays (BeagleBone, Raspberry Pi, and similar), every megabyte allocated to directory documents is not available for new circuits. Should we add a config option that allows operators to disable being a directory server? Is it more worthwhile for them to serve these documents or to relay cells? Future Considerations: Should the DirPort be deprecated at some point in the future?

2 2