- tor-dev - lists.torproject.org

txtorcon versioning
by meejah 12 Apr '17

12 Apr '17

I will soon release the next version of txtorcon with a ton of cool new features. This will be called 0.19.0. More details: http://timaq4ygg2iegci7.onion/releases.html Going forward, versioning will switch to a "CalVer.org" variant. At one point, I thought of breaking a few now-regrettable APIs. However, I will not do this. The next version after 0.19.0 will be 17.x.y Changes in any existing APIs will be done by first introducing the new thing, deprecating the old thing and eventually removing the old thing. The new documentation's "programming guide" includes some notes on API stability. I have not to date broken/changed any existing API. Also at this point nothing is deprecated (but there are "preferred" APIs). The onion services APIs *will* change for the 17.x release. New code should follow the recommendations in the programming guide. Existing code will continue to work for the forseeable future. thanks, meejah

2 2

GNU Guix and Tor Browser Packaging
by bancfc＠openmailbox.org 11 Apr '17

11 Apr '17

There is a serious Tor Browser packaging effort [3][4] being done by ng0 (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles and most importantly reproducible builds. I have checked with Guix's upstream and they are working on making a binary mirror available over a Tor Hidden Service. [2] Also planned is resilience [2] to the attack outlined in the TUF threat model. [1] Back to the topic of Tor Browser packaging. While there are good reasons for Debian's pakaging policies they make packaging of fast evolving software (and especially with TBB's reliance on a opaque binary VM for builds) impractial. Both we and Micah have been doing a good effort to automate downloading and validating TBB but I still believe its a maintenance burden and Guix may be a way out of that for Linux distros in general. What are your thoughts on this? *** [0] https://www.gnu.org/software/guix/ [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html

2 2

Re: [tor-dev] Contents of tor-dev digest...
by Mike Guidry 10 Apr '17

10 Apr '17

I am not trolling you. I attached a PDF which explains how to trace TOR connections over the internet. It is not a joke. I have some other vulnerabilities at that URL I am releasing. I'll include here: Michael Guidry March 15, 2017 Tracing connections online from the virtual landscape to the physical world Hacking is the intrusion of a computer by an unwanted guest, and is usually used to express gaining access to corporate, or government networks. It requires either installing using malware, phishing, or directly connecting to machines and attacking their software with exploits. It is currently impossible to accurately trace hackers online unless they use the same software, and techniques for all their targets. It has become a major problem within the last decade due to globalization, and corporate networks directly connected to the Internet. Tracing Transmission Control Protocol (TCP) connections across the Internet is inaccurate due to how routing is performed across global backbones. The global routing table is modified constantly with nodes, and routes being adjusted for optimization, or quality of service needs. TCP is the most used protocol therefore it is the only protocol which really matters to attempt to trace. User Datagram Protocol (UDP) is state less therefore less reliable for tracking, however has the same vulnerability. UDP is usually used by hackers for exfiltration, or remote control after other actions have been performed. It is currently impossible to track connections over the Internet accurately. Several cases relate to The Onion Router (TOR) sites aka “Dark Web,” which were somehow uncovered using private technologies. Technologies used for those cases do not work properly over regular hacking via proxies online. Its an issue for the landscape of political hacking worldwide which has been increasing annually across the globe. China, for example, has been having a lot of blame lately due to Internet Protocol (IP) addresses assigned within its borders being used in massive amounts of attacks. Some of these attacks have been supposedly verified, however it is impossible for China to have performed them all. Proxy servers being used in chains may just be victims themselves. The problem arises due to possible evidence planting being similar to proxying through their others networks, or borders. It is completely different comparing cyber war to traditional conflicts due to evidence being traceable, and soldiers physical evidence being easily recovered. Hacking back is a concept any government, or corporation is now detailing within their playbook to understand how the liabilities may affect them. It is the terminology used to attack the source of an intrusion by means of hacking itself. Repercussions of hacking a country due to incorrectly assuming an attack was originating there is highly possible. Cyber war policies exists for a lot of nations, and it may easily escalate their attention on whom they believe is performing the attacks. The same happens with ‘proxy wars’ currently within the middle east, etc. Proxy wars traditionally will have global evidence allowing verification of weapon deliveries, or monetary exchanges to determine the origin of funding. Soldiers training methods, and other strategies may be impossible to cloak. It is generally accepted once verified, and escalation is directed towards the proper perpetrator. Internet Service Providers (ISP) have the ability to perform various tasks internally to determine the pathways through their networks which would reflect lateral hacking movements. Connections leaving a single network that enter the realm of dynamic routing via Border Gateway Protocol (BGP) become a nightmare. The percentage of accuracy decreases exponentially as each separate network is used to route the connection to its destination. It becomes nearly impossible to trace after just a few gateways at least publicly, or academically. Unorthodox methods are required to allow tracing of connections under these circumstances. Distributed Denial of Service (DDoS) is a solution that allows you to turn the internet’s own packet distribution system into a tracking mechanism. Most people do not consider performing DDoS attacks for positive reasons. DDoS may have been used by targets to “quarantine” their hacking source temporarily from the Internet. This strategy is beyond the scope of this technique, and is literally only a bandaid for a single attack originating from possibly just a proxy. DDoS is also illegal in most nations which have advanced their cyber crime laws. The fact that this technique requires many computers performing attacks strategically placed across the globe also ensures that they will be performed from countries where these laws are being enforced. The attack requires attacking all networks that you wish to verify against therefore you are immediately breaking laws on the destination side of most of the world simultaneously. It should not be used lightly, or regularly without cause and understanding. DDoS attacks transmit more data to a destination than a that network can handle which forces it to stop responding in a timely fashion. The latency is so high that the TCP timeouts are reached, and connections break. New connections are also impossible during these attacks. It has only had negative effects since it began being used globally regularly. This technique could be considered a reverse DDoS. The approach is to attack the entire world in a very strategically timed manner using worldwide machines. Each separate DDoS attack using machines worldwide would use different synchronization, and timing information which would allow embedding information directly into the latency it causes on those networks. The purpose is to compare that latency with the hack taking place to verify its source location. If the attack disrupts networks your attempting to verify against for milliseconds up to a few seconds then you can perform several of these sequentially to embed information in this timing itself. DDoS then becomes a positive useful solution even though technically illegal to a currently difficult problem. You wouldn’t necessarily have to attack the entire world. Conceptually it would be better to use databases of networks wishing to verify against. Residential, and commercial IP delegations throughout most nations would cover a large portion. Government hacking groups have their IPs leaked often as well. It is possible to just perform the attacks on these particular sets of IP addresses rather than the world as a whole. It is also equally possible to perform the attacks on entire ISPs, and countries to quickly determine although this would not be accurate due to possible proxies in between being within that country. If the technique is used on a major ISP network rather than a gateway going into an office then it is possible that a proxy exists within their network which would read off as a false positive. Accuracy relies on the networks your verifying against to be actual end user machines which would have human attackers. If you were to attack a network, or router of a network which has an office then it is highly likely they are going to notice other hackers using their network to hack externally on scales which would involve this type of solution. If you were to attack an entire country then you are going to have a problem of not recognizing from timing alone whether or not a proxy (of possibly several) just exist in that country. It is imperative to understand this, and always attempt to get as close to the networks in question being verified. Original message: Are you trolling us? I don't get it! On Sun, Apr 09, 2017 at 08:19:28PM -0400, Mike Guidry wrote: > 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 4

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 09 Apr '17

09 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 08 Apr '17

08 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