tor-dev

tor-dev@lists.torproject.org

3581 discussions

0.2.9 freeze dates, and fun bugs to work on, and important code to review
by Nick Mathewson 07 Oct '16

07 Oct '16

Hello, all! Here is an incomplete list of takeaways from network-team meeting last week, plus some more scheduling things, and other fun stuff for new (and experienced) Tor developers! * 0.2.9 is now frozen for big/risky changes. I'll put out the final alpha around 14 or 17 Oct, and fork 0.3.0 then too. * I'll continue to accept small, safe changes in 0.2.9 through the final alpha. Maybe a couple of days after. After that, I only plan to take fixes for critical bugs, regressions, and security issues. * Here are the open tickets in the 0.2.9 milestone [1]. Note that some of them have no owner! Many of them would be pretty easy for somebody to fix, if you want something to work on over the next few days. On the other hand, almost none of them seem must-fix-before-0.2.9-or-the-sky-falls to me. So if nobody works on a patch for them over the next week or so, they're probably going to have to wait for 0.3.0. * Here is the latest "review group" [2] -- a list of tickets where I'm not planning to review new big stuff outside of this group until everything in this group. During the 0.2.9 development period, using this method has gotten us to the point where we are reaching the final weeks of development without a huge backlog of unreviewed code. Writing reviews for this code can be a fun introduction to how Tor works! [1] Open 0.2.9 tickets: https://trac.torproject.org/projects/tor/query?status=!closed&milestone=Tor… [2] review-group-10: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~rev… all best wishes, -- Nick

1 0

CollecTor Release 1.0.2
by iwakeh 07 Oct '16

07 Oct '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! CollecTor continues with a smaller release: https://dist.torproject.org/collector/1.0.2/ This release makes features available that have been running on the main CollecTor [4] instance for a while now. The three most significant changes for release 1.0.2: * CollecTor provides Bifroest's descriptor data [1]. * A shutdown hook gives the running threads time to complete properly instead of simply terminating them [2]. * TCP ports are now replaced with hashes in @type bridge-network-status 1.1 and @type bridge-server-descriptor 1.2 descriptors [3]. and some more listed in CHANGELOG.md of the tar-ball. Cheers, iwakeh [0] https://dist.torproject.org/collector/1.0.2/ [1] https://trac.torproject.org/projects/tor/ticket/20037 [2] https://trac.torproject.org/projects/tor/ticket/19016 [3] https://trac.torproject.org/projects/tor/ticket/19317 [4] https://collector.torproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlf3ukkACgkQsANAxTOj/abFvwD/ap0UWbyMVUm/gL7zZarslLuM ocTxr7Xr3VUjznxLPHsA/0it/ia7Ym1RvgB/bxKuefxcGB9n20dC4tVCAlJFwDAJ =QgO8 -----END PGP SIGNATURE-----

1 0

txtorcon 0.17.0
by meejah 04 Oct '16

04 Oct '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce txtorcon 0.17.0, largely to fix a bug with Unix-socket control-ports: * issue 187: fix unix-socket control endpoints * sometimes mapping streams to hostnames wasn't working properly * backwards-compatibility API for `socks_hostname` was incorrectly named You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.17.0 https://github.com/meejah/txtorcon/releases/tag/v0.17.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.17.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.17.0.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 5e321387ab56f22d184b18d91a60c30dd1f72575d9e32ff3614ef911bce49daa txtorcon-0.17.0.tar.gz e1da13cc43328e040335d091e2ef15717a2b836b48fbede31fc6a7e332b699b4 txtorcon-0.17.0-py2-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX9B8gAAoJEMJgKAMSgGmnCLoH/jZNzTG4QRRKk54XkFCbSmBh Qg0YAmWVa4iFMkjidawyfZ8Cocje+yROMiuvH2VWNCcI809q96TB06caNJS0w5c3 I10i9N9xY2S13/yVzW/izW3HMPR+Sdi0Hod9UGTQ0F2Vpcs+g8bpPyKvMK+mPm+L P0QwyejOAO/FzTndA73T5o2bVKdR3NkK1EfY0FRTjQsD71UZlVJa4AK828v1EMi3 0oNXDny+H9xzJu/i03zFX3zSL1jb69KCxkLyUBIuj5Vg+3by8FwbBa1G3Ehcs70C RV6ew6WLa0Ty7fnUBy18Z3gFx9+4Ew/Eq/t7weVgRiW0VCAHwgOKx0D4wqSMeH8= =nyB6 -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Joining Tor Project's software infrastructure
by George Kadianakis 04 Oct '16

04 Oct '16

Paul Syverson <paul.syverson(a)nrl.navy.mil> writes: > [ text/plain ] > On Tue, Oct 04, 2016 at 12:54:55PM -0700, George Kadianakis wrote: >> >> BTW, monitor this list, there will soon be a proposal specifying a Tor >> API for naming systems like OnioNS, similar to the one we have for >> pluggable transports. >> > > There will? Was this discussed at tordev? How did I miss this? Who's > working on it? Is there a draft anywhere? > > (Feel free to respond to tor-dev. I just didn't want to spam the list > if good general answers to these were not quite ready.) > Hey Paul :) It was discussed on Sunday, the last day of the hackfest, so that's why you missed it :( Here are some spoilers: https://people.torproject.org/~asn/hs_notes/name_transport_plugin.jpg I hope to work on the proposal ASAP. [CCing tor-dev just for completeness]

1 0

uProxy adds Tor support
by David Fifield 30 Sep '16

30 Sep '16

https://blog.uproxy.org/2016/09/uproxy-adds-tor-support.html This blog post says that uProxy gained support for proxying others' traffic through Tor. uProxy client → censor → uProxy server → Tor → destination In the classic uProxy deployment scenario, the client and server are people who know each other. (I say "classic" because there are other deployment modalities now.) They each run a browser extension. The client encapsulates its web traffic and sends it to the server over WebRTC. The server then issues the web requests and sends the responses back over the WebRTC channel. A potential problem is that the uProxy server's own web browsing gets mixed up with that of the client. The client could, for example, get the server in trouble by accessing sketchy web sites. That's what the Tor integration is meant to solve.

1 0

Thesis using QUIC in Tor
by Ali Clark 30 Sep '16

30 Sep '16

Hi all, For my master's thesis this summer I looked into the performance impact from using QUIC instead of TCP/TLS as the relay transport. Results from the experiments look quite promising. For more details and the thesis, please see my blog post: https://www.benthamsgaze.org/2016/09/29/quux-a-quic-un-multiplexing-of-the-… I'm happy to respond to questions either here or in comments on the blog post. Ali

2 2

Constraining Ephemeral Service Creation in Tor
by bancfc＠openmailbox.org 29 Sep '16

29 Sep '16

Hello, We are working on supporting ephemeral onion services in Whonix and one of the concerns brought up is how an attacker can potentially exhaust resources like RAM. CPU, entropy... on the Gateway (or system in the case of TAILS) by requesting an arbitrary number of services and ports to be created. In our opinion, options in core Tor for setting a maximum number of services and ports per service seems the right way to go about it. Also rate limiting the requests (like you do with NEWNYM) would be a sensible thing to do. What are your opinions about this?

2 2

Reducing initial onion descriptor upload delay (down to 0s?)
by Ivan Markin 29 Sep '16

29 Sep '16

Hi tor-dev@! Moving the discussion on the future of rendinitialpostdelay from ticket #20082 [1] here. Transcribing the issue: > At the moment descriptor is getting posted at > MIN_REND_INITIAL_POST_DELAY (30) seconds after onion service > initialization. For the use case of real-time one-time services > (like OnionShare, etc) one has to wait for 30 seconds until this > onion service can be reached. Besides, if a client tries to reach > the service before its descriptor is ever published, tor client gets > stuck preventing user from reaching this service after descriptor is > published. Like this: Could not pick one of the responsible hidden > service directories to fetch descriptors, because we already tried > them all unsuccessfully. > It has jumped to 30s from 5s due to "load on authorities". > 11d89141ac0ae0ff371e8da79abe218474e7365c: > > + o Minor bugfixes (hidden services): + - Upload hidden service > descriptors slightly less often, to reduce + load on > authorities. > > "Load on authorities" is not the point anymore because we don't use > V0 since 0.2.2.1-alpha. Thus I think it's safe to drop it back to at > least 5s (3s?) for all services. Or even remove it at all? The questions are: * Can we drop this delay? Why? * Can we set it back to 5s thus avoiding issues that can arise after removing the delay? * Should we do something now or postpone it to prop224? [1] https://trac.torproject.org/projects/tor/ticket/20082 -- Ivan Markin

6 10

prop224: Ditching key blinding for shorter onion addresses
by George Kadianakis 29 Sep '16

29 Sep '16

Hello people, this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal. Anyway, after prop224 gets implemented, we will go from 16-character onion addresses to 52-character onion addresses. See here for more details: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… This happens because we want the onion address to be a real public key, and not the truncated hash of a public key as it is now. We want that so that we can do fun cryptography with that public key. Specifically, we want to do key blinding as specified here: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… As I understand it the key blinding scheme is trying to achieve the following properties: a) Every HS has a permanent identity onion address b) Clients use an ephemeral address to fetch descriptors from HSDir c) Knowing the ephemeral address never reveals the permanent onion address c) Descriptors are encrypted and can only be read by clients that know the identity onion key d) Descriptors are signed and verifiable by clients who know the identity onion key e) Descriptors are also verifiable in a weaker manner by HSDirs who know the ephemeral address In this email I'm going to sketch a scheme that has all above properties except from (e). The suggested scheme is basically the current HSDir protocol, but with clients using ephemeral addresses for fetching HS descriptors. Also, we truncate onion address hashes to something larger than 80bits. Here is a sketch of the scheme: ------ Hidden service Alice has a long-term public identity key: A Hidden service Alice has a long-term private identity key: a The onion address of Alice, as in the current scheme, is a truncated H(A). So let's say: onion_address = H(A) truncated to 128 bits. The full public key A is contained in Alice's descriptor as it's currently the case. When Alice wants to publish a descriptor she computes an ephemeral address based on the current time period 't': ephemeral_address = H(t || onion_address) Legitimate clients who want to fetch the descriptor also do the same, since they know both 't' and 'onion_address'. Descriptors are encrypted using a key derived from the onion_address. Hence, only clients that know the onion_address can decrypt it. Descriptors are signed using the long-term private key of the hidden service, and can be verified by clients who manage to decrypt the descriptor. --- Assuming the above is correct and makes sense (need more brain), it should maintain all the security properties above except from (e). So basically in this scheme, HSDirs won't be able to verify the signatures of received descriptors. The obvious question here is, is this a problem? IIUC, having the HSDirs verify those signatures does not offer any additional security, except from making sure that the descriptor signature was actually created using a legitimate ed25519 key. Other than that, I don't see it offering much. So, what does this additional HSDir verification offer? It seems like a weak way to ensure that no garbage is uploaded on the HSDir hash ring. However, any reasonable attacker will put their garbage in a descriptor and sign it with a random ed25519 key, and it will trivially pass the HSDir validation. So do we actually care about this property enough to introduce huge onion addresses to the system? Please discuss and poke holes at the above system. Cheers!

11 23

Paper on how DNS affects Tor's anonymity
by Philipp Winter 28 Sep '16

28 Sep '16

My colleagues and I published a (not yet peer-reviewed) research paper on how DNS affects Tor's anonymity. The key parts of our work are: - We measure the DNS setup of exit relays over time, showing that at times Google got to see almost 40% of DNS requests coming out of Tor. - We show how website fingerprinting attacks can be augmented with observed DNS requests, resulting in precise attacks for unpopular websites. - Similar to the "Users Get Routed" work, we simulate the impact of our attack at Internet-scale using the TorPS simulator. The PDF is available online: <https://nymity.ch/tor-dns/tor-dns.pdf> Our project page has code, data, and replication instructions: <https://nymity.ch/tor-dns/>

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev