tor-dev

tor-dev@lists.torproject.org

3581 discussions

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

Transparent Proxy: how does it work?
by CJ 16 Sep '14

16 Sep '14

Hello dear torrorists :) I'm wanting to do some weird things with iptables in order to force some connections through Tor's TransProxy, but before that I have an interrogation on its internals: How does it detect if we're wanting to use, let's say, SMTP over Tor? Is there any kind of sniffer that tells tor "ok, so this one wants to go to mail.google.com:25, this other one to www.ethack.org:443 with SSL" ? If so, how does it work? It seems it may cause some problems when using Tor on a gateway, like some android device with tethering: forcing tethered connections through tor [orbot] seems to be really hard. Thank you in advance for your enlightenment. Cheers, C.

1 0

Why the seeming correlation between flash proxy and meek on metrics graphs?
by David Fifield 16 Sep '14

16 Sep '14

In comparing the user graphs of pluggable transports, I found that there seems to be a correlation between the graphs of flashproxy and meek. They are not equal, but they seem to go up and down at the same time. Other transports don't show such an effect as far as I can tell. What could the cause be? I am trying to rule out a measurement error. Could it be an artifact of both transports running on the same bridge? After the "How to use meek" blog post on August 15, there was a noticeable increase in the number of meek users, from about 5 to about 20 concurrent users: https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… The blog post also seems to have had a positive effect on flashproxy and scramblesuit, too. I suspect it is because the blog post also named other transports and suggested to try them first: https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… On the other hand, I don't see any noticeable rise for obfs3 and fte: https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… What's interesting is when we plot meek and flashproxy together (this is the first attached image). There seems to be a strong correspondence between the two. They both jump on August 15, as expected, but then they both jump again together on August 21. In early September they settle back down, but still mostly match each other's up/down patterns: https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… What's really intriguing is that the apparent correlation goes back in time, even before August 15. Compare the shapes of the graphs during July, for example. The correlation between meek and scramblesuit appears to be not as strong (this is the second attached image). There's a rise around August 15, but no big secondary spike, although the first part of September matches pretty well. https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… There's no obvious positive correlation between meek and fte (this is the third attached image) nor meek and obfs3 (this is the fourth attached image). https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… Why could this be? Some hypotheses: * meek and flashproxy have similar capabilities (resistance to IP blocking), so maybe the circumstances where they work are similar. If one works, so does the other, so we expect them to more or less track one another. * There is a bug in metrics collection, so that, for example, sometimes a meek connection is counted as flashproxy or vice versa. The backend bridge for both meek and flashproxy is the same; i.e., tor2.bamsoftware.com. (Before May 8, 2014, it was a different bridge, namely tor1, but both transports were still running on it together.) * After my blog post, a bunch of people just picked transports at random until they found one that worked, which was likely one of {flashproxy, meek, scramblesuit}, and now we're just seeing the aggregation of those user's daily usage. Doesn't explain a match before August 15, though. To figure this out I'm thinking of i) counting bytes transferred on the flashproxy and meek external ports, or ii) moving one to a different bridge (or different tor instance), to see if the effect remains. Do you have any other ideas? David Fifield

2 4

Debian popcon as a vulnerability?
by Griffin Boyce 15 Sep '14

15 Sep '14

Hello all! I am wondering whether to force-uninstall Debian's popularity-contest package as part of Stormy's installation process. It would be good to have an idea how popular Stormy is, but on the other hand, I'm not sure how anonymous the reporting is on Debian's end. This is also relevant for users of the tor package, who might also be at mild risk (though far less so because the number of users is so high, and doesn't reveal location of location-hidden services). Anyone have opinions on this? I'm leaning towards checking if popularity-contest is installed and then asking if the user would like it to be removed. If y'all have other recommendations, please comment here or on the ticket. Ticket: https://trac.torproject.org/projects/tor/ticket/13154 thanks! Griffin -- "I believe that usability is a security concern; systems that do not pay close attention to the human interaction factors involved risk failing to provide security by failing to attract users." ~Len Sassaman

3 2

Re: [tor-dev] Symlink to latest sources
by Peter Swire 15 Sep '14

15 Sep '14

Dear Roger, You've avoided that for both binaries and sources? That's interesting. I guess it makes sense, if it's been a problem before. I mostly would like to be able to wget the the sources and build them automatically, without having to specify a version number. Whenever I setup a new machine, I like to make it a tor relay; I don't particularly care about versions, just as long as it's new enough to not have any old vulnerabilities. Best, Peter > Hi Peter, > > So far we have avoided doing this approach, since it increases the number > of user support cases where we ask "what version?" and they say "latest" > because their file name doesn't actually tell them what version it is. > > I guess we could try adding the symlink but then never tell anybody > about it, in hopes that users will keep downloading the files that have > version numbers in their names. > > What problem are you trying to solve? > > --Roger

4 4

Tor Research Framework update
by Gareth Owen 12 Sep '14

12 Sep '14

Hi all I thought I'd give you an update on where the Tor Research Framework is now at as there's been lots of development over the last few weeks. At present, the framework is a largely fully functional tor client with code that is easy to read, follow and crucially change for custom functionality. URL: https://github.com/drgowen/tor-research-framework Completed ======= The examples exercise a big chunk of the functionality so in the examples directory, we now have examples on how to do: - Circuit building, Random circuits based on flags, etc - Building HS circuits and establishing streams to their service - Consensus parsing examples - RELAY_EARLY scanner - scans HSDirs looking for RELAY_EARLYs coming the wrong way (aka the recent Blackhat deanon attack) - Tor SOCKS Proxy and PortForwarder The examples are here: https://github.com/drgowen/tor-research-framework/tree/master/src/main/java… The RELAY_EARLY scanner took around five minutes to write for example and didn't require modifying core library code. Work in progress ========== Fuzzer: We also have another chap (twilsonb) working on a fuzzing framework for Tor that is capable of fuzzing the protocol and directory services - although this is at early stage I'm sure he'd welcome help from anyone interested. Relay: We're working on building the capability to act as a Tor relay with examples for building malicious guard nodes that deny circuits or do correlation attacks. Naturally, we'll also look later down the line at optionally integrating with the shadow simulator for research which shouldn't be done on the live network. -- If anyone is interested in helping out then please dont hesitate to get in touch. Best Gareth -- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth Tel: 02392 846423 Web: ghowen.me

3 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev