- tor-dev - lists.torproject.org

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