- tor-dev - lists.torproject.org

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

06 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

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

04 Apr '17

On 04/04/2017 12:50 AM, Nick Mathewson wrote: > On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis <desnacked(a)riseup.net> wrote: >> Nick Mathewson <nickm(a)torproject.org> writes: >>> 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. I2P has been doing this for years with *.b32.i2p for unique identifiers vs *.i2p for hosts.txt-style naming, and I'm planning on writing an I2P proposal to create a formal registry of 2LDs that implementations need to know about, so we have the ability to expand in future under the .i2p TLD. So I don't think it's a stretch for users to understand (although I have other concerns, see below), and I'd be keen to have a common standard for specifying subdomains that we can use for interoperability :) >>> >> >> I have mixed feelings about keeping the .onion suffix. >> >> One one hand it seems like The Right Thing to do, since we managed to >> get .onion standarized in the IETF which comes with various >> benefits. Also, starting to squat other tlds arbitrarily seems like a >> silly thing to do. This is the safest space for Tor to work in from a technical perspective. More specifically, I've been following discussion in DNSOP ever since the original special-use names draft (containing .onion, .i2p etc) was posted, and there is no way that the IETF is going to standardise any new TLD for non-DNS (see below). It's increasingly unlikely that the non-.onion TLDs in the draft will either (without industry support like .onion had), so no CA-supported SSL certs for I2P :( >> >> However, I also dislike asking users to visit something.bit.onion >> instead of something.bit, since people are not used to the second tld >> having a semantic meaning, and I can imagine people getting very >> confused about what it means. There's also the problem of transport-agnosticism. Assume there's some FOOnet that is created for naming that we all decide we want to use. Users would probably expect that FOOnet names all exist in the same space, which would not be the case if we had *.foo.onion, *.foo.i2p, etc. I'm thinking along the lines of IPv4 vs IPv6, where you can have a DNS name delegate to both via A and AAAA records; you wouldn't want the name changing just because the underlying transport changed. > > Indeed. And I'm not only concerned about people becoming confused: I > am also worried about confused programs. > > Right now, it is easy to answer the question "will Tor handle this > address specially" -- the only special addresses are the ones ending > with ".onion", and the legacy suffices ".exit" and ".noconnect" as > documented as address-spec.txt. But if we allowed arbitrary TLDs in > this proposal, then _any_ hostname would potentially be an address > that Tor would handle specially. > There is a draft currently in working-group last call that will specify a .alt TLD (or possibly .alt.arpa, it's still being debated [1]), that future non-DNS names will have to be under. Part of the proposed benefit is that with a standard TLD, DNS resolvers can just stub out that entire namespace, ie. if fqdn.endswith('.alt'): do_non_dns_lookup(fqdn) else: gethostbyname(fqdn) Presumably, browsers would do so as well. So it's possible that you could have *.foo.alt as the URI, but only *.foo is displayed in the browser (along with some chrome indicating it is non-DNS), similar to how only the base domain name is shown for some URIs (IIRC that's an SSL cert verification thing). The question then is how a browser would handle *.foo being typed in. You wouldn't want to query DNS and then try *.foo.alt afterwards, as that would be terrible for privacy, but if they tried *.foo.alt first, and didn't have FOOnet installed, should they try *.foo in the DNS? The browser either needs to know the full contents of *.alt (which is not possibly because by design it will have no official registration), or every registered TLD in DNS (which won't ever be added as a restriction because of various legacy local-net vendor TLDs like *.home). So with this approach, it's likely that .alt would need to stick around. Lots to think about here... str4d [0] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08 [1] https://www.ietf.org/mail-archive/web/dnsop/current/msg19983.html

1 0

Circuit times
by grarpamp 03 Apr '17

03 Apr '17

Anything going to blow up if set anywhere from 1k to 1M? CBT_NCIRCUITS_TO_OBSERVE

1 0

[prop269] [prop270] Ideas from Tor Meeting Discussion on Post-Quantum Crypto
by isis agora lovecruft 03 Apr '17

03 Apr '17

Hey hey, In summary of the breakaway group we had last Saturday on post-quantum cryptography in Tor, there were a few potentially good ideas I wrote down, just in case they didn't make it into the meeting notes: * A client should be able to configure "I require my entire circuit to have PQ handshakes" and "I require at least one handshake in my circuits to be PQ". (Previously, we had only considered having consensus parameters, in order to turn the feature on e.g. once 20% of relays supported the new handshake method.) * Using stateful hash-based signatures to sign descriptors and/or consensus documents, and (later) if state has been lost or compromised, then request the last such document submitted to regain state (probably skipping over all the leaves of the last used node in the tree, or the equivalent, to be safe). (This requires more concrete design analysis, including the effects of the large size of hash-based signatures on the directory bandwidth usage, probably in a proposal or longer write up, should someone awesome decides to research this idea further. :) Thanks to everyone involved in the breakaway group, and I apologise, but I don't actually remember all the attendants off the top of my head. If either of these were your idea, please message me off-list and I'll ensure you're credited in the eventual proposal(s)/documentation. Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

2 2