tor-dev

tor-dev@lists.torproject.org

3581 discussions

Anti-censorship discussion with Briar devs
by Cecylia Bocovich 28 Feb '19

28 Feb '19

Hi, I just had a really great conversation with some of the developers at Briar about the recent work they've done in integrating some pluggable transports into their messaging application. I thought I would summarize some key points from the conversation here. In particular, this information might prove useful for both the metrics and anti-censorship teams to know how other projects are using our tools and what they would like help with. This summary is organized as follows: I. How they used metrics data II. Independent reachability tests they performed III. What they did to integrate pluggable transports into Briar IV. What they want help with I. How they used metrics data One goal the Briar project had was to automatically detect where bridges are needed so they can be enabled automatically and for Briar to "work out of the box" with minimal developer overhead as they do not currently have dedicated anti-censorship funding. Here is the related ticket with a lot of useful discussion: https://code.briarproject.org/briar/briar/issues/1266 They wrote a collection of analytics scripts that use both OONI and Tor Project metrics data to determine where bridges are being blocked. Source code for the scripts: https://code.briarproject.org/briar/tor-circumvention-analytics/ Results (outdated): https://grobox.de/tor/bridges.html They rely mostly on OONI data but also use some Tor metrics to look at the ratio of bridge users in a country. Their reasoning being that while OONI shows what doesn't work, Tor metrics data shows what is currently working. Source code for Tor metrics script: https://code.briarproject.org/briar/tor-circumvention-analytics/blob/master… The ticket linked above has more discussion that might be useful to the metrics team as well. II. Independent reachability tests they performed To validate some of the results from OONI and Tor metrics, they ran a private bridge and did some reachability tests to it from China. They found that the bridge was not blocked, however they did not perform bandwidth tests to determine whether or not obfs4 bridges are being throttled. This makes sense as briar produces probably fairly low bandwidth traffic. When I asked them about it they suggested performing the following test: Set up obfs4 to forward connections to a local http server that servers a large, static file. Have a contact in China set up a cron job that periodically downloads the file from the bridge via obfs4. Their original reachability test was not running for very long, so it's still possible that prolonged use would result in its discovery but the fact that it wasn't blocked suggests that China might be enumerating bridges through the distribution mechanism rather than by something identifiable from obfs4 itself. We should perform our own tests to verify this, and to check for throttling. III. What they did to integrate pluggable transports into Briar My understanding from the issue text and commit messages about how briar decides whether to use pluggable transports is to use the output of their reachability analysis to determine user needs by country. If Tor is not blocked, users just use vanilla Tor If it is they use obfs4. If obfs4 is blocked, then they use meek (meek lite). Right now the countries that use meek in briar are: China, Iran, Egypt, Belarus, Turkey, Syria, and Venezuela. As far as the integration, they wrote some code that makes reproducible builds of obfs4 and meek and spits out a java/android library: https://code.briarproject.org/briar/go-reproducer Briar already uses Tor, so they configure these bridges in the usual way using a torrc file and a hardcoded, shipped file of bridge information (which I believe are also the default bridges used by Tor Browser). They decided they didn't want to maintain any private bridges like the one they used for their reachability tests. One of the concerns there was the ability to fingerprint Briar traffic by bridge connection and differentiate it from other Tor traffic. IV. What they want help with Because they do not have dedicated anti-censorship funding, they mentioned a few things that would help them maintain their pluggable transport use going forward and ease the integration of pluggable transports. The main thing they would like on the metrics side is up-to-date information about which PT works in which country and where PTs are needed at all in order to make quick and easy decisions based on location about which transports to use. They started to work with OONI to expand their tests but it turned out to be too much work for their time/funding: https://code.briarproject.org/briar/briar/issues/1414 It's on our roadmap to work with OONI and other censorship measurement tools (like Censored Planet) to expand our tests so we should get into contact with them again once we have gotten farther with this. On the PT development side, they expressed a desire to transfer maintenance of their reproducible builds of obfs4 and meek to someone else (that's the go-reproducer code linked above).

5 6

Speeding up your Tor Appveyor Builds
by teor 27 Feb '19

27 Feb '19

Hi, We have made some changes to speed up Tor's Appveyor builds: https://bugs.torproject.org/29601 They should be merged soon. If you have Appveyor set up on your personal tor git repository, you can change Appveyor's configuration so that it's a bit faster. (We can't make these changes in the .appveyor.yaml config.) 0. Log in to Appveyor: https://ci.appveyor.com/ I use GitHub to log in to Appveyor. 1. Go to Appveyor's project settings page. Mine is: https://ci.appveyor.com/project/teor2345/tor/settings 2. Set "Build timeout, minutes" to 30. The default timeout is 60 minutes. Tor's jobs usually take about 10 minutes, unless they hang. 3. Set the "Rolling builds" checkbox. The default is: "build all versions of a branch/pull request". Rolling builds means: "when a branch or pull request is updated, cancel the previous build, and start a build with the latest changes." That's it. Your builds will be a bit faster! T -- teor ----------------------------------------------------------------------

1 0

Sending multiple streams throuh a single Tor circuit
by Piyush Kumar Sharma 26 Feb '19

26 Feb '19

Hello all, I am a PhD student, and am working on some measurements in Tor. I am stuck at a point where i need to send multiple applications(streams) traffic through a single circuit. I am currently using torsocks/torify to send traffic of these multiple applications through Tor. The main problem is that, despite trying many different ways to achieve the same (sending multiple streams through a single circuit), i am not successful. Things i have tried : 1.) Force Tor process to create only a single circuit at a time preventing any new circuit creation, so that any new stream would be attached to this only available circuit. To acheive this i have set the following Tor options : set __DisablePredictedCircuits to 1 set MaxClientCircuitsPending to 1 set newcircuitperiod to 999999999 set maxcircuitdirtiness to 999999999 The problem with the above method is that it seems to work sometimes randomly. But most of the times for some reason, a new circuit is still created. 2.) Next, i assumed that maybe running torify multiple times for each application is the culprit, as it may try to create new circuit for each run. So i created a new bidirectional stream using socat, which listens on a local TCP port, and forwards the data to the Tor SOCKS port assuming that it will lead to a singe connection to local SOCKS. Even this did not work and still new circuits were created randomly. 3.) Next i tried to attach streams to circuits manually, using the stem library following the link : https://stem.torproject.org/tutorials/to_russia_with_love.html#custom-path-… . This seemed to work initially, but then after every 4-5 runs, the streams seemed to detach automatically. Moreover, the original circuit crashed too. It would be great, if someone could tell a simple way to achieve the same, or would point me to any mistakes that can be improved in the above methodologies to make them work. Regards Piyush

4 8

xp + T
by Gedropi 26 Feb '19

26 Feb '19

I would like to continue to get Tor updates but intend to keep Windows XP. How can I do it? Thanks

4 4

GSOC 2019 tor project participation
by ＠usernamedt 26 Feb '19

26 Feb '19

Hello everyone, Can someone confirm that tor project is participating at GSOC 2019? I am a Mathematics and Computer Science student (Russia, Ural Federal University). Privacy violation and internet censorship became serious problems for me personally and for many people in my country. I am looking forward to contribute to tor project by implementing OONI Encore style test in browser. Thanks!

2 2

Testing Network: Circuit buildup errors and missing guards
by Katharina Kohls 21 Feb '19

21 Feb '19

Hey guys, currently I am working on a private Tor setup and I repeatedly run into issues with the circuit buildup procedure (it's Tor 0.3.5.7 on linux, the setup consists of several debian jessie VMs). The setup is as follows: 1 Client, 2 V3 Authorities, 6 Relays of which 3 have the ExitRelay 1 option set. In the torrc configs of all relays I define a list of fixed exits TestingDirAuthVoteExit and fixed guards TestingDirAuthVoteGuard and I use DirAuthority to fix the two V3 authorities of my setup. All nodes bootstrap properly and reach 100%, the authorities both manage to vote and exchange information. Also the relays and the client bootstrap to 100%. Nevertheless, the consensus seems to lack relays with guard flags: Feb 12 10:35:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 2/2, and can only build 0% of likely paths. (We have 0% of guards bw, 100% of midpoint bw, and 100% of end bw (no exits in consensus, using mid) = 0% of path bw.) Because of this, no default circuits can be built in the client or the relays in all logs the following message appears every second: [warn] Failed to find node for hop #1 of our path. Discarding this circuit. Google says it might be an ntp-sync problem. The VMs are not connected to the Internet (but can talk to each other), so I made sure that all machines are in sync and use the firewall as NTP server. Sync shouldn't be the problem. In the data_dir/state file I see several guard entries: Guard in=default rsa_id=[...] nickname=auth01 sampled_on=2019-01-17T18:33:12 sampled_by=0.3.5.7 listed=1 Guard in=default rsa_id=[...] nickname=relay03 sampled_on=2019-01-22T17:17:10 sampled_by=0.3.5.7 unlisted_since=2019-01-27T11:00:36 listed=0 Guard in=default rsa_id=[...] nickname=relay02 sampled_on=2019-01-24T22:19:10 sampled_by=0.3.5.7 unlisted_since=2019-01-29T09:08:59 listed=0 Guard in=default rsa_id=[...] nickname=relay03 sampled_on=2019-02-06T21:07:36 sampled_by=0.3.5.7 listed=1 Guard in=default rsa_id=[...] nickname=relay05 sampled_on=2019-01-27T16:37:38 sampled_by=0.3.5.7 listed=1 The client also seems to receive a complete consensus, at least all fingerprints of my setup show up if I fetch the file manually. Please find below an example of the configs I use for the different nodes. Any help or hints would be great :) Thanks, Katharina # DIRECTORIES, LOGGING SafeLogging 0 ProtocolWarnings 1 DisableDebuggerAttachment 0 DataDirectory /var/lib/tor PidFile /var/lib/tor/pid Log notice file /var/lib/tor/notice.log Log info file /var/lib/tor/info.log # CONTACT ContactInfo ... # GENERAL RunAsDaemon 1 AssumeReachable 1 ConnLimit 60 MaxMemInQueues 1507 MB ShutdownWaitLength 0 HashedControlPassword ... # FIXED AUTH DirAuthority auth01 orport=5000 no-v2 v3ident=... ...:7000 B218B78864CEF4397CEE0AEF61703459EEE64E38 DirAuthority auth02 orport=5000 no-v2 v3ident=... ...:7000 431E50CDBB0B6FFDD0284A45ABEC875136D980E8 TestingDirAuthVoteExit 2B74825BE33752B21D17713F88D101F3BADC79BC,E4B1152CDF0E5FE697A3E916716FC363A2A0ACF3,7353D324677B9E7A9A50240339C2C7366B381F64 TestingDirAuthVoteGuard 911EDA6CB639AAE955517F02AA4D651E0F7F6EFD,C122CBB79DC660621E352D401AD7F781F8F6D62D,8E574F0C428D235782061F44B2D20A66E4336993 # PORTS OrPort 5000 ControlPort 9051 SocksPort 9050 # FLAGS ExitRelay 1 Nickname ... Address ...

2 5

Proposal Idea: Consensus Options
by teor 21 Feb '19

21 Feb '19

Hi all, I have a Tor proposal idea: we should make it easier for tor to get options from the consensus. At the moment, a few tor options are set from the consensus. (If they aren't already set in the torrc.) But there's no abstraction in tor's code, so they're all implemented slightly differently. We could refactor the code so these options are much easier to declare. And we could provide a graceful upgrade path from off-by-default features, to on-by-default features. 1. Tor refactoring We refactor the tor config code, so that options can be declared as consensus options. If the option is configured locally, that value is used. Otherwise, the consensus value is used. If there is no configured or consensus value, the default is used. Each entry in the option declaration table would need 3 extra values: * a flag that tells tor whether to check the consensus * a minimum permitted value from the consensus * a maximum permitted value from the consensus At the same time, we might also want to: * declare a minimum and maximum value for all options, not just the consensus options * add a log message fragment that explains the value restriction So far, this is a refactoring idea. But here's where it gets interesting… 2. Tor authority behaviour change We also want to gracefully upgrade new features, so that they are on-by-default. For privacy sensitive features, we would keep the current process: 1. Deploy the feature off-by-default, but make it a consensus option 2. Manually change the consensus parameter so the option is on-by-default 3. Change the next release of Tor so the option is on-by-default 4. When all supported Tor versions have the feature on-by-default, manually remove the consensus parameter This upgrade path allows us to make sure that almost all the network has the same behaviour. But for other features, we could upgrade faster: 1. Deploy the feature off-by-default, but make it a consensus option 2. Change the next release of Tor so the option is on-by-default 3. When the authorities upgrade to the next release, they automatically vote the consensus parameter on-by-default 4. When all supported Tor versions have the feature on-by-default, remove the flag telling authorities to write the consensus parameter from the option 5. When the authorities upgrade to the next release, they automatically stop voting for the consensus parameter This upgrade path turns the option on when a majority of authorities upgrade. We wouldn't be able to use it for options where flapping is an issue. Each option declaration would need one extra value: * a flag that tells tor authorities whether to write to the consensus If the consensus parameter is explicitly set on an authority, then it would override the default from the option declaration. I think we could implement this proposal as part of Sponsor 31, which is about refactoring tor. We have some tickets for refactoring tor's config code, and making it easier to implement optional features. If anyone wants to help me write it up, let me know! T -- teor ----------------------------------------------------------------------

2 2

Re: [tor-dev] tor-dev Digest, Vol 97, Issue 19
by Gedropi 19 Feb '19

19 Feb '19

Attn: Iain Learmonth <irl(a)torproject.org> Thank you for your thoughtful response. Perhaps this was the wrong mailing list in some ways. Backing up on Iain's email conversation, I have always built my desktop computers from scratch. Salvaged hardware and researched drivers, etc. There is nothing pre-installed. (My colleagues affectionately call me the Queen of Setup and Config.") By design. I have an OEM version of XP that I put on initially, but that is only the start. Since xp is not locked down like Windows 7 and beyond, I then reconfigure so much! You would be right in assuming that a standard xp install is a security risk. But I am constantly tracing packets, studying the traffic at the back end to see where the leaks are. Then I figure out what I can do to plug / understand the leaks. Partly therefore, xp is a learning / testing tool. I use xp for basic apps. But I would sooner drink lye than use Windows 7 and beyond. Therefore, as you already suggested, I did have a dual boot with a Parrot distribution. That is, until my sata drive died. Upon purchase, I will return to the dual boot or to two machines. So therefore, I am back to xp for the time being. Until such time as I have the dual/two machine option again, I surely would like to be able to update as much of Tor as I can. (I know that you are serving the masses and not an individual person). Anyhow, I love Tor and I love having kindred spirits that 'get' security. Thank you for what you are doing. ~Emily On Tue, Feb 19, 2019, at 12:00 PM, tor-dev-request(a)lists.torproject.org wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: xp + T (Iain Learmonth) > 2. Sending multiple streams throuh a single Tor circuit > (Piyush Kumar Sharma) > 3. Re: Sending multiple streams throuh a single Tor circuit (meejah) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 Feb 2019 14:32:11 +0000 > From: Iain Learmonth <irl(a)torproject.org> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] xp + T > Message-ID: <4b405fbe-6130-ef98-1a8d-74bcacc8bc5f(a)torproject.org> > Content-Type: text/plain; charset="utf-8" > > Hi, > > On 13/02/2019 16:56, neel(a)neelc.org wrote: > > I don't think this is the right mailing list. > > This is entirely the correct mailing list as it is discussing a > technical policy of the network team. This policy can be found here: > > https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Support… > > > You probably shouldn't be using Windows XP, otherwise the EOL'd OS would > > be a weak point in security. One option could be to dual-boot Windows XP > > and Linux/*BSD, using Linux/*BSD for Tor and browsing, and XP for > > applications that haven't been ported. > > It is worth remembering that most people do not have the privileges to > install software on the computers that they use. > > Unfortunately, the current policy of the network team is that they will > not even accept patches for Windows XP support and will merge changes > that break Windows XP support. > > I would be interested in statistics that show the current Windows XP > user base, especially in countries with users that can most benefit from > Tor. The policy has been drawn up primarily on technical considerations > but if it is shown that this has negative impacts for large numbers of > users then it may be reconsidered. > > Thanks, > Iain. > >

1 0

Marking Proposal 299 (Preferring IPv4 or IPv6 based on IP Version Failure Count) as Accepted
by neel＠neelc.org 18 Feb '19

18 Feb '19

Hi tor-dev@ mailing list, My proposal "Preferring IPv4 or IPv6 based on IP Version Failure Count" (a.k.a. Prop299) is here: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt I haven't gotten any comments for requests when I asked for them, so I am assuming this proposal is okay. If it is, could someone please mark this proposal as Accepted? If not, what does this proposal require? Thank You, Neel Chauhan === https://www.neelc.org/

2 1

Sending multiple streams through a single Tor circuit
by Piyush Kumar Sharma 16 Feb '19

16 Feb '19

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev