tor-dev April 2017

tor-dev@lists.torproject.org

53 participants
50 discussions

Re: [tor-dev] Tracing TCP Connections online..
by Mike Guidry 10 Apr '17

10 Apr '17

re: grarpamp I am writing a possible countermeasure which uses transactional requests. You submit entire requests which are processed by the exit node. Several other situations can take place while routing to the exit node. It would also only require exit nodes to have updated to the newer feature. I'll post as soon as I'm finished.. Thanks, Mike Guidry ----- >This appears to describe an active network modulation attack (node DoS). >Either hammer tree on nodes of the expected path and trace the modulation, >or on all but the expected path to find unmodulated. >It generally requires GPA, deploying nodes, or being one end of the path... >in order to observe the results. >And it's old news. >As noted before, since Tor (and all other current anonymous overlays) >nodes do not perform their own independant buffering, reclocking and >contracting for expected hop parameters... this vulnerability will remain. >Anyone wanting to research, code, deploy, and present on >such countermeasures would certainly be welcomed.

1 0

Control-port filtering: can it have a reasonable threat model?
by Nick Mathewson 10 Apr '17

10 Apr '17

Hi! As you may know, the Tor control port assumes that if you can authenticate to it, you are completely trusted with respect to the Tor instance you have authenticated to. But there are a few programs and tools that filter access to the Tor control port, in an attempt to provide more restricted access. When I've been asked to think about including such a feature in Tor in the past, I've pointed out that while filtering commands is fairly easy, defining a safe subset of the Tor control protocol is not. The problem is that many subsets of the control port protocol are sufficient for a hostile application to deanonymize users in surprising ways. But I could be wrong! Maybe there are subsets that are safer than others. Let me try to illustrate. I'll be looking at a few filter sets for example. ===== Filters from https://github.com/subgraph/roflcoptor/filters : 1. gnome-shell.json This filter allows "SIGNAL NEWNYM", which can potentially be used to deanonymize a user who is on a single site for a long time by causing that user to rebuild new circuits with a given timing pattern. 2. onioncircuits.json Allows "GETINFO circuit-status" and "GETINFO stream-status", which expose to the application a complete list of where the user is visiting and how they are getting there. 3. onionshare-gui.json Allows "SETEVENTS HS_DESC", which is exposes to the application every hidden service which the user is visiting. 4. ricochet.json Allows "SETEVENTS HS_DESC", for which see "onionshare-gui" above. 5. tbb.json Allows "SETEVENTS STREAM" and "GETINFO circuit-status", for which see "onioncircuits" above. ===== Filters from https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/to… : 1. onioncircuits.yml See onioncircuits.json above; it allows the same GETINFO stuff. 2. onionshare.yml As above, appears to allow HS_DESC events. It allows "GETINFO onions/current", which can expose a list of every onion service locally hosted, even those not launched through onionshare. 3. tor-browser.yml As "tbb.json" above. 4. tor-launcher.yml Allows setconf of bridges, which allows the app to pick a hostile bridge on purpose. Similar issues with Socks*Proxy. The app can also use ReachableAddresses to restrict guards on the . Allows SAVECONF, which lets the application make the above changes permanent (for as long as the torrc file is persisted) ===== So above, I see a few common patterns: * Many restrictive filters still let the application learn enough about the user's behavior to deanonymize them. If the threat model is intended to resist a hostile application, then that application can't be allowed to communicate with the outside world, even over Tor. * Many restrictive filters block SETCONF and SAVECONF. These two changes together should be enough to make sure that a hostile application can only deanonymize _current_ traffic, not future Tor traffic. Is that the threat model? It's coherent, at least. * Some applications that care about their own onion services inadvertantly find themselves informed about everyone else's onion services. I wonder if there's a way around that? * The NEWNYM-based side-channel above is a little scary. And where do we go forward from here? The filters above seem to have been created by granting the applications only the commands that they actually need, and by filtering all the other commands. But if we'd like filters that actually provide some security against hostile applications using the control port, we'll need to take a different tactic: we'll need to define the threat models that we're trying to work within, and see what we can safely expose under those models. Here are a few _possible_ models we could think about, but I'd like to hear from app developers and filter authors and distributors more about what they think: A. Completely trusted controller. (What we have now) B. Controller is untrusted, but is blocked from exfiltrating information. B.1. Controller can't connect to the network at all. B.2. Controller can't connect to the network except over tor. C. Controller is trusted wrt all current private information, but future private information must remain secure. D. Controller is trusted wrt a fraction of the requests that the clients are handling. (For example, all requests going over a single SOCKSPort, or all ADD_ONION requests that it makes itself.) E. Your thoughts here....? signing-off-before-this-turns-into-a-capabilities-based-system, -- Nick

8 10

Tracing TCP Connections online..
by grarpamp 10 Apr '17

10 Apr '17

re: "tcp_tracing_internet.pdf" This appears to describe an active network modulation attack (node DoS). Either hammer tree on nodes of the expected path and trace the modulation, or on all but the expected path to find unmodulated. It generally requires GPA, deploying nodes, or being one end of the path... in order to observe the results. And it's old news. As noted before, since Tor (and all other current anonymous overlays) nodes do not perform their own independant buffering, reclocking and contracting for expected hop parameters... this vulnerability will remain. Anyone wanting to research, code, deploy, and present on such countermeasures would certainly be welcomed.

2 1

Re: [tor-dev] Feedback Extension for Tor Browser
by Jayati Dev 10 Apr '17

10 Apr '17

Dear Mentors, Is the project 'Feedback Extension for Tor Browser' still a part of GSoC 2017? I have already submitted a proposal and would like to work on it. Please help. Regards, Jayati Dev

2 1

Tracing TCP Connections online..
by Mike Guidry 10 Apr '17

10 Apr '17

Hello, Here is a document I've wrote regarding a concept to trace connections even through TOR. If you have any questions feel free to respond, and I'll attempt to explain. I have also considered a way to mitigate this situation being allowing TOR to be traced by using 'Transactional Requests.' I'll proceed to write it up, and post soon. I have released some other short papers as well. It contains several files regarding a few vulnerabilities, and a couple concepts regarding things like quantum resistant cryptography, etc.. URL: https://mega.nz/#F!QnZRXKyS!oluyILlMPpyJjPS57w7axQ Feel free to e-mail me directly.. Thanks, Mike Guidry

2 1

Comments on proposal 279 (Name API)
by Nick Mathewson 09 Apr '17

09 Apr '17

Hi ! I'll make some comments here on the draft onion naming API at https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-a… (Some of these are probably things you already meant, or already said elsewhere.) Section 2.1 and elsewhere: I suggest that we require all address suffixes to end with .onion; other TLDs are not reserved like .onion is, and maybe we shouldn't squat any we haven't squatted already. I think we might also want to have all output addresses end with .onion too. I suggest also that we might want to reserve part of the namespace for standardized namespaces and some for experimental or local ones. Like, if we standardize on namecoin that could be .bit.onion, but if we don't, it could be .bit.x.onion. I finally suggest that we distinguish names that are supposed to be global from ones that aren't. Section 2.3: How about we require that the suffixes be distinct? If we do that, we can drop this "priority" business and we can make the system's behavior much easier to understand and explain. Let's require that the TLDs actually begin with a dot. (That is, I think that ".foo.onion" can include "bar.foo.onion", but I don't like the idea of "foo.onion" including "barfoo.onion".) Section 2.3.1: Does the algorithm apply recursively? That is, can more then one plugin rewrite the same address, or can one plugin rewrite its own output? (I would suggest "no".) I think there should be a way for a plugin to say "This address definitely does not exist" and stop resolution. Otherwise no plugin can be authoritative over a TLD. Section 2.5.1: Is the algorithm allowed to produce non-onion addresses? Should it be? Must query IDs be unique? Over what scope must they be unique? Who enforces that? May query IDs be negative? Can they be arbitrarily large? I think result should indeed be optional on failure. Section 2.5.1 and 2.5.2: We should specify what exactly clients and plugins will do if they receive an unrecognized message, or a malformed message. Section 2.5.3. See security notes on caching below; client-side caching can lead to undesirable results. As noted above, I agree with requiring all result addresses to be .onion. Section 3.1: I prefer the "put everything under .onion" option. I also think that we should require that the second-level domain be 10 characters or less, to avoid confusion with existing onion addresses. General questions: I know we've done stdout/stdin for communication before, but I wonder if we should consider how well it's worked for us. The portability on Windows can be kind of hard. Two alternatives are TCP and named pipes. Another alternative might be just using the DNS protocol and asking for some kind of "ONION_CNAME" record. (DNS is ugly, but at least it's nice and standard.) Security notes: I'd like to know what the browser people think about the risks here of (eg) probing to see whether the user has certain extensions installed or names mapped. Maybe .hosts.onion should only be allowed in the address bar, not in HREF attributes et al? We might want to think about cache-related timing attacks here. Perhaps we should have a "no caching" rule. We should probably add a security notes section for how to write plugins that aren't dangerous: a bad plugin potentially breaks user anonymity.

7 10

Reverse Naming Proposals?
by grarpamp 09 Apr '17

09 Apr '17

These recent naming proposals on list, for forward naming 'string --> onion, 1:1', I think. Is anyone working on doing reverse naming, 'onion --> string, 1:1' ? With links to such work?

1 0

Adding Single Onion Service support to Bitcoin Core
by James Evans 08 Apr '17

08 Apr '17

Core is preparing to support this new tor feature. Any helpful suggestions would be appreciated. :) https://github.com/bitcoin/bitcoin/issues/9836 https://github.com/bitcoin/bitcoin/pull/10161 Thanks for all the great onion work! James

1 0

minimizing traffic for IoT Tor node over 3G/LTE
by Razvan Dragomirescu 08 Apr '17

08 Apr '17

Hello, I am working on a project to create very small Tor nodes on embedded devices connected over LTE or 3G. I have it working fine with OpenWRT and just 128MB of RAM, but the main issue is now the amount of data needed to download the consensus. The consensus files appear to be around 2.3MB at the moment and I think the default is to re-download every 3 hours, so that's 18.4MB/day or 552MB/month. Is there any way to reduce this while still maintaining good citizenship on the Tor network? Are there any recommended options for low-bandwidth nodes? Thank you, Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL

2 3

Re: [tor-dev] Comments on proposal 279 (Name API)
by str4d 07 Apr '17

07 Apr '17

On 04/06/2017 09:13 AM, Jeremy Rand wrote: > Hi Nick! > > Nick Mathewson: >> Section 2.1 and elsewhere: > >> I suggest that we require all address suffixes to end with .onion; >> other TLDs are not reserved like .onion is, and maybe we shouldn't >> squat any we haven't squatted already. > > FWIW it's not at all clear to me that this is a concern that IETF or > ICANN will care about. Most DNS recursive servers (e.g. Unbound) > allow squatting on arbitrary TLD's (this is often used for corporate > systems that use internal TLD's, but we use it for Namecoin as well), > and to my knowledge no one has complained to Unbound about the ability > to misuse this. Then you haven't been reading the DNSOP working group's mailing list - the IETF certainly cares. I recommend searching for ".onion", "special-use", "sutld", or "alt-tld" on their ML viewer [0] and reading the (extensive) back-history of these discussions. See below for a link to my earlier comments on this tor-dev thread [1], as well as several IETF drafts you may wish to read and comment on [2-3]. Cheers, str4d [0] https://mailarchive.ietf.org/arch/search/?email_list=dnsop [1] https://lists.torproject.org/pipermail/tor-dev/2017-April/012153.html [2] https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-03 [3] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev April 2017