tor-dev

tor-dev@lists.torproject.org

3581 discussions

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

GSoC: Support all kinds of DNS queries
by Daniel Achleitner 07 Apr '17

07 Apr '17

Hi everyone, I'm a Software Engineering master's student at TU Wien, Austria, with a recent focus on computer security and privacy issues. I am interested in participating in GSoC 2017, particularily in the task to support all kinds of DNS queries via Tor [1]. I've seen the mailing list discussions of 2012 and read the resulting proposition 219 [2]. What do you think, which parts of it (if any) would need to be adapted for DNS in 2017? My current impression is that not much has changed, particularily regarding DNSSEC support and deployment. As of now, the proposal looks fairly complete with few questions remaining, the biggest research task being how to utilize libunbound for query/response parsing and construction. Implementing the RELAY DNS cells then seems fairly straightforward. Unit/integration tests and some fuzzing would be a good idea. The problem of reducing DNSSEC roundtrips (serialization) to be investigated in a later phase, I would say. Is a separate AXFR tool still something that is desired? I have no experience with zone transfers -- can't the existing tooling just be used over a normal TCP conn through Tor? This project idea would make a good match to my thesis in progress, for which I am researching and evaluating privacy-improving DNS tools in the context of Tor (DNSCrypt, DNS-over-TLS) [3], inspired by the awesome paper on DNS correlation [4]. For example, I recently built a SOCKS-to-SOCKS translator which allows to resolve hostnames using a resolver of choice, e.g. using DNSCrypt with TBB. Looking forward to hearing your thoughts, concerns and opinions! Best regards, Daniel IRC handle on OFTC: idealchain [1]: https://www.torproject.org/getinvolved/volunteer.html.en#supportAllDNS [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.t… [3]: My work-in-progress mindmap about DNS Privacy (not related to prop219): https://drive.google.com/open?id=0B3d38csDsjwudDJOUjRleE93bjQ [4]: https://nymity.ch/dns-traffic-correlation/tor-dns.pdf

2 3

Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser
by Donncha O'Cearbhaill 06 Apr '17

06 Apr '17

Hi all, The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages. Increasingly these attackers are becoming more selective in their targeting. Some attackers are only targeting a handful of pre-configured pages. As a result, we often rely on Tor users to report bad exits and the URLs which are being targeted. In Firefox 51, Mozilla started to highlight HTTP pages containing password form fields as insecure [1]. This UI clearly and directly highlights the risk involved in communicating sensitive data over HTTP. I'd like to investigate ways that we can extend a similar UI to Tor Browser which highlight Bitcoin and onion addressed served over HTTP. I understand that implementing this type of Bitcoin and onion address detection would be less reliable than Firefox's password field detection. However even if unreliable it could increase safety and increase user awareness about the risks of non-secure transports. There is certainly significant design work that needs to be done to implement this feature. For example, .onion origins need be treated as secure, but only if they don't included resources from non-secure origins. We would also need to make the onion/bitcoin address detection reliable against active obfuscation attempts by malicious exits. I'd like to hear any and all feedback, suggestions or criticism of this proposal. Kind Regards, Donncha [1] https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-n…

7 8

Counter-RAPTOR Paper
by Yixin Sun 06 Apr '17

06 Apr '17

Hi all, Our proposed defenses (Counter-RAPTOR) against active routing attacks on Tor will soon appear at IEEE S&P in May. It's also available here: https://arxiv.org/abs/1704.00843 In short, we have two lines of defenses: (1) Entry Guard Selection (proactive defense, https://github.com/inspire-group/Counter-Raptor-Tor-Client) (2) BGP Monitoring on Tor relays (reactive defense, in progress of making it public) Please let us know if you have any questions/comments. Thanks! Yixin

2 1

"Anomalous keys in Tor relays" technical report now available
by Laura M. Roberts 05 Apr '17

05 Apr '17

Hello, Tor devs! We have just published a (not yet peer-reviewed) technical report entitled "Anomalous keys in Tor relays." https://nymity.ch/anomalous-tor-keys/ The project was inspired by the "Mining Your P's and Q's" paper from Heninger et. al., and in it, we take a closer look at the RSA keys used in Tor since 2005. We found that entities had purposely created anomalous keys in order to attack Tor's onion services and that researchers had inadvertently created weak keys while conducting experiments on Tor. (None of the weak keys we found are affecting the current Tor network.) We welcome your questions and feedback! Regards, George, Claudia, Laura, & Philipp

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev