- tor-dev - lists.torproject.org

Making and distributing custom TBB with a new "home-page"
by Fabio Pietrosanti (naif) 23 Sep '14

23 Sep '14

Hi all, for a very interesting deployment of GlobaLeaks in the are of Human Rights defense, we will have the need to distribute a customized Tor Browser Bundle to the sources. The "customization" requirement is simple: Have as a default home-page the GlobaLeaks .onion site . We must go that way because: - the "target country" where the sources are cannot download TBB due to torproject.org being censored - the sources are absolutely non-technologically savy (average 60yo lawyers doing human rights defense) The website where there will be the leaking instructions and the download of such custom TBB will be "privately distributed" trough word of mouth and trusted connections, with no public solicitation. So we must do some piece of software that will: - Download TBB in specific languages (2-3 specific languages) for each platform - Unpack TBB (in all formats for Windows, OSX, Linux) - Apply the customization (set the home-page, with slightly different parameters depending on the language) - Check periodically if a new version is available and, in that case, re-execute the process described above to release updated version of TBB The questions are: a) Which is a simple/stable/resilient way to check which is the latest version of TBB b) Does someone have already done that kind of customization-process? c) Can everything be done from Linux, like a cron-job, in a fully automatic way? d) Which other customization / ideas / concern are there regarding this process? I'd personally love if the customization would enable me to completely disable the "URL Bar" and all of the Browser Button in order to make it useful only to use it as a console to send information being a source, without the possibility to go browse other sites. Waiting for comments before writing some quick specs -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org

3 4

meek on Microsoft Azure
by David Fifield 22 Sep '14

22 Sep '14

I've got meek working on Microsoft Azure, a cloud services platform and CDN. If you'd like to try it, use a 4.0-alpha bundle and enter the bridge line: Bridge meek 0.0.2.0:3 url=https://az668014.vo.msecnd.net/ front=ajax.aspnetcdn.com As usual, the IP address is ignored; I'm just assigning incrementing numbers in the port. az668014.vo.msecnd.net is a CDN domain that points to meek-reflect.azurewebsites.net, where the service is really running. The front domain ajax.aspnetcdn.com is one that hosts a bunch of common web libraries: http://www.asp.net/ajax/cdn. I didn't look very hard to see if there are other good front domains. More information on Azure: https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure David Fifield

1 0

Attack linking Tor circuits
by Otto Huhta 19 Sep '14

19 Sep '14

Dear Tor developers, We’ve been working on an MSc Thesis project looking into an attack that links different Tor circuits back to the same user, using only information available to a Tor middle node. We’ve discovered that an adversary can quite accurately determine if two consecutive circuits are used by the same user just by looking at when these circuits are built and destroyed or when they begin and stop relaying traffic. This is mainly the result of the fixed 10 minute circuit lifetime and the fact that the transition to using a new circuit is quite sharp. According to our measurements, circuits belonging to the same user are built at very close to 10 minute intervals. Also, when one circuit stops relaying traffic another one suddenly becomes active, at almost the very same moment. Thanks to these properties we could train a classifier to quite efficiently identify matching pairs of circuits (9% EER). We looked into the threat posed by this attack to Tor users and concluded that because of entry guards the threat is real, given that an adversary can control a significant portion of middle node traffic. Finding matches among all possible Tor circuits would result in too many false positives but thanks to entry guards an adversary can focus only on circuits built through these specific nodes and quite efficiently determine if two circuits belong to the same user. Possible plans of moving to using only a single guard node make the situation much more severe: we concluded that for a user picking a slow guard node, the adversary can find almost all circuits belonging to a same user (again assuming control of a large portion of middle node bandwidth). We thus see that before moving on with any such plans, one should consider the effect of our findings on the threat posed by a middle node linking user circuits. As a final note, we considered the effects of randomizing the circuit lifetime (e.g. between 5-15 minutes) to mitigate this threat but concluded that it would not necessarily solve the problem. The most prominent feature linking two circuits together seems to be the time difference between traffic ending on one circuit and beginning on another circuit, and this link cannot be broken by varying the circuit lifetime. However, if someone were to devise such a modification, we would be happy to re-run our tests to see what kind of an effect this would have on the success rate of an adversary. For those interested in our findings, the full thesis Linking Tor Circuits can be found at: http://www0.cs.ucl.ac.uk/staff/G.Danezis/students/Huhta14-UCL-Msc.pdf Best regards, Otto Huhta, UCL

2 3

Responsible disclosure
by Bram de Boer 18 Sep '14

18 Sep '14

Hi, How can I responsibly report a bug that might affect security (e.g. possibility to DoS Tor nodes)? I searched the torproject.org website, but couldn't find any pointers with respect to responsible disclosure. Do I just file a trac ticket and/or drop it in this mailinglist? Do I report it directly to some of the key players in this project (Roger, Nick, etc.)? Thanks, Bram

3 2

Reminder OONI dev meeting happening tomorrow
by Arturo Filastò 18 Sep '14

18 Sep '14

Hi Oonitarians, This is a reminder to inform you that tomorrow (Friday 19th of September) there will the weekly dev meeting. It happens on IRC (irc.oftc.net) on the channel #ooni at 17:00 CET (15:00 UTC). Everyone is invited! See you tomorrow! ~ Art.

1 0

Gitian Build Issue - Tor Browser
by SiNA Rabbani 17 Sep '14

17 Sep '14

Dear Team, I need some help getting gitian-build to work for the Tor Browser. Can anyone help with this error please? ./mkbundle-windows.sh adding: Docs/ (stored 0%) adding: Docs/ChangeLog.txt (deflated 68%) adding: Docs/Licenses/ (stored 0%) adding: Docs/Licenses/Firefox.txt (deflated 68%) adding: Docs/Licenses/HTTPS-Everywhere.txt (deflated 49%) adding: Docs/Licenses/NoScript.txt (deflated 62%) adding: Docs/Licenses/PluggableTransports/ (stored 0%) adding: Docs/Licenses/PluggableTransports/LICENSE (deflated 73%) adding: Docs/Licenses/PluggableTransports/LICENSE.CC0 (deflated 60%) adding: Docs/Licenses/PluggableTransports/LICENSE.GO (deflated 47%) adding: Docs/Licenses/PluggableTransports/LICENSE.PYTHON (deflated 78%) adding: Docs/Licenses/Tor-Launcher.txt (deflated 48%) adding: Docs/Licenses/Tor.txt (deflated 75%) adding: Docs/Licenses/Torbutton.txt (deflated 46%) adding: Data/ (stored 0%) adding: Data/Browser/ (stored 0%) adding: Data/Browser/profile.default/ (stored 0%) adding: Data/Browser/profile.default/bookmarks.html (deflated 70%) adding: Data/Browser/profile.default/preferences/ (stored 0%) adding: Data/Browser/profile.default/preferences/extension-overrides.js (deflated 68%) adding: Data/Browser/profiles.ini (deflated 21%) adding: Data/Tor/ (stored 0%) adding: Data/Tor/torrc (stored 0%) adding: Data/Tor/torrc-defaults (deflated 29%) ****** SKIPPING already built Utilities Component of Windows Bundle (1/5 for Windows) ****** ****** Starting Tor Component of Windows Bundle (2/5 for Windows) ****** --- Building tor-windows for precise i386 --- Stopping target if it is up Making a new image copy Formatting 'target-precise-i386.qcow2', fmt=qcow2 size=11811160064 backing_file='base-precise-i386.qcow2' encryption=off cluster_size=65536 Starting target Checking if target is up. Preparing build environment Updating apt-get repository (log in var/install.log) Installing additional packages (log in var/install.log) Grabbing package manifest Creating build script (var/build-script) Running build script (log in var/build.log) ./bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError) from ./bin/gbuild:122:in `build_one_configuration' from ./bin/gbuild:224 from ./bin/gbuild:219:in `each' from ./bin/gbuild:219 from ./bin/gbuild:217:in `each' from ./bin/gbuild:217 All the best, SiNA

3 3

Re: [tor-dev] Guardiness: Yet another external dirauth script
by Tim 17 Sep '14

17 Sep '14

On 17 Sep 2014, at 22:00 , George Kadianakis <desnacked(a)riseup.net> wrote: > Sebastian Hahn <sebastian(a)torproject.org> writes: > >> On 16 Sep 2014, at 16:15, George Kadianakis <desnacked(a)riseup.net> wrote: >> >>> ====How the guardiness script will be deployed==== >>> >>> The idea is that dirauths will add another script to their crontab >>> that is called every hour (before or after the bwauth scripts). >> >> Only 4/9 have such scripts, if at all - it is possible to run a >> bwauth on a different host, and scp the file over. I don't know >> if any of the dirauth ops actually do this currently. >> > > This should also be possible with the guardiness stuff, as long as you > can arrange fresh consensuses to arrive on the second host. tor supports consensus downloads without being a router, but it's a bit of a hack: A tor instance configured with a DirPort and no ORPort will act as a directory cache only. Directory caches regularly download the latest consensuses. It's worth binding the DirPort to localhost only, and marking it NoAdvertise. This hides the cache from the consensus, and disables remote requests. However, the cache will also download router descriptors unnecessarily. (Microdescriptors and extra info can be turned off, but I'm not sure if router descriptors can.) T

