- tor-dev - lists.torproject.org

Fwd: Orbot v15.1.0-RC-4
by Nathan Freitas 26 Jan '16

26 Jan '16

Orbot update with new built-in bridges (currently using the TBB default list, randomly shuffled!) and some other small fixes for the user interface, reproducible builds, and VPN feature. ----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15.1.0-RC-4 Date: Mon, 25 Jan 2016 22:48:01 -0500 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Fixes based on feedback from our RC-2 release.... this will be up on Play and F-Droid shortly, and from the link below right now. /** 15.1.0-RC-4 / 25-January-2016 / 80491ea95bd62346bf3f3a579d3302dbd84f4ca9 **/ APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-4.apk SIG: https://guardianproject.info/releases/Orbot-v15.1.0-RC-4.apk.asc Improve Bridge selection to support built-in default bridges * c235e3e tweak the string about bridges a little bit * 2a72814 choose up to 2 bridges from default list randomly * 1dbe5ea make bridge allocation shuffle randomly to distribute load inspired by this work: https://trac.torproject.org/projects/tor/tic * cf1a644 add support for loading default bridges from asset file VPN mode now uses Google's DNS (tunneled through Tor) as default * 9af00fe change VPN mode DNS to use Google's 8.8.8.8 Other UI fixes * ba83559 this should be kbps in fact * ab8709d add orfox icon to replace orweb * 6eb0a93 improvements to Locale changing in app * 0669add re-add appcompat, update to latest, move to Android 23 to build - this is required for latest appcompat, and to address the bu * c05d8e7 remove appcompat, and just support support-v4 Fix our stpcpy implementation to ensure no buffer overruns * 4913b0c better implementation of stpcpy for pre-Android 21 NDK Make the build process better and more reproduceable * 735b298 make-release-build: remove faketime from `ant release` * 461e35d make-release-build: freeze time when running ndk-build * 5c86b5c make-release-build: make sure ndk-build can be found * 58d53ea make-release-build: use strip-nondeterminism to get reproducible build * 5ce1f5f make-release-build: make sure tag signers exist before verifying tags * 72eab39 build jtorctl directly, using a symlink to point to its source code * a6ac016 use symlinks to provide alternate folders for Hebrew and Indonesian * 5fb4e9b update ndk-builds to NDK 4.8 toolchain - -- Nathan of Guardian nathan(a)guardianproject.info - -- Nathan of Guardian nathan(a)guardianproject.info -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.3.4 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJWpuxcCRCoARg+abN6qQAABa8P/2AlGCzBOBWhb4rVTvfE 64af8Pw031oJyyFDvtlUeETS1Ct95Zz7prP41ywhItPi/6eLCTwkbcbDA+Zl xDK6eSy6NhyMgh2qrC3US45HvQGjSCA7496IM5T3lL71wEL71sxAIaPh2abP 1akDEiXiJTnRUqFGui0aQkt0rJKQ0GShqJXmDM6qvuMCoiJSJ/ehc6Rnkyam 3/m4j5+IZ5JNpPKPDFjmW5cNFSDr+11SSdWlzjC9QfE8Ebo0rceMgpFASqH+ alzl6dB7y2rA+QeQcFQfwTlckKELq/cNofruV4UYmEIIlt/3dPZkIoIPlxBT i/ozTkmSPyEUurnxmAJQMVhergN/0WzGOWST5ceLABjjuVsoVrCZ7ai4eKiX M2zHxPQdjeLnc1HG5IXYLQcABJ9j9ol84oIH4VfcMPBCSjb205S42ChBx8Tm 9LGSSkn1i7JmVR2BaXaxmhbgoU5X+abumy3fH2uwDS5WCMDAExVw43sb8qM9 pGbDxK/wYd4aBaYZQK9VO7nA48eiv7yIw7uoKOhA7JFOnLg8he0DcngikCIx VNEqaO231Kgj1kN8Uc8+ombelRxb++997gnWfqE2ZHsEt3BpRpSAephJMJyq pxOeW/0tQL860oObACLjIp9xZ5FecZPWB4QqDEBRdOtT4MsgjDRP/Wty8Rzt UF2G =9Fk9 -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Release: obfs4proxy-0.0.6
by Nathan Freitas 26 Jan '16

26 Jan '16

On Mon, Jan 25, 2016, at 09:38 AM, Yawning Angel wrote: > benefit is that it is a lot easier to package than meek-client + the > external helper, and this can probably save binary size on things > like Android. Yes, I've been waiting for this. It is especially useful since we will be including both ARM and x86 builds shortly, so the size of PT storage in the app is already going to double. Thanks for the continued hard work on this. +n

1 0

Release: obfs4proxy-0.0.6
by Yawning Angel 26 Jan '16

26 Jan '16

Hello all, I just tagged obfs4proxy-0.0.6. There aren't many significant changes, and the internal changes primarily affect the client side initialization, so those of you that are perfectly content with obfs4proxy-0.0.5 can continue to use the existing version without issue. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6… Changes in version 0.0.6 - 2016-01-25: - Delay transport factory initialization till after logging has been initialized. - Add a meek client implementation (WARNING: Does not support using a helper to normalize TLS signatures). The brave people that want to use it can do so as the "meek_lite" transport, with identical bridge lines to the real meek-client. This means "It's blatantly obvious that you're using a HTTPS client written in Go because the ClientHello is rather distinctive". The benefit is that it is a lot easier to package than meek-client + the external helper, and this can probably save binary size on things like Android. An example bridge line would be: Bridge meek_lite 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com It has received moderate testing when I was on a business trip, and appears to function as intended, given the design constraints. There are minor internal API changes (which caused issues delaying the release) motivated by "meek's behavior is unlike most other transports" but I expect such things to be straight forward to those that actually hack on the code. Thanks to the person on Github for filing a pull request which saved me time debugging. Regards, -- Yawning Angel

1 0

Moving prop#250 discussion meeting to Tuesday, 1600 UTC
by Nick Mathewson 25 Jan '16

25 Jan '16

As mentioned on the other thread, George and David (who wrote proposal 250) can't make it at the originally planned time. So instead, we'll be discussing proposal 250 at 11 am eastern (1600 UTC) on Tuesday! (I'll still be around at the planned time to talk about patches and code and whatever.) cheers, -- Nick

1 0

New Shadow versions now available
by Rob Jansen 25 Jan '16

25 Jan '16

Hello, Shadow versions 1.11.0 and 1.11.1 are now released! https://github.com/shadow/shadow/releases/tag/v1.11.0 https://github.com/shadow/shadow/releases/tag/v1.11.1 These versions represent a huge engineering effort to provide transparent support for plug-ins that use pthreads and that make blocking IO or system calls. We are using a fork of GNU portable threads (http://www.gnu.org/software/pth/) to enable this thread and blocking support. Shadow now literally just calls `tor_main()` and handles the rest internally. More details can be found in the release notes here: http://mailman.cs.umn.edu/archives/shadow-support/2016-January/000475.html All the best, Rob

1 0

Proposal 251 (netflow padding) meeting logs, minutes, and action items
by Mike Perry 23 Jan '16

23 Jan '16

We had our meeting about the netflow padding defense proposal and implementation today: https://gitweb.torproject.org/torspec.git/tree/proposals/251-netflow-paddin… Here's the IRC logs: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-22-16.00.log.html The minutes+action item summary is as follows: - Write a torspec branch to describe the defense and changes since the proposal. The protocol changes will go in tor-spec.txt, and the behavior/usage will go in padding-spec.txt. Right now, I do not plan to also update Prop#251 itself, as the spec will be canonical. - In padding-spec.txt, we need to describe the options for disabling padding, reducing padding, and connection lifespan controls as these have changed since Prop#251 was written. - We are not going to use channel padding to obscure circuit setup (https://trac.torproject.org/projects/tor/ticket/17591) as fingerprinting is more of a risk from the guard node rather than someone watching TLS. It is better handled through multi-hop padding. That ticket needs to be closed or replaced with one to write a separate proposal for multi-hop padding. - We discussed overhead bounds and if we believe there are adversaries that exist that this will protect against (who won't/aren't doing full take for example). We believe data retention regulation and ISP practices strongly indicates that there are. - Bridges will be padded like clients are. - We discussed using behavioral checks to differentiate clients from relays instead of the consensus checks. I do not like this option, as it introduces protocol side effects that seem sloppy and prone to cause problems in the future (like CREATE_FAST did). I am not sure if we came to an agreement here. - We need to be sure to describe the protocol negotiation and forward compatibility properties of the padding negotiation in detail in tor-spec.txt. After the meeting, Nick and I discussed some implementation details. We need to improve the callback handling and maybe also upgrade libevent's timer algorithm. Nick is working on a new data structure to look up channels in O(1), so we can fix a callback channel dropping bug he spotted in code review, and eliminate the need to reach into channeltls_t from channelpadding.c. Nick also has code review comments in https://trac.torproject.org/projects/tor/ticket/16861#comment:39 that I have mostly fixed, minus the callback issue. I will be posting a reply and a new branch later today. I think that's it. Please reply with questions, comments, or additions, or if I missed anything. -- Mike Perry

1 0

Entry/Exit node selection
by Evan d'Entremont 22 Jan '16

22 Jan '16

What threat is Tor trying to defeat? Region locking or nation states? If the former, then great, select an exit country, or just use a VPN. If the latter, perhaps that actual threat profile should be taken into account. Is there any reason why Tor doesn't select exit nodes which are as close as possible to the intended host? If I connect to Tor and request a resource from a server on ISP A, would in not make sense to enforce an exit node also on ISP A, or if not, as close as possible? As well, entry guards should be as close as possible to the user, limiting the ability of others to log the connection. In short, it's safer that only my ISP see a connection rather than my ISP, a backbone provider, the entry guard's ISP, etc. Systems like XKeyscore wouldn't even see the traffic in this case. It seems that selecting an exit country may actually be detrimental to anonymity by forcing traffic over the (monitored) internet backbone. Evan d'Entremont

4 6

SyslogIdentityTag considered to be backported to 0.2.7?
by nusenu 22 Jan '16

22 Jan '16

Hi, I like weasel's [1] SyslogIdentityTag feature that is available in debian 0.2.7 packages only. The ticket [1] suggests that it will be included in tor 0.2.8.x (milestone). Would you consider to backport it to 0.2.7 as well so other platforms can make use of it before we see tor 0.2.8 (without having to ask every package maintainer to maybe ship packages with the patch applied)? thanks! [1] https://trac.torproject.org/projects/tor/ticket/17194 https://gitweb.torproject.org/debian/tor.git/tree/debian/patches/20-upstrea…

2 1

Is it possible to specify voluntary delays in my Tor client?
by Virgil Griffith 20 Jan '16

20 Jan '16

I.e., if I want the extra resistance to traffic analysis that higher latency connections provide, is there a way to specify that in my Tor config? -V

5 6

Notes from 1st Tor proposal reading group [prop241, prop247, prop259]
by George Kadianakis 20 Jan '16

20 Jan '16

Today was the first Tor proposal reading group [0] and we discussed the following guard proposals: Prop#241: Resisting guard-turnover attacks [DRAFT] Prop#259: New Guard Selection Behaviour [DRAFT] Prop#247: Defending Against Guard Discovery Attacks using Vanguards [DRAFT] In this mail, I will assume that the reader is familiar with the concepts behind those proposals. We started by discussing prop241 and prop259. These proposals specify how Tor should pick and use entry guards. - We decided that we should merge the remaining ideas of prop241 into prop259. - prop259: The original guardset should also include 80/443 bridges (shouldn't have disjoint utopic/dystopic guard sets). We should specify a behavior on how the fascist firewall heuristic should work. - prop259: Should probably not impose a specific data structure to the implementor except if strictly required. Instead maybe state the properties that such a data structure needs. Maybe we can put the hashring idea in the appendix? - We can simulate the various algorithms we are examining to test their behavior and correctness. Nick and Isis have already written some guard switching code to be simulated: https://github.com/isislovecruft/guardsim.git However, no simulations happen right now. We should code some simulation scenarios and check that the algorithm works as intended in all possible edge cases: https://github.com/isislovecruft/guardsim/blob/master/doc/stuff-to-test.txt We then moved to discussing prop247. Proposal 247 specifies how entry guards should be used by hidden services to avoid various attacks: - We can think of prop241 as the proposal specifying how entry guards work on Tor. It specifies how Tor selects its set of guards and also how it picks and switches between them. Then prop247 could be stacked on top of prop241 specifying how entry guards are used specifically in _hidden services_ and describing how the guardsets from prop241 can be used in the hidden services setting. To achieve this design we should figure out what we need from Tor guardsets to achieve all the needs of prop247, and then we should design the interface of guardsets appropriately in prop241. A stupid Guardset interface that prop247 could use could be: guardset_layer_1 = Guardset(nodes_to_consider, n_guards=1, rotation_period_max, flags, exclude_nodes) guardset_layer_2 = Guardset(nodes_to_consider, n_guards=4, rotation_period_max, flags, exclude_nodes=guardset_layer_1) - We discussed how the HS path selection should happen in prop247. Should layer-2 and layer-3 vanguards be picked from the set of Guard nodes, or should they be middle relays? This is important to figure out both for security and performance! Also, it's clear that layer-2 vanguards should not be the same node as the layer-1 guard. But what about layer-3 vanguards? Can they be the same node as the layer-1 guard? If not, then an attacker learns information about the layer-1 guard by keeping track of the list of layer-3 vanguards by monitoring many layer-3 rotations. Also, should layer-3 guardsets share nodes between them or should they be disjoint? We should be very careful about what kind of relays we allow in each position since it's clear that it has security implications. We should edit the proposal and specify this further. - We should test our design here with a txtorcon test client, and get some assurance about the performance and correctness of the system. Also, we need to see how CBT interacts with it. If you want to help with any of the above, show up for the little-t-tor meeting tomorrow. --- [0]: https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html

4 3