- tor-dev - lists.torproject.org

Update on Guardian Project Pluggable Transport work
by Hans-Christoph Steiner 13 Dec '18

13 Dec '18

The Guardian Project "PLUTO" project is our name for the work we're doing around Pluggable Transports. If you want to follow this work more closely, you can ask n8fr8 to add you to our semi-private PLUTO mailing list. n8fr8 is currently working on integrating PTs into Android apps in a reusable way. That work is mostly in https://github.com/guardianproject/AndroidPluggableTransports I recently did some work to port snowflake to Android. That should be useable now, but with some open issues about repeatable builds and verification that non-free libs are not linked in. That's mostly here: https://github.com/keroserene/snowflake/pull/43 Then we're doing full stack prototypes for using PTs in Android apps, based on Wikipedia, F-Droid and an RFA app. That stuff is scattered around. >From that work, uniqx (Michael Poehn) has produced a PT bridge server setup automation: https://gitlab.com/uniqx/pt-socks5-over-obfs4proxy uniqx and I are now focused on Encrypted SNI for use as a PT, so there will be some server automation around that, e.g. custom openssl/mod_ssl build included. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

1 0

prob_distr.c: LogLogistic fails stochastic tests on 32-bits mingw
by George Kadianakis 13 Dec '18

13 Dec '18

Hello Riastradh, as discussed on IRC, Appveyor recently started failing the stochastic tests of LogLogistic on 32-bit builds: https://github.com/torproject/tor/pull/576 https://ci.appveyor.com/project/torproject/tor/builds/20897462 I managed to reproduce the breakage by cross-compiling Tor and running the tests with wine, using this script of ahf: https://github.com/ahf/tor-win32/ Here are my findings: The following two test cases are breaking 100% reproducibly: ok = test_stochastic_log_logistic_impl(M_E, 1e-1); ok = test_stochastic_log_logistic_impl(exp(-10), 1e-2); The breakage seems to be because of the beta parameter. In particular, it seems like the test will break with any beta <= 0.26, and will succeed with a beta >= 0.27. The space in between is still unclear ;) I haven't managed to figure out what's actually offending the test but I can reproduce this so I can do some digging if you have any ideas. FWIW, I haven't noticed any other stochastic test breakage. Cheers!

2 3

Regarding projects and a begineer guide.
by Durgesh Kumar 10 Dec '18

10 Dec '18

Dear sir/mam I am durgesh kumar from ABES engineering college,ghaziabad,uttar pradesh,india. I am currently in 2nd year of my graduation(Btech CSE ) I want to contribute in some of your prestigious project. So i request you to please provide me some of your top priority project and a begineer guide. I hope you will concern my request.

2 1

Network team meeting on Tuesday at 2300 UTC
by teor 10 Dec '18

10 Dec '18

Hi everyone, This week's network team meeting is on Tuesday at 2300 UTC. (If this time doesn't work for you, we'll see you the week after.) Our meetings are held on #tor-meeting on OFTC. We'll be back to our regular schedule next week, but we'll meet an hour earlier due to daylight saving time. First meeting each month: Tuesday at 2300 UTC. Other meetings each month: Mondays at 1700 UTC. T -- teor ----------------------------------------------------------------------

1 3

Failure to connect to a 0.3.4.9 bridge--downgrading to 0.2.9.17 fixes it
by David Fifield 08 Dec '18

08 Dec '18

Here, a user reported a failure to connect to their own bridge, stopping at 25% bootstrapped. teor and I went through the basic troubleshooting steps of checking the bridge syntax, system time, and firewall settings. With or without obfs4 didn't make a difference. The user eventually tried downgrading the bridge from 0.3.4.9 to 0.2.9.17--and that fixed it. Their client version was 0.3.4.9. https://bugs.torproject.org/28717#comment:18 They also tried with two bridges from BridgeDB. The one running 0.3.4.9 didn't work, and the one running 0.2.9.17 did. A possible lead are these client log messages: [info] handle_response_fetch_desc(): Received server info (body size 0) from server 'X.X.X.X:YYYY' [info] handle_response_fetch_desc(): Received http status code 404 ("Servers unavailable") from server 'X.X.X.X:YYYY' while fetching "/tor/server/authority.z". I'll try again soon.

1 1

Re: [tor-dev] Easy(?) adaptation of meek-client for ESNI
by Hans-Christoph Steiner 07 Dec '18

07 Dec '18

Nathan of Guardian: > On Mon, Sep 24, 2018 at 08:23:58PM -0600, David Fifield wrote: >> What we would need in order for meek to used encrypted SNI would be >> either: >> 1) support for encrypted SNI in Go's crypto/tls package; or >> 2) support for encrypted SNI in the Firefox that ships with Tor >> Browser, which meek-client could use through its TLS camouflage >> helper support. >> >> IMO (2) is less desirable because I'd like to get rid of the TLS >> camouflage helper support and replace it with a Go-level TLS camouflage >> library: https://github.com/refraction-networking/utls. The TLS helper >> works, but its complexity is a pain to deal with and leads to problems >> like https://bugs.torproject.org/12774 https://bugs.torproject.org/25405. > > I wrote an untested overview of how to adapt meek to use ESNI, using an > external copy of Firefox Nightly rather than Tor Browser's built-in copy > of Firefox. Testing this out to see if it works would be a good task for > someone who wants to get involved with pluggable transports. > > Use ESNI via Firefox HTTPS helper > https://bugs.torproject.org/28168 > > 1. Download Tor Browser and Firefox Nightly. > 2. Go to about:config in Firefox nightly and set > network.trr.mode=3 > network.trr.uri=https://1.1.1.1/dns-query > network.security.esni.enabled=true > 3. Copy the meek-http-helper(a)bamsoftware.com.xpi from Tor Browser to > Firefox Nightly. > 4. Hack meek-client-torbrowser/{mac,linux,windows}.go to point > firefoxPath at the copy of Firefox Nightly and disable the custom > profile. (Additional hacks to remove hardcoded Tor Browser > assumptions may be required.) > 5. Set up a Cloudflare instance pointing to https://meek.bamsoftware.com/, > call it https://meek.example.com/. > 6. Set up a custom bridge in Tor Browser, using url= without front= > (because we're no longer domain fronting). > bridge meek 0.0.2.0:3 url=https://meek.example.com/ > > The only slightly weird part I foresee is hacking > meek-client-torbrowser; it has some internal hardcoded paths and > profiles that are specific to the Tor Browser directory layout, and > you'll have to point those to an external Firefox Nightly. Of course, > once ESNI support makes its way into Tor Browser itself, there won't be > a need for another external copy of Firefox. Two things to follow up on this thread: 1) I believe ESNI support is now in the Firefox betas, so that approach is looking like an option 2) Guardian Project got a grant to work on a full stack prototype of using Pluggable Transports. We're going to try to do it with ESNI using Stephen Farrell's patches to openssl. My last thought on this topic for today: we should be careful about making it too easy to use ESNI for circumvention before its gained any server side implementers. If it gets branded a activist tool, I could see many orgs failing to adopt ESNI. I think Cloudflare is the only active provider offering it. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

1 0

Scheduled changes to Tor Metrics CSV files in the Performance and the Traffic category
by Karsten Loesing 06 Dec '18

06 Dec '18

Hi, if you're not pulling CSV files from the Tor Metrics website in an automated fashion, you can stop reading now. We just scheduled some changes to the Tor Metrics CSV files in the Performance and the Traffic category: - December 20, 2018 (scheduled): Remove source parameters and output rows with aggregates over all sources from Time to download files over Tor, Timeouts and failures of downloading files over Tor, Circuit build times, Circuit round-trip latencies graphs. - December 20, 2018 (scheduled): Remove two graphs Total relay bandwidth and Consumed bandwidth by Exit/Guard flag combination, and update the data format of the Advertised and consumed bandwidth by relay flag graph to cover all data previously contained in the first two graphs. For more details, see: https://metrics.torproject.org/stats.html I'm posting this note here, because some folks might pull these CSV files automatically, and they should have at least a two-weeks warning to update their scripts. All the best, Karsten

2 1

Throughput of each circuit
by marziyeh latifi 05 Dec '18

05 Dec '18

Hello, I want to count the number of cells that are sent from circuit queue to the output buffer in each relay. How can I do this? Any opinion? thanks, marziyeh

2 1

Dealing with frequent suspends on Android
by Michael Rogers 04 Dec '18

04 Dec '18

Hi all, It's great to see that some children of #25500 have already been released in the 0.3.4 series. Can I ask about the longer-term plan for this work, and whether #23289 (or something similar) is part of it? The context for my question is that we're trying to reduce Briar's power consumption. Until now we've held a wake lock to keep the CPU awake all the time, but normally an Android device would go into "deep sleep" (which corresponds to suspend on other platforms) whenever the screen's turned off, apart from brief wakeups for alarms and incoming network traffic. Holding a permanent wake lock has a big impact on battery life. Most of our background work can be handled with alarms, but we still need to hold a wake lock whenever Tor's running because libevent timers don't fire when the CPU's asleep, and Tor gets a nasty surprise when it wakes up and all its timers are late. It looks like most of the work has been moved off the one-second periodic timer, which is great, but I assume that work's now being scheduled by other means and still needs to be done punctually, which we can't currently guarantee on Android without a wake lock. As far as I can tell, getting rid of the wake lock requires one of the following: 1. Tor becomes extremely tolerant of unannounced CPU sleeps. I don't know enough about Tor's software architecture to know how feasible this is, but my starting assumption would be that adapting a network-oriented codebase that's been written for a world where time passes at a steady rate and timers fire punctually, to a world where time passes in fits and starts and timers fire eventually, would be a nightmare. 2. Tor tolerates unannounced CPU sleeps within some limits. This is similar to the previous scenario, except the controller sets a regular alarm to ensure the CPU never sleeps for too long, and libevent ensures that when the CPU wakes up, any overdue timers fire immediately (maybe this happens already?). Again, I'd assume that adapting Tor to this environment would be a huge task, but at least there'd be limits on the insanity. One of the difficulties with this option is that under some conditions, the controller can only schedule one alarm every 15 minutes. Traffic from the guard would also wake the CPU, so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android. 3. Tor knows when it next needs to wake up, and relies on the controller to wake it. This requires a way for the controller to query Tor, and Tor to query libevent, for the next timer that needs to fire (perhaps from some subset of timers that must fire punctually even if the CPU's asleep). Libevent doesn't need to detect overdue timers by itself, but it needs to provide a hook for re-checking whether timers are overdue. The delay until the next timer needs to be at least a few seconds long, at least some of the time, for sleeping to be worthwhile. And finally, even if all those conditions are met, we run up against the 15-minute limit on alarms again. None of these options are good. I'm not even sure if the first and third are feasible. But I don't know enough about Tor or libevent to be sure. If you do, I'd be really grateful for your help in understanding the constraints here. Cheers, Michael

6 13

Merging Tor Bug #27490
by Neel Chauhan 29 Nov '18

29 Nov '18

Hi, I noticed that while you all have accepted bug #27490 (When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at random), it has not been merged. Is there anything I can do to speed up the process since I also have code ready for #27491 and #27492 but am awaiting the merger of #27490 before I submit them? I am also currently working on Bug #27647. Thank You, Neel Chauhan

2 1