- tor-dev - lists.torproject.org

Upcoming Tor change with application impact: "Dormant Mode"
by Nick Mathewson 04 Jan '19

04 Jan '19

Hello! This email is about a new feature that has some implications here for applications that use Tor. I want to make sure we've thought about and prepared for those implications, since we still have time to tweak this feature. == Overview In 0.4.0.x, Tor will begin supporting a new "dormant" mode in which it does not initiate network activity, and tries to avoid CPU wakeups. This mode is intended to help mobile devices sleep, and to minimize the impact of unused Tor clients on the network, and on the devices that run them. For the implementation history, see: https://trac.torproject.org/projects/tor/ticket/28335 and https://trac.torproject.org/projects/tor/ticket/28624 By default, Tor will become dormant if it is a pure client (not a relay, not an onion service[*]), and if it has received not client activity for 24 hours. (You can change the interval with DormantClientTimeout.) Unlike "DisableNetwork 1", Tor in dormant mode will not close any listener ports, and will become active again as soon as it receives a client connection. But like a "DisableNetwork 1" Tor, a dormant Tor will not build predicted circuits, and will not download directory information -- and therefore, will not bootstrap. Controllers can make Tor become dormant or non-dormant by sending the commands "SIGNAL DORMANT" and "SIGNAL ACTIVE" respectively -- these are now documented in control-spec.txt. Dormant state is persistent: if Tor has been idle for 20 hours, and you stop tor and start it again, and idle for 4 more hours, Tor will become dormant. If you stop tor and start it again, Tor will start in dormant mode. == Documentation Here's the documentation we have so far -- please let me know if you have ideas for clarification: DormantClientTimeout N minutes|hours|days|weeks If Tor spends this much time without any client activity, enter a dormant state where automatic circuits are not built, and directory information is not fetched. Does not affect servers or onion services. Must be at least 10 minutes. (Default: 24 hours) DormantTimeoutDisabledByIdleStreams 0|1 If true, then any open client stream (even one not reading or writing) counts as client activity for the purpose of DormantClientTimeout. If false, then only network activity counts. (Default: 1) DormantOnFirstStartup 0|1 If true, then the first time Tor starts up with a fresh DataDirectory, it starts in dormant mode, and takes no actions until the user has made a request. (This mode is recommended if installing a Tor client for a user who might not actually use it.) If false, Tor bootstraps the first time it is started, whether it sees a user request or not. After the first time Tor starts, it begins in dormant mode if it was dormant before, and not otherwise. (Default: 0) == Compatibility issues I see two issues here: one minor, and one major. Minor issue: some applications periodically make requests to the tor network on their own -- for example, Tor Browser's update requests. These requests prevent Tor from becoming dormant. If this is undesired, we can add some way around this. Major issue: some applications expect that Tor will always bootstrap when it starts, and delay presenting their own UI until Tor is ready. But if Tor starts as dormant, then it will not bootstrap until it receives a request from the client or a "SIGNAL ACTIVE" command from the controller. This could lead to breakage as the application waits for Tor to tell it that it's ready, and Tor waits for somebody to tell it that it's needed. Are all application developers okay with the issues above, and okay with working around them? If not, we may need changes in Tor before 0.4.0.x is released. Let's talk! [*] I'd like to add support for dormant onion services, but that's harder. See https://trac.torproject.org/projects/tor/ticket/28424 . peace, -- Nick

7 10

Queries regarding Summer of Privacy 2019
by Pranav Vardia 04 Jan '19

04 Jan '19

Hi, I am Pranav Vardia , third year student from International Institute of Information Technology, Bangalore. I am writing this mail to clarify few of my queries regarding Summer of Privacy. Firstly, I would like to ask that is there a list of projects whcih we can work on or do we need to come up with our own proposal ? Secondly, I cannot find any timeline and project lists for previous years Summer of Privacy. It would be great if you could provide me links to the aforementioned. Regards, Pranav Vardia

2 1

HTTPS and Tor Onion v3 Services
by Nathaniel Suchy 28 Dec '18

28 Dec '18

Hi everyone, So I have an idea which may or may not be a possibility. Currently Tor Onion Services do not need HTTPS since they are already end to end encrypted. That said multiple layers of crypto cannot hurt, Facebook for example uses this approach. So I have the idea of some sort of mechanism that lets you sign a self-signed tls certificate with your Onion Service's hs_ed25519_secret_key and Tor Browser trusting the tls certificate based on this signature. Would this approach work? Would it be worth the effort? Look forward to hearing your thoughts :) Cordially, Nathaniel Suchy

3 3

Re: [tor-dev] Regarding projects and a begineer guide.
by teor 21 Dec '18

21 Dec '18

Hi, Here's the torsocks README: https://gitweb.torproject.org/torsocks.git/tree/README.md You could start by building and installing torsocks: https://gitweb.torproject.org/torsocks.git/tree/INSTALL T -- teor ---------------------------------------------------------------------- > On 16 Dec 2018, at 01:26, Durgesh Kumar <durgesh.17bcs1179(a)abes.ac.in> wrote: > > Thanks for your reply.. > > I am intrested in TORSOCKS under usability category. > Can you please provide me a begineer guide about the project so that i can get familiar with it. > > Sorry for late reply. > > > >> On Mon 10 Dec, 2018, 6:40 AM teor, <teor(a)riseup.net> wrote: >> Hi, >> >> > On 7 Dec 2018, at 02:28, Durgesh Kumar <durgesh.17bcs1179(a)abes.ac.in> wrote: >> > >> > 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. >> >> Here's a list of our projects and some project ideas: >> https://www.torproject.org/getinvolved/volunteer.html.en#Projects >> >> Let us know which ones you're interested in. >> >> T >>

1 0

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