- tor-dev - lists.torproject.org

Proposal xxx: Filtering malicious rendezvous points at hidden service server side
by s7r 26 Jan '16

26 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, Inspired by asn, dgoulet and Mike Perry discussing alternate path lengths for proposal 247, I wrote a proposal that could fit in nicely with proposal 247, maybe even allow us to make the 3rd hop wild (random) so we don't have to worry about HSDirs + HSDir fetch/post circuits and introduction points + introduction points circuits linking short term layer 3 guards. Please find the proposal attached as well as inline for comments. Looking forward for reviews. If I've structured it wrong or something I apologize in advance - will do better next time. Filename: xxx-malicious-rendezvous-point-filter.txt Title: Filtering malicious rendezvous points at hidden service server side Authors: s7r [ 0x837FA52C81265B11 ] Created: 23 January 2016 Status: Draft 0. Definitions client = an user running Tor as a client, which connects to a hidden service. hidden service server = the Tor instance hosting the hidden service. rendezvous point = the relay which acts as the rendezvous meeting point in a circuit between a hidden service client and a hidden service server. 1. Motivation A hidden service circuit (rendezvous circuit) is always initiated by the client so the relay which should act as the rendezvous meeting point is selected by the client. We assume that any client can be an attacker and will try to make the hidden service server connect to a malicious rendezvous point under his control. The attacker is also a Sybil (holds an unknown % of the bandwidth in the Tor network). By making the hidden service server build many circuits to his evil rendezvous points, the attacker gets a high probability that the hidden service server will eventually pick his evil relays in a circuit, so the attacker will trivially perform a successful hidden service guard discovery attack or, with more luck, discover the real location of the hidden service server. The hidden service server can only defend itself by building a 3 hop circuit to the rendezvous point, but in practice this is not always enough. 2. Logic for filtering malicious rendezvous points To be able to make fair assumptions about which rendezvous point might be malicious or not we are going to use the probability theory and statistics, precisely the binominal distribution equation [0]. In simple words, we count and keep track of how many rendezvous circuits a hidden service server built and to which rendezvous points. Then, based on the weight (middle probability fraction) of each rendezvous point, we determine if one was insanely overpicked by clients. Think of this like: Alice plays a game with Bob in which Bob has the success probability to draw a certain number n%. In practice however, he shows a success rate of more than (n*2)% (2 times bigger), Alice assumes Bob is not playing nice and will refuse to play with him for the next 24 hours or so. Fast example: A hidden service server built 100 rendezvous circuits in the last 24 hours, out of which in 7 of them the rendezvous point was a relay with the middle probability fraction of 0.5%. We assume that rendezvous point is malicious and refuse to build rendezvous circuits to it for the next 24 hours. 3. Equations and formulas 3.1 Probability of different clients genuinely picking the same rendezvous point n = total number of established rendezvous circuits. k = number of clients that could have genuinely picked the same rendezvous point. p = probability of picking that rendezvous point per client (middle probability fraction of the relay) divided to 100. H = Probability mass function expanded. C = The result of the equation, the value we need to determine multiplied with 100 to have the percent value. Formulas: H = n! / k!^(n - k)! C = H * p^k * (1 - p)^n - k Example: n = 100 k = 9 p = 0.5% / 100 = 0.005 H = 100! / 9!^91! = 20023492720 C = 20023492720 * 0.000000000000000000001953125 * 0.63372, ~ 0.00000000002478376524710625 * 100, ~ 0.000000002478376524710625% 3.2 Expected number of clients to pick the same rendezvous point n = Total number of established rendezvous circuits. p = Probability of picking that rendezvous point per client (middle probability fraction of the relay) divided to 100. We multiply this with 2 intentionally so we will allow 2 times more circuits than we would expect based on this formula - this should reduce the error margin enough. C = The result of the equation, the value we need to determine. Formula: C = n * p Example: n = 100 p = 0.5% / 100 = 0.005 * 2 = 0.01 C = 100 * 0.01 = 1 4. Implementation and variables We keep track in the persistent state of a hidden service server of the total number of built rendezvous circuits as well as a counter for number of rendezvous circuits per rendezvous point. Variables: REND_FILTER_MONITOR_PERIOD = count and track the rendezvous circuits built within this latest period. We set it to 24 hours. REND_FILTER_BAN_PERIOD = for how long we are going to ban a malicious rendezvous point. We set it to 24 hours. REND_FILTER_TOLERANCE = how many circuits we allow per rendezvous point regardless of its middle probability fraction. We set it to 4. REND_FILTER_BAN_ACTIVATION = when we should ban a malicious rendezvous point. To determine this, we are going to get from REND_FILTER_MONITOR_PERIOD the total number of established rendezvous circuits as well as the number of established rendezvous circuits with a given rendezvous point and apply the formula from 3.2 with approximation to the next whole number (example: 5.01 = 6; 5.99 = 6). Example: A hidden service server built 100 circuits in the last 24 hours out of which 5 to a rendezvous point with the middle probability fraction 1% (p = 0.02), so the expected number of circuits we expect is 2, but allow up to maximum 4 (if REND_FILTER_TOLERANCE > REND_FILTER_BAN_ACTIVATION, REND_FILTER_TOLERANCE prevails). In this case we consider this too much of a coincidence and ban this rendezvous point for the next 24 hours. We keep this ban in our persistent state with a timestamp so we'll know when it expires. 5. Ban malicious rendezvous points just for rendezvous circuits, not for anything else If we treat as relay as a malicious rendezvous point for a given time period, this only means we are not building circuits with it as the rendezvous point, but we don't exclude it for other purpose circuits, regardless which are those other purpose circuits. We may use them in our exit circuits, consensus fetch circuits, as HSDirs and HSDir fetch / post circuits, as Introduction Points or Introduction Point circuits. 6. Non zero probability to assign the malicious rendezvous point flag to an innocent relay This is indeed a non-zero value and it can be computed with the formula from 3.1, but it's a value so close to zero that we think it's totally worth it. Even if accidentally (low chances) an innocent relay will be banned, this will be something local to the hidden service server. It won't affect that relay at all, nor how other client or hidden service servers treat that relay. It has nothing to do with the network wide consensus as well. A honest client will always retry with a different rendezvous point, so honest clients should not experience reachability issues. 7. Rendezvous points that aren't included in hidden service server's consensus Clients and hidden service servers might have different consensuses. This means that a hidden service server can be genuinely asked to build a rendezvous circuit to a rendezvous point for which it has no middle probability fraction because it's not included in that consensus. We should allow REND_FILTER_TOLERANCE number of circuits to the rendezvous points for which we have no weights at all and if that rendezvous point appears in a later consensus within the REND_FILTER_MONITOR_PERIOD update its middle probability fraction value to ensure the filter will activate and work properly once REND_FILTER_TOLERANCE threshold was reached. 8. Security implications for maintaining such records in the persistent state of a hidden service server An attacker which compromises the location of a hidden service server will access this additional information: total number of rendezvous circuits built within the last REND_FILTER_MONITOR_PERIOD and to which rendezvous points these circuits were. This tradeoff should be worth it as well, since if the location of a hidden service server is compromised it is game over anyway, and this additional information shouldn't be so important to the attacker, except maybe for better determining the popularity of that hidden service (this can be determined many other ways, like the logs from the application running behind the hidden service, network counter, datacenter/ISP level counters and logs, etc.). To avoid co-location linkability between different hidden services, we should keep rendezvous circuits records and counters individually for each hidden service. The logic is designed to adjust by itself dynamically, based on the popularity and usage of a hidden service. If it's a high profile hidden service, experiencing 10000 connections per 24 hours, the REND_FILTER_BAN_ACTIVATION will increase for every rendezvous point. 9. Default option, with possibility to turn off for testing environments and experiments We add a new torrc option named HiddenServiceRendFilter 0|1 and set it to 1 by default. It can be turned off by setting it to 0, if this will be desired in some testing environments or experiments. 10. Other considerations, limitations and compatibility with other existing proposals This proposal won't disable an attacker entirely, but it will make it much harder and more expensive, given that the attacker will have to run more malicious relays to act as rendezvous points, increasing the capacity of the Tor network overall and directly the costs of the attack. Also, the attacker will have to grow the popularity of a hidden service so that he can establish more rendezvous circuits using the same rendezvous points. This will at least be kind of hard if other genuine clients pick the same rendezvous points and get noisy to the hidden service operator (much more traffic, same number or slightly more users on his service). This proposal is compatible with all the other hidden service related proposals to date. For tools like OnionBalance, each backend / fallback Tor instance included in the master hidden service descriptor will just transparently and individually maintain their own tracking vales and ban list. With proposal 260 - Rendezvous Single Onion Services this should be disabled since it makes no sense. Set HiddenServiceRendFilter 0 in a RSOS type hidden service. This proposal should be quite helpful once we implement enough padding between relays, where an attacker might have to own the entire path in order to distinguish dummy traffic from real traffic. This proposal should fit in nicely with proposal 247 - Vanguards and could make it safe to leave the 3rd hop wild (no layer 3 short term guards) and use only layer 2 medium term guards + layer 1 long term guard since an attacker will be able to establish less circuits to his malicious rendezvous point, thus drastically decreasing the chances of the hidden service server to also pick his malicious relay as 3rd hop to the malicious rendezvous point (layer 2 guards discovery). [0]: https://en.wikipedia.org/wiki/Binomial_distribution -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWo/K4AAoJEIN/pSyBJlsRAnMIAKFDDFm0DICrog1JecmrO82y N7dJf6tDURjGkUTr5i+mf91S4gTvxYigkT/tWTPH2E65XQGl2qLXo4d1+vgfaJmf H7QxUFy2kt+oFV03pg7SsF1KlMLaIVjlPMC17hPjAL8wnLMPkTICUn+VqWVYqmq+ w4uFPncm42mhkd3EwRq3HCrwq4O7PasWfSBYXmAuIJl6CWDkZqBI+UUj56dqQG6c zpWUMIZpfaMQzEJ438VhpVpiN19Ep5hIV5dJfz4MJ9eyhyas487nRXYyirEWqBs0 VXUsb/m/wgHICLjLukNYJ/+NZUk+Y5mIhL756HIiYUlL8UK85MaJhbozvjhqLnw= =tMjA -----END PGP SIGNATURE-----

5 13

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 25 Jan '16

25 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 25 Jan '16

25 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 24 Jan '16

24 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 22 Jan '16

22 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 21 Jan '16

21 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 19 Jan '16

19 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

Re: [tor-dev] Does Orbot use default obfs4 bridges?
by Nathan Freitas 19 Jan '16

19 Jan '16

On Tue, Jan 19, 2016, at 03:33 PM, David Fifield wrote: > On Tue, Jan 19, 2016 at 03:29:38PM -0500, Nathan Freitas wrote: > > > > On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote: > > > Does Orbot have a list of default built-in obfs4 bridges? Or do users > > > fetch them dynamically? I looked in the source code and found default > > > meek bridges but not default obfs4. > > > > No we have no default Obfs4 bridges built-in. It has been on my list to > > get done, because we really should, obviously to make the user > > experience better, and to alleviate meek traffic. > > > > > I'm asking because we recently added a few new high-capacity default > > > obfs4 bridges. > > > https://bugs.torproject.org/18071 (1 bridge) > > > https://bugs.torproject.org/18091 (2 bridges) > > > > I will get this built-in ASAP. > > The list of Tor Browser built-in bridges is here: > https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-D… Fantastic. Those will be built into the next release.

1 0

ENGINE_get_default_ECDx missing?
by Gisle Vanem 19 Jan '16

19 Jan '16

Seems these two OpenSSL functions: ENGINE_get_default_ECDSA() ENGINE_get_default_ECDH() have been dropped; in util/libeay32.num: ... ENGINE_get_default_ECDH 3387 1_1_0 NOEXIST::FUNCTION: ENGINE_get_default_ECDSA 3662 1_1_0 NOEXIST::FUNCTION: ... https://raw.githubusercontent.com/openssl/openssl/master/util/libeay.num (not sure exactly what 'NOEXIST' does). So shouldn't common/crypto.c be patched into something like: --- a/src/common/crypto.c 2016-01-14 22:29:59 +++ b/src/common/crypto.c 2016-01-18 17:55:53 @@ -373,8 +373,10 @@ used by Tor and the set of algorithms available in the engine */ log_engine("RSA", ENGINE_get_default_RSA()); log_engine("DH", ENGINE_get_default_DH()); +#if OPENSSL_VERSION_NUMBER < OPENSSL_V_SERIES(1,1,0) log_engine("ECDH", ENGINE_get_default_ECDH()); log_engine("ECDSA", ENGINE_get_default_ECDSA()); +#endif log_engine("RAND", ENGINE_get_default_RAND()); log_engine("RAND (which we will not use)", ENGINE_get_default_RAND()); log_engine("SHA1", ENGINE_get_digest_engine(NID_sha1)); Isn't OpenSSL 1.1.0 supported yet? Scratching head... BTW, I'm using TDM-gcc 5.1 (http://tdm-gcc.tdragon.net/) on Win-10. -- --gv

3 2

Re: [tor-dev] Does Orbot use default obfs4 bridges?
by Nathan Freitas 19 Jan '16

19 Jan '16

On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote: > Does Orbot have a list of default built-in obfs4 bridges? Or do users > fetch them dynamically? I looked in the source code and found default > meek bridges but not default obfs4. No we have no default Obfs4 bridges built-in. It has been on my list to get done, because we really should, obviously to make the user experience better, and to alleviate meek traffic. > I'm asking because we recently added a few new high-capacity default > obfs4 bridges. > https://bugs.torproject.org/18071 (1 bridge) > https://bugs.torproject.org/18091 (2 bridges) I will get this built-in ASAP. +n

2 1

Does Orbot use default obfs4 bridges?
by David Fifield 19 Jan '16

19 Jan '16

Does Orbot have a list of default built-in obfs4 bridges? Or do users fetch them dynamically? I looked in the source code and found default meek bridges but not default obfs4. I'm asking because we recently added a few new high-capacity default obfs4 bridges. https://bugs.torproject.org/18071 (1 bridge) https://bugs.torproject.org/18091 (2 bridges)

2 1

Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points
by George Kadianakis 19 Jan '16

19 Jan '16

Hello there, we recently finished implementing proposal 250 which is one of the first steps for the upcoming hidden service redesign [1]. The next steps are implementing proposal 224 and the other performance and security proposals [2]. On this note, one of the open design issues that we need to tackle next is whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro Points into a single entity to simplify the protocol and improve its performance. The idea is that HSes will pick their intro points using the hash ring algorithm currently used for picking HSDirs. Clients will do the same and connect directly to the intro points instead of going through the HSDir step. I suggest you read the proposal and the discussion thread to become better informed about this idea: https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html Proposal 246 changes the hidden service protocol substantially, which is why we need to decide whether to do it soon. The next steps in our implementation plan heavily depend on whether we will do proposal 246 or not. Here are some issues that make this proposal not an obvious pick: 1) Security issues - Professor Hopper pointed out [3] that this proposal will double the number of introduction points of a hidden service (from the current 3 to 6). Introduction points have slightly more attack vectors than HSDirs, so we should not increase their number without analyzing further. That said we could potentially increase the number of intro points by doing proposal 246, and at the same time we could also increase their lifetime period to multiple days (instead of the current 18-24 hours lifetime), to keep the exposure of hidden services to an acceptable value. - It was also pointed out that the HSDir algorithm does not take into account the bandwidth of the nodes, making it easier to launch Sybil attacks. However, the rest of the the mailing list thread suggests various ways to do bandwidth weighted hash ring selections [4], so this might not be an important factor. 3) Load balancing issue - With proposal 246, the Tor network decides which relays will be used as the introduction points of a hidden service. A hidden service cannot pick its own introduction points, similarly to how currently a hidden service cannot pick its own HSDirs. This is a problem because it blocks load balancing solutions like onionbalance from working. Variants of the onionbalance logic can still work as suggested in the proposal [5], at the cost of increased engineering and sysadmin complexity. - Another concern here is that hidden services would not be able to change the number of their introduction points. This is not a big problem currently, but it could become in the future if the network gets more overloaded. As a partial solution to this, #17690 suggests making the number of HSDirs a network-wide consensus parameter that could also be used by proposal 246. 2) Reachability issue A final issue here is that if the relay churn of the network increases, the introduction point hash ring might be changing rapidly and clients might get pointed to the wrong introduction points. However, this does not seem like a greater problem than what hidden services are facing with HSDir reachability currently. Is this right, or does prop246 makes it worse? Personally, I'm not that concerned about the security issues I outlined above. I think the security difference will not be that great, and maybe we can equalize it by using some of the listed solutions. However, more thinking is required. I'm currently more concerned about the load balancing and reachability issues that I outlined above and maybe others that I forget. I would like to have more assurance that relay churn will not cause reachability issues to the proposal 246 system before we commit to it. Feedback is very welcome. Also please post any issues that I forgot to mention. We should try to figure out what to do here as soon as possible. If we fail to come to a conclusion here, our engineering plan is to ignore proposal 246 and continue with proposal 224 like it never happened. Of course this will suck if we later decide that proposal 246 was super important and should have happened. Cheers! [1]: https://lists.torproject.org/pipermail/tor-dev/2016-January/010182.html [2]: https://lists.torproject.org/pipermail/tor-dev/2015-October/009762.html [3]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009093.html [4]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009163.html [5]: https://gitweb.torproject.org/torspec.git/tree/proposals/246-merge-hsdir-an…

7 10

Always up-to-date HSTS preload list for Tor?
by Ivan Ristic 18 Jan '16

18 Jan '16

Dear Tor developers, My SSL Labs server test has a feature where it checks for preloaded HSTS in Chrome, IE, Firefox, and Tor. You can see it near the bottom of this report, for example (under "HSTS Preloading"): https://www.ssllabs.com/ssltest/analyze.html?d=scotthelme.co.uk&s=107.170.2… For Tor, I download the preload list from this URL: https://gitweb.torproject.org/tor-browser.git/plain/security/manager/boot/s… That's the best I could find (when I originally implemented the feature), and I now see that the version number has advanced since. Which brings me to my question: is there a public URL that always contains the latest preload list? Thanks! -- Ivan

2 1

Upcoming Onionoo version 3.1 removes "family" field from details and stops returning code 500 when serving stale data
by Karsten Loesing 18 Jan '16

18 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Onionoo users, the upcoming Onionoo [0] version 3.1 will contain two minor changes that are worth announcing in advance: - Details documents will not contain a "family" field anymore but instead two fields "alleged_family" and "effective_family" which together contain the entries in the now removed "family" field. Clients that wish to continue using "family" field entries will need to switch to using the union of the other two fields instead. See #18026 [1] for details. - The Onionoo server will not return status code 500 anymore if its data gets more than 6 hours old but instead continue returning status code 200 with the somewhat stale data in the body. Clients that wish to keep the current behavior will need to check the "Last-Modified" header themselves and see if the contained timestamp is more than 6 hours old. See #16907 [2] for details. I'm planning to deploy version 3.1 in a week from now, by January 19, 2016. If you need to adjust your Onionoo client to these changes, please do that soon. All the best, Karsten [0] https://onionoo.torproject.org/protocol.html [1] https://trac.torproject.org/projects/tor/ticket/18026 [2] https://trac.torproject.org/projects/tor/ticket/16907 -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWk3T4AAoJEJD5dJfVqbCrSEAH/3nAFXDEzRQn2FgCVMXNGHQ+ NnWNs+56ZPMWnTx3IynAy6QTsF0r8iQ3gdrhoKTjpgI0mcHgfQi1GlAcFfw/+lZ4 VU1kueZvgK4Eja36wzjh5d2W7CQLq/1muj7rWlFyaBESrnAfc0TmLhYC/Ou8hxcu UtmsJHIE6L4MvYtMNzLSUukU0MVKPOpaAhMJ0U144NdekcD9FP5oVvm6u7SmsOJO /0MFwFlaLOT5Hur6cDBgksbkAQt5sXVx5Qbnf5GY+i/Vv6X4ZIwneY2e/dAwQdBe VZUIhl1TGFmCEnt3nYFG6TzxS4IrzetO6/6de4VDRiIu9ukcseY3IJs8rkjQh6k= =pyyb -----END PGP SIGNATURE-----

1 1

How many exits exit from an IP address different than their OR address? (10.7%)
by David Fifield 17 Jan '16

17 Jan '16

I wanted to know how many exits exit from an address that is different from their OR address. The answer is about 10.7%, 109/1018 exits. The interesting part is that of those 109 mismatches, 87 have an exit address that differs from the OR address in all four octets; i.e., the IP addresses used by the exit are not even in the same /8. Also, there are several groups of exits whose OR addresses *are* in a related subnet, but which all exit through the same, unrelated, IP address. See for example 109.236.82.* (all exiting through 185.108.128.7), 178.17.171.* (all exiting through 37.48.65.71), and 217.23.11.* (all exiting through 85.17.31.120) in the table below. I wrote an exitmap module that hits an IP-checker website. The module wrote a CSV file where each row included the exit's OR address and the address as reported by the remote web site. I ignored IPv6 OR addresses. I did not find any fingerprint that had more than one IPv4 address (considering the .fingerprint and .or_addresses members from Stem). Percentages are just raw counts, not weighted by exit probability. Total number of exits: 1018 (100.0%) Number of failures: 18 (1.8%) Number of matches: 891 (87.5%) Total number of mismatches: 109 (10.7%) Number of 1-octet mismatches: 19 (1.9%) Number of 2-octet mismatches: 3 (0.3%) Number of 3-octet mismatches: 0 (0.0%) Number of 4-octet mismatches: 87 (8.5%) Table of mismatches * = mismatch 1 octet ** = mismatch 2 octets *** = mismatch 3 octets **** = mismatch 4 octets fingerprint or_address remote_address mark B060482C784788B8A564DECD904E14CB305C8B38 176.10.104.241 176.10.104.240 * DC41244B158D1420C98C66F7B5E569C09DCE98FE 176.10.104.241 176.10.104.240 * 487092BA36F4675F2312AA09AC0393D85DAD6145 176.10.104.244 176.10.104.243 * DE7DE889E0D1A5F397AE35642060B84999581203 176.10.104.244 176.10.104.243 * 7A65CC8F45134F3393A0295EFFD2980DD885E8E2 176.123.6.157 176.123.6.155 * A7E78D9880BB0793409D386D15E83B3B1236B19F 178.175.128.54 178.175.128.50 * 8BF22BEA5F854F2BB2E09C71260ADF590D355E36 213.61.149.125 213.61.149.100 * 80D73E75A30BEEF627604B7014753304764E0723 213.61.149.126 213.61.149.100 * 5D263037FC175596B3A344132B0B755EB8FB1D1C 31.185.27.203 31.185.27.1 * C974508A98446F36169FB248655BCD50DF17F14C 37.130.227.134 37.130.227.133 * 170EC06D58E9094A027F4169514ADD98D30983A6 46.235.226.27 46.235.226.226 * D3BE73ECE50DA9243DC0DF9DA6ED25027B82D385 50.7.178.101 50.7.178.100 * FEDEF82551BB49DB54BE6C77D27AD0E20A8D6FD6 50.7.178.102 50.7.178.100 * 10E13E340651D0EF66B4DEBF610B3C0981168107 77.247.181.164 77.247.181.162 * 06E123865C590189B3181114F23F0F13A7BC0E69 77.247.181.166 77.247.181.162 * 664BDC0344771122FC6C4F577BF0AEC3F4ED5456 80.73.242.142 80.73.242.130 * 9E3E47D7B92144CBAB0D487CCE192531F6A55833 81.209.35.111 81.209.35.112 * 410C286061266C562049178C6BF1E04060F51F7C 94.103.175.85 94.103.175.86 * F4B72EA6FD0EACF652B6C200611F37244F2B31F3 94.242.228.107 94.242.228.108 * 62BEE61EB88D4A81C3BA3931D6FA999D706AC4D5 62.149.13.57 62.149.12.153 ** 1BC17B72F90998F0BAEE25E36FFC140C9D7A8D7A 85.119.82.4 85.119.84.57 ** AA60D088E8317BBA3D2CF96C706AB4452FB2F57D 90.182.128.100 90.182.235.46 ** 4E915A5CCDBBDD4BD4B7F09A5AFB581AB1AD7EF2 107.181.178.204 104.156.228.72 **** 03B4386E579BEBCF7605D0FB17A688B35C342D5D 109.236.82.50 185.108.128.7 **** C3B1E12BCA2F307B64737AB84993E7B414FD3D09 109.236.82.50 185.108.128.7 **** B9DC592CBC10EC7428730BF658F9211B8773800F 109.236.82.51 185.108.128.7 **** DE89B3B6954FFC0F76F6B37A05E2AD6EF3B046F1 109.236.82.51 185.108.128.7 **** CF9F5B88C0F95EB6C5547CE5FB38503049DF784D 109.236.82.52 185.108.128.7 **** 57275A9356CFB1D36E64B117D44AB9F67711E483 109.236.82.53 185.108.128.7 **** D1E52741A7DCB4D51C7EFC82A654E2527516E1B0 109.236.82.53 185.108.128.7 **** 7837F5B740223D19D8A0D3127D2A8EB9FDA59F67 148.163.73.112 206.217.208.162 **** B6045286F21E7078203E1B03C8E00669A2154724 148.163.73.112 206.217.208.162 **** D225C2EC81E044E3947BC49929E46003ED62C89F 151.80.164.147 46.166.186.238 **** 23A69F271ACBFACB20467559D1C04F13DEF74B4B 153.92.126.135 128.127.105.94 **** 4236DF494DC91E1245234AA676F1F993ECB067F5 153.92.126.135 128.127.105.94 **** 27CE487BABE6C2128FB2D1A801C7CB715B48EC6B 153.92.126.19 168.1.6.34 **** C369EB6BFDFB996864746944544B82C9684C46EA 153.92.126.19 168.1.6.34 **** 5453CAF677B8E754C4D5EFA1FEDD8ABB16950FCB 153.92.127.143 168.1.10.226 **** 756F68024C6E55FF7142AD933C135F88B552A932 153.92.127.143 168.1.10.226 **** B0E7C83FA0C728997BB60CB0C758A3A3FDC3C1DB 173.243.112.148 162.216.46.165 **** E6BE2BEAAF4A543F9D94CD20CB459ECFEA3AD1B1 173.243.112.148 162.216.46.165 **** 7585DDCEB14783C69960E777BA258F5B3948F1C9 176.126.85.175 159.122.133.198 **** CBBCD92AD9479C8FBB8AA17FF22C7EC206FF5B1A 176.126.85.175 159.122.133.198 **** 9634A0F1FBE02EBF6E0D59CA7835928D6D55CBCA 176.126.85.176 161.202.72.152 **** C68988E3DD72549AD9C3D1A67FAD056241154775 176.126.85.176 161.202.72.152 **** 58287449DDAD3CF4020071E1139CB4A22BB02D02 178.17.171.140 37.48.65.71 **** 7E2AFD5EA1FD32B0EBA4BDC3C102B9DC67B882E7 178.17.171.140 37.48.65.71 **** 59DE28A0D0A5529CEA9FC4B90DFCFCEC980C4139 178.17.171.156 37.48.65.71 **** E94FA1FDEDF7FC10208C51DABD4EC5045C0A4EC4 178.17.171.156 37.48.65.71 **** 52F6510B5D59678B77DF351C0F7F9B5A2070F393 178.17.171.157 37.48.65.71 **** A566EBAC657485F3D0AEE70C021EA2658D9F0B09 178.17.171.157 37.48.65.71 **** BCF9B6FA788E7F74DD77724D205C46195688D748 178.17.171.159 37.48.65.71 **** D41C2006D7C461BDC22B9D236CC93F5D366C1388 178.17.171.159 37.48.65.71 **** 5CECC5C30ACC4B3DE462792323967087CC53D947 178.32.181.96 37.187.129.166 **** 65F9944338C684109EB975D0EC7489B30E191E87 178.32.181.97 37.187.129.166 **** 66AA1EB64AAFEDC1EA8E49A701F6C472102C5E1A 178.32.181.98 37.187.129.166 **** 4F0003EAB0E8712B94B29A84BF8B8F34C95927BC 185.106.120.153 216.185.103.139 **** 4287D0C57CEFBE7E06B24A0E9370DC671FED5462 185.62.190.38 93.115.87.78 **** D96F409E59D5C41F3761F1F23438131BDE57C538 185.62.190.38 93.115.87.78 **** 8E15D869D266DF5B08351122185F9660CA6D0FA2 185.82.202.178 216.185.103.139 **** BF6379111EC2C29C104ED0239D5709D08BC3B9EB 188.209.52.109 5.149.249.10 **** 184E9215A97F21323BF8661329FCB6F89305CDAC 192.3.24.227 173.225.119.156 **** 9AC41D1DCA4A1BB5D52708E9EE00CED129567B7C 192.3.24.227 173.225.119.156 **** 7DF1BD29A7F927B61F31688395D39F75FC541647 209.141.43.84 67.212.234.181 **** 86D3FECC084BE5611B3F7F4791DAB6204C2E2996 209.141.43.84 67.212.234.181 **** 5F2F5B0014BE0C36E98EEAD5FC35A100FCCEDD4B 217.23.11.95 85.17.31.120 **** CC8C96DF58EFC67662FF751425D2A4D6C7D0F8F0 217.23.11.95 85.17.31.120 **** 1BE59B741F6DAECF29F13226C33B3282316BD81C 217.23.11.97 85.17.31.120 **** 83FCB9E1BE894C3947686AB6C11074B4AAA959B7 217.23.11.97 85.17.31.120 **** AB802EDBD1CF49CDE5A03394AC1B20C5DC1E17CE 217.23.11.98 85.17.31.120 **** C8D9AD239C658121999E56196A8AF74FF586A073 217.23.11.98 85.17.31.120 **** A478E6F4F193BDE43C3BD2BC6A5BC90DA5472FE8 217.23.7.25 168.1.99.217 **** B3233E96418C4E89AF22FC9A1F2392C0D194117B 217.23.7.25 168.1.99.217 **** 4AF6CEC4351DE02BB5A7CBBC82607171832C687B 217.23.7.79 168.1.99.217 **** 26ABA62FBEE9A751790C31AA9EE9E5014439769C 217.23.7.98 168.1.99.217 **** 382248E9E99857109B14344CF2B88166B41297A3 217.23.7.98 168.1.99.217 **** 137AEDE28D9E0BBABE2A5B2F476096740EF1A226 217.23.7.99 168.1.99.217 **** 69ABCEEE7117BBBBF74BA03C09963D28A4F7376F 217.23.7.99 168.1.99.217 **** FA4E22CFC0802D6738837DE980AFC7199F7DB040 217.34.135.225 136.0.2.226 **** 68F70BFCB2A5400ED6F98C8DB30C41A36743962D 217.37.19.115 95.211.184.197 **** C9A7289A94FF30C8772D7E70B56EACA330B95D08 31.220.42.170 95.211.148.154 **** D8082DFB5E22F23D60DE1F6A80986323FF86C027 31.220.42.170 95.211.148.154 **** D90ED0B491FB089EEA827188891BB47EBE13DC14 37.48.124.116 85.17.31.120 **** 276A7ACA7515E90ABB2AB36D4F3421B1C7FB4501 37.48.124.117 85.17.31.120 **** 5FEA88EFEDC5897F7094A1759CE25BA0D3DA87E7 37.48.124.117 85.17.31.120 **** 1F85C11528B6C599EDC488A68DF045F73D29CB18 37.48.64.48 109.201.143.40 **** F712F85AFA84A4D68A40A7AC20416D0B426969CD 37.48.64.48 109.201.143.40 **** 0C7A04579C0A53D99389333D2F9BAE35589F0F84 37.48.64.49 109.201.143.40 **** 71AE6B66F521BD5E6F304A08FB2ABADF4557D815 37.48.64.49 109.201.143.40 **** B9C49DBE93D7D70B41CF95C4F91EFDFC73FC5E60 46.105.183.141 108.61.123.75 **** D3DA6122AA416B8D7AB02CA9858DC3F206C656D2 46.105.183.142 108.61.123.75 **** D85E3FFE70BCBC6964969CDF1065457736D99DE4 50.7.124.238 161.202.72.185 **** 1AE0B173A9FA95D4258B9FC181FDB2BBF040F913 50.7.124.243 161.202.72.185 **** C5325DED0CFEA73F381920FADF5F1220B72841B8 50.7.124.243 161.202.72.185 **** 68D9005982673F068B7844D60915FD141155A8AC 51.254.83.238 108.61.123.75 **** 7774C0F736E02AD48C7A4F3BDFE636A21BBE0255 51.254.83.238 108.61.123.75 **** 4F154FF308400D5BDFB791FAD4C7577547BAA5CA 74.122.198.101 168.1.6.28 **** C75EC9CB9667CEC47BB155DD322789DBE0384ED8 74.122.198.101 168.1.6.28 **** 308D5B726051761D40DB31C7E89254A3CD3F27E0 78.142.19.59 85.17.25.22 **** 3D28E5FBD0C670C004E59D6CFDE7305BC8948FA8 78.142.19.59 85.17.25.22 **** 70119F72F2609BA1CC12640BF66905FE21768152 79.143.87.204 104.238.169.126 **** 83D664A8216DBE4BD48F71BDC61E8F7D8AB68517 79.143.87.204 104.238.169.126 **** C7E75D7D968C2355791EC29A420F69AF2737DA58 93.158.215.174 31.7.56.133 **** 0FAE6840763B2C9DDBCDD9DBA7C1A0549FF0155A 94.242.206.183 93.115.83.253 **** 13DFA359319F34F3FFC55154BDBC499FB5822C1C 94.242.206.183 93.115.83.253 **** 0760C0A34CCBCB2614075E27B88151FCC7D047EC 94.242.206.35 93.115.83.253 **** BFD74D651690324DCA9FB744E2D54DDC814DD3FB 94.242.206.35 93.115.83.253 **** 0BE8EBA01005974782C4573037F4F82D915166C5 96.43.142.28 80.82.215.199 **** A9FEB4AD16FC0ECCF5B01885374E4243E0981384 96.43.142.28 80.82.215.199 ****

8 12

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh
by Karsten Loesing 17 Jan '16

17 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Philipp and iwakeh, hello list, Damian and I sat down yesterday at the dev meeting to talk about doing a comparison of the various descriptor-parsing libraries with respect to capabilities, run-time performance, memory usage, etc. We put together a list of things we'd like to compare and tests we'd like to run that we thought we'd want to share with you. Damian and I will both be working on these for metrics-lib for a short while and then switch to Stem. Please feel free to join us in these effort. The result is supposed to live on Stem's home page unless somebody comes up with a better place. Thanks! All the best, Damian and Karsten On 30/09/15 10:57, Karsten Loesing wrote: > 1. capabilities - supported descriptor types - all the ones on > CollecTor's formats.html - hidden service descriptors (have an > agreed @type for that) - getting/producing descriptors - reading > from file/directory - reading from tarballs - reading from > CollecTor's .xz-compressed tarballs - fetching from CollecTor - > downloading from directories (authorities or mirrors) - generating > (for unit test) - recognizing @type annotation - inferencing from > file name - keeping reading history - user documentation - > validation (format, crypto, successful sanitization) - packages > available - how much usage by (large) applications > > 2. performance (CPU time, memory overhead) - compression: > .xz-compressed tarballs/decompressed tarballs/plain-text - > descriptor type: consensus, server descriptor, extra-info > descriptor, microdescriptors - validation: on or off (allows lazy > loading) > > 3. tests by descriptor type - @type server-descriptor 1.0 - Stem's > "List Outdated Relays" - average advertised bandwidth - fraction of > relays that can exit to port 80 - @type extra-info 1.0 - sum of all > written and read bytes from write-history/read-history - number of > countries from which v3 requests were received - @type > network-status-consensus-3 - average number of relays with Exit > flag - @type network-status-vote-3 - Stem's "Votes by Bandwidth > Authorities" - @type dir-key-certificate-3 - @type > network-status-microdesc-consensus-3 1.0 - @type microdescriptor > 1.0 - look at single microdesc cons and microdescs, compile list > of extended families - fraction of relays that can exit to port 80 > - @type network-status-2 1.0 - @type directory 1.0 - @type > bridge-network-status - @type bridge-server-descriptor - @type > bridge-server-descriptor 1.0 - @type bridge-extra-info 1.3 - @type > bridge-pool-assignment - @type tordnsel 1.0 - @type torperf 1.0 > > 4. action items - get in touch with Dererk for packaging > metrics-lib for Debian > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWDOCYAAoJEJD5dJfVqbCrwAMIAJ0Chlui/Qv5kiGy9WZVkoKU UsxiK1IGVh/eGrpunzKdWQtVhvv+285Ab0OUB4URTK5mpOE+bKD3vcFy3ziXvpke xl5X2rZ/MtzJpRrGcAue0+2YZBrmOsGtGbclH9LcnTRgs65AKFMUp/SPf30LS0Pw l8tg6xUtB7/97qxwNDj08J9Yp/YtWaankE0zuI3py10qa/2RTXBSjZ0JkemLmhxL zVy2yUirNdC+bq9rNh+qh2LMIIEEVbGX2sHJx4JdbLjrJAyrSPtyFhXaih4jkIz3 TptTymRwX8Peny7zEJkkGojH6FkOW0gwpfaZBd4vkphLUbyupHIt3k9aKS15Je0= =uGPS -----END PGP SIGNATURE-----