2 1

[RFC] Proposal draft: The move to a single guard node
by George Kadianakis 17 Sep '14

17 Sep '14

> On Mon, Apr 7, 2014 at 11:34 AM, George Kadianakis > So, based on your > response, IIUC, the idea is that because young > > guards are underutilized, we want to increase the probability of them > > being chosen in non-guard positions, so that they become more utilized > > till more people pick them as guards? > > Right. > > > Some questions on the terminology you used: > > > > a) What do you mean by 'last rotation period'? When you say "for > > fraction k of the last rotation period", you mean that if the > > authorities read consensuses for the past 12 months, and the relay R > > was up as a guard for 6 months, then k would be 6/12 == 0.5? > > The "rotation period" is the average length of time between choosing > guards. For example, with the current parameters (IIRC), clients > discard a guard and choose a new one at a time uniformly chosen > between 30 and 60 days. So the rotation period is 45 days = 45*24 > hours = 1080 consensus votes, and essentially in each of those hours, > 1/1080 of the clients choose a new guard. So the last rotation > period's worth of status documents should be the only ones that matter > for figuring out how heavily a node is used as a guard. For example, > if a relay has had the guard flag for 15 days (=360 consensus > documents) out of the last 45, then that relay has about k=360/1080 of > the number of clients using it as a guard as it would have, if it had > been a guard for the full 1080 hours. > Ah, I see. I originally misinterpreted what you meant by 'last rotation period'. > (N.B. I'm making an assumption that guard rotations will be uniformly > distributed over the period. This should be safe in equilibrium, but > might get kind of shaky when the period first increases to 9 months or > whatever the final decision is) > Yep. We also don't consider new releases of TBB/Tails (many users pick new entry guards), or sudden bulk arrival of users (botnets, real life events, etc.). > > b) By (weight with the guard flag) you mean the result of: > > <consensus BW> * <consensus weight> ? > > > > Is that right, or did I misunderstand you? > > Yes. > > > Assuming the above terminology assumptions, I began trying to > > understand your formula. First of all, I was wondering how you ended > > up with it? Is this some standard form? I'm not very familiar with > > these things. > > Well, the way the weights work is that they compute what fraction of > guard bandwidth should be used for middle and exit traffic, assuming > that the rest will be all used up by client-guard connections. That > is, the weights are telling us to use (1-(<consensus middle weight> + > <consensus exit weight>)) fraction of the guard's bandwidth for these > connections. > > But if a relay has only fraction k of its "guard bandwidth" used up > this way, then (1-k) of this bandwidth should go back into the pool > for other positions. I think that's what the formula does, but I > could have it wrong. Does that make sense? > I see. That makes sense, I think. I will ponder on this a bit more, and then edit the proposal. (I would like to think a bit more about how accurate the assumption "relay has been a guard for 0.25 of the rotation period => relay has 0.25 of its bandwidth occupied for guard purposes") Thanks!

3 6

Temporary decrease in FTE users in late August?
by David Fifield 17 Sep '14

17 Sep '14

Kevin, Do you know the reason why FTE usage dropped from 200 to about 50 at the end of August and then recovered again? https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… I had a guess that maybe it had to do with availability of new bridges. If a bunch of bridges got blocked and then new bridges were made available, that could explain it. The 4.0-alpha-2 release was on September 3, but as far as I know it didn't contain new FTE bridges. They could have been added to BridgeDB, I suppose. David Fifield

2 1

Preferred OpenSSL config for Tor?
by Steve Snyder 16 Sep '14

16 Sep '14

What are the recommended build options for OpenSSL 1.0.1x when building it for use with Tor v0.2.5.x? Put another way, what default OpenSSL features (ciphers, etc.) should be disabled and what optional features should be enabled? My goal here is to build a Tor-oriented OpenSSL, one that dispenses with features Tor doesn't need/use while enabling those that improve security and/or performance. Thanks.

2 1