3 23

Fwd: Orbot 15.1.0-RC-1
by Nathan Freitas 15 Jan '16

15 Jan '16

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot 15.1.0-RC-1 Date: Fri, 15 Jan 2016 15:34:20 -0500 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Orbot v15.1 is out as a release candidate. It includes Tor 0.2.7.6, a very reliable VPN mode (full device or app-specific), a major update to Orbot icon, and many more important improvements. APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-1.apk Sig: https://guardianproject.info/releases/Orbot-v15.1.0-RC-1.apk.asc Code: https://gitweb.torproject.org/orbot.git/commit/?id=f541e9ffe14a2719863327bf… Changelog: https://gitweb.torproject.org/orbot.git/tree/CHANGELOG?id=f541e9ffe14a27198… /** 15.1.0-RC-1 / 15-January-2016 / f541e9ffe14a2719863327bf262b48de135ee0fd **/ We updated the essentials * 317405d update external versions of Tor 0.2.7.6 and OpenSSL 1.0.1q We made the ability scan QR codes from bridges.torproject.org work again! * 8f7165c fixes for settings processing and QRCode scanning of bridges - support new JSON array form bridges.torproject.org - only en ab We fixed the DNS leak bug in the VPN feature and improved the usability overall (no Orbot restart required) * 76b2171 update pdnsd and tun2socks to Android-16 add stpcpy function not present before Android-21 * 39244a6 fix the ability to select per app VPN routing * d839b15 fixes for VPN service UI to work on Android6 * 3691cca native binary asset building fixes move pdnsd exec to assets * f369652 add code to kill pdnsd daemon when VPN is stopped * f1fcec3 add support for PDNSD DNS Daemon for VPN DNS resolution Tor's DNS port doesn't work well with the VPN mode, so we will use PD * 8d8fe0c updates to improve VPN support * 699b60d add linancillary for badvpn tun2socks update for DNS We added the controversial ability for the user to easily set their exit country, with the default to the whole world * 52acf68 move "World" string to resource * 3b41365 allow country exit node select to persist * b208178 add initial support for easy exit country selection We now recommend Orfox over Orweb * 51205b8 update for Orfox * 0a5dd08 use a browser constant here, with the new constant being Orfox We made some new graphics * c54ab18 deleted these graphics * 534c2fb update style, icons and graphics We improve the build process, updated localizations and links to other repos: * 3240367 clean shouldn't clean assets, so we can easily builds for multiple platforms * 0081d00 remove Pluto Go building form this Makefile for now * 2288210 update to OpenSSL's github mirror * dfc5101 update tfx config * eaf49da update store and app translations * fe9119d update jenkins-build script * 6dc8cf6 update makefile for new pluto builds * 0261236 change this to "browser button" * 3462cbd small updates to icon and strings * bb55557 update installer to get PLUTO binaries from assets * 7d213e2 delete pluggable transport binaries here; build with Makefile use the external/pluto project * 6cf1201 update makefile to support PLUTO builds * 871701e add link for new icon * 6fb4f0c update binaries * cd0bfd3 [Trivial] Fixed broken reference to Main Activity in WALKTHROUGH * 0cde639 fix translations for common issues * 2acdd29 update localizations for strings and app description - - -- Nathan of Guardian nathan(a)guardianproject.info -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.3.3 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJWmVe+CRCoARg+abN6qQAAdksP/2REHo8U2M42/cBLD9Pd wKnPxGTNMnLYsv0Nq7hJMwmMky/7BNopBW9T2pjIiLSxj3soNUdw7LJAgA57 ns0bI2BNqILcai/gK3j9tw1dOQdfvYmfKL4omZuJpGSOSotGW/F9nVnv8SBn l8ddE0rU5FUyrJ3Si+QNgkCB4heij6oNOAFqrUb6YRQcUuu08tl18b3IGr1N VfWk4504FjwJIKX1LiYLVHRL2Se49UGYOmeg+cZtKcVV/6zmcl66hsaAdqZD +7IhcUivlGPU37v/IP3Af9hbpLIcW/eyW6Arf3kKD8Pv08mwg5gHQDblOcD0 j5Ai29Tig+75RHjmCdkIBnc4dhByGbNaiY49t12gBq2/m9zNwgqibmxozG3Y gTecvL5rGxgYdOYby1Hd9ndSF7x5R2L/IREAbotsvph4TxUhHh2AAnumAU9a YitErhaNE3vim6ywP8Il92WJ3gIDUlQimXAJuVmsOQcnXRLIq2LcJUW2IkfJ 1+D+Z4z1xJePDAOaguxK1WHb3TerG4y/CT7btQb2ibTf6u0pMgCYK7+bRf1S pPlkzr6sh+DWkihom+rU+vrLsqAhuGfVydsVy3RS+n6ea+dEpqY92YGaFXxZ XbwYrNOsBDD+rlzvKJr/51GgxmtGvVTfeh+P0bxClnIkwoyuDSH7MftONFeY OxI3 =16US -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Fwd: Orbot roadmap feedback
by Nathan Freitas 14 Jan '16

14 Jan '16

On Tue, Jan 12, 2016, at 10:48 AM, Georg Koppen wrote: > Nathan Freitas: > > - Overall improved configuration / settings UI to make tuning Orbot a > > better, simpler experience... this is an expansion of the new exit > > country selector in Orbot v15.1, but also includes managing things like > > network usage and so on. > > Could you explain that point a bit more, what you currently have and > what you plan to do? Especially the exit country selector seems kind of > scary to me but maybe I am just missing some bits. I looked at the > changelog you sent to tor-talk (in the alpha 1 release mail) but did not > find anything related. The broader idea is to determine which Tor torrc settings are relevant to the mobile environment, and that could use a more intuitive user interface than the empty text input we currently offer in our Settings panel. This may also mean implement a slider type interface mechanism similar to Tor Browser. In addition, users are interested in being able to control which network types (wifi vs 3g) Orbot runs on, in order to conserve spending on bandwidth. The Exit country selector option (basically a list of countries that starts with "World" as the option) is definitely controversial, but it is also something that comes up over and over again as a feature request. It is expected especially of a VPN-style app, which Orbot now is. It may be we only enable it when the VPN feature is enabled, and disable it when Tor is used directly via SOCKS from the Orfox browser. We may also need to just sufficiently warn and inform the user so they can decide for themselves what to do. +n

4 3

txtorcon: ipaddress instead of ipaddr?
by meejah 13 Jan '16

13 Jan '16

Regarding https://github.com/meejah/txtorcon/pull/155 does anyone have a good reason not to move txtorcon to using "ipaddress" -- this is a built-in library on Python3, with backports to Python2. Thanks, meejah

1 0

Re: [tor-dev] Fwd: Orbot roadmap feedback
by Nathan Freitas 13 Jan '16

13 Jan '16

On Tue, Jan 12, 2016, at 11:52 AM, Michael Rogers wrote: > On 12/01/16 16:16, Nathan Freitas wrote: > > The broader idea is to determine which Tor torrc settings are relevant > > to the mobile environment, and that could use a more intuitive user > > interface than the empty text input we currently offer in our Settings > > panel. This may also mean implement a slider type interface mechanism > > similar to Tor Browser. In addition, users are interested in being able > > to control which network types (wifi vs 3g) Orbot runs on, in order to > > conserve spending on bandwidth. > > Briar's TorPlugin has an option to disable Tor when using mobile data, > feel free to backport it to Orbot. Likewise for the plugin as a whole, > if it would be a suitable basis for LibOrbot. We've benefitted a lot > from your work and I'd love to send some contributions back upstream! Is TorPlugin already a distinct library / module? +n

2 1

Needs Code Review: Shared Randomness Generation for Tor
by George Kadianakis 13 Jan '16

13 Jan '16

Hello there, we are happy to tell you that we finished coding proposal 250 and our first attempt at implementation is ready for review. You can find the final specification here: https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final… and the corresponding code here: https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1 Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) will be used for code review. Please use this mailing list to discuss any issues with the spec. Some notes: We've separated this in 7 commits prefixed with prop250: except first one that adds a needed tor_htonll/ntohll function to tor utils. This code is mostly contained in two *new* files (with their headers) that are shared-random.{c|h} and shared-random-state.{c|h}. For what it's worth, we expect this code to run for a long time before the shared random values generated by the authorities are used for anything (e.g. HSDir scrambling). Cheers!

3 3