- tor-dev - lists.torproject.org

txtorcon 18.3.0
by meejah 06 Oct '18

06 Oct '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hot on the heels of 18.2.0 comes 18.3.0 because I forgot to add the "single_hop=" feature to endpoint-strings: * add `singleHop={true,false}` for endpoint-strings as well You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.3.0 https://github.com/meejah/txtorcon/releases/tag/v18.3.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.3.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.3.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… 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 5601956b3a2452526cd1ea31662696a51ddbf8ed6452633ee464fc1ff275f8b0 dist/txtorcon-18.3.0.tar.gz 8edac3b6d9c633b9182b4e5a2ed3ac86953ed44b9ea230aac3e0708c30b73861 dist/txtorcon-18.3.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlu37ycRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaafaFAf/e4pVR7bL+gDMq2sJVaFVFzsQqPTV2RLi 9e5A7RRfCPfDSPMyJg71I5qnXXY7aXMP5kBOmK1WF7hN06NRrYGuVifWzijogosP l/2KIGp1I6nK77JTNdjPqnSfQ9N+/ZXaXK3ILzlmSiyI3PMaLgPjB0x2JM6NhcfQ pPPKuL9K0bw94slGSTJa29py4yBV4VhAG0qwHEigw3Zwie2iAejk1GwSW9UEhJnp GBDECiaBdgDZZozn43Q9WXoVIcTnsjTBIN9Km3gNgIcn+ZbwH461HKDXvW7yDfsV oZ7thGr5xD9ENErOzWgU52kMOOuo/pM50vAlzJC518iV39deCD1GQA== =6d14 -----END PGP SIGNATURE-----

1 0

txtorcon 18.2.0
by meejah 05 Oct '18

05 Oct '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm glad to announce txtorcon 18.2.0. This adds or fixes the following: * add `privateKeyFile=` option to endpoint parser (ticket 313) * use `privateKey=` option properly in endpoint parser * support `NonAnonymous` mode for `ADD_ONION` via `single_hop=` kwarg You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.2.0 https://github.com/meejah/txtorcon/releases/tag/v18.2.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.2.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.2.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… 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 b1714dfa633cb4097c9ea649c8c49657d9d22a990cc465bb904620428c5e684e dist/txtorcon-18.2.0.tar.gz 9d05f2b1144dfbc63844e78fbc51a195e3b39a79f280db50a81b346476c47e7b dist/txtorcon-18.2.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlu2qS0RHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaafvxAgAxsqlJ7LcnX2SxU89NHXJZ/og9ZkcKF89 RCAdYm/G1R4cJpqX9wjd0Kt38NJJyt/SuT95wGtYInLjrrTs3lzg7ToLoRxIodaF rXdlnUKaNJBStpIW62oJ1WRq8AFsjtjnxFv9iuIyUCA7BMh/nkKwCMoEOqtQ/KbO V43DjZpTr9cQmn62c1b6H+x+TVXhyZxiTK0d7WTHrrKbMOIpSKIJTezZvOfDV7MC dQdmLlhE1qxW8X5UjlNeWApuGWtY6U9aSVJcglN6Ecp8bZcvvS9LSWxn+KHkbzFX uLOgTyfp9/mQsAeVosp9HQ7iB+6BD27blJlMIBFPNLoBaFNjX91H7A== =v2ac -----END PGP SIGNATURE-----

1 0

Information on the handling of relays churn
by Adrien Luxey 28 Sep '18

28 Sep '18

Dear Tor developers, As a PhD student in distributed systems, I am studying onion routing. We would like to investigate an onion routing system that would run on users devices, i.e. a lot of nodes with crappy bandwidth and intermittent connection. To compare against Tor, I have been looking for information about how you currently handle the disconnection of relays, but I found no "digest" on the Web. Your code seems to point to the direction of core/or/circuit*, that I need to investigate further. I still would love some first-hand high-level description from you guys. I have the following questions: * When an OR disconnects while supporting active circuits, how is the failure detected? * How are the paths subsequently rebuilt? * To which extent would you say that Tor is resilient to churn? What would be the effects of a massive churn of relays? Where would be the bottleneck? If you have any questions on my work, I will be pleased to answer (though a little ashamed, because I know our system will never hold your security properties so tight)! With much respect for your work and philosophy, Adrien Luxey

4 4

txtorcon 18.1.0
by meejah 27 Sep '18

27 Sep '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm very pleased to announce txtorcon 18.1.0. This adds or fixes the following: * better error-reporting (include REASON and REMOTE_REASON if available) when circuit-builds fail (thanks David Stainton) * more-robust detection of "do we have Python3" (thanks Balint Reczey) * fix parsing of Unix-sockets for SOCKS * better handling of concurrent Web agent requests before SOCKS ports are known * allow fowarding to ip:port pairs for Onion services when using the "list of 2-tuples" method of specifying the remote vs local connections. You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.1.0 https://github.com/meejah/txtorcon/releases/tag/v18.1.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.1.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.1.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… 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 b61cf175a5f1d4092609caf05d178fcdcabf513928eec98d38125c501afea43c dist/txtorcon-18.1.0.tar.gz 98aba4a96c355c55ee5d8290b67a09380b02e1044fb2e76737f47f5a33659dce dist/txtorcon-18.1.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlusMDQRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaadz3wgAk+UbYuw0lIwEqQZbhQ6oTk0cTu5GrB5q WkSbqPkj5Ph+y1iYMQoEgAZdD97zjpfGR+/JcyXbPyh4ZDcqkL8Hhay9yF2/PAkd agu1LBuBjVXOFvcw3D8Xi91miFwjmMKznAuR1Jv9gp66emw3qbZRZE9g1S9o1lCX 3Cx6o3kLiq8h7UmOiqFfCFGjNBFsaiDqf35P7FH7Btg4FYIGtI5/uQ3qgDtyqlhD YKA91KxZQoZFGiAhp5h84WXrvtuQ5tDjRNiIfh76xRFiFRnWe9ofELidKqEgnyzF shBqdGpaIT0g0NTQRhCnzBM7m3u0RHxkRblJWBLa6t4KYNFTMJ8Pag== =z+Lo -----END PGP SIGNATURE-----

1 0

[release] Tor Metrics Library 2.5.0 and Tor Metrics Website 1.2.0
by Karsten Loesing 26 Sep '18

26 Sep '18

Hi, we just released new versions of the Tor Metrics Library, metrics-lib 2.5.0, and Tor Metrics Website, metrics-web 1.2.0. The primary reason for these new releases is that libraries contained in the tarball match the ones needed to build current master. Downloads are available at: https://dist.torproject.org/metrics-lib/2.5.0/ https://dist.torproject.org/metrics-web/1.2.0/ Please direct comments and questions to the metrics-team mailing list: https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team All the best, Karsten -- on behalf of the Metrics Team.

1 0

I
by john loughlin 25 Sep '18

25 Sep '18

Sent from my iPhone b

1 0

Memory usage on 0.3.4.8
by r1610091651 24 Sep '18

24 Sep '18

Hi devs After upgrade from 3.3.7 -> 3.4.8, I've noticed that memory usage is erratic. Please consult the image below, showing memory available in green and memory used in blue on a tor dedicate system. [image: image.png] The upgrade to 3.4.8 took place on Saturday in week 37. The connection count / load was relativity stable: [image: image.png] (green inbound, blue outbound) I was wondering if there were any changes from 3.3.7 to 3.4.8 which might impact memory behaviour on a middle-relay. I'm also wander what is the "source" of this usage? Potentially relevant config entries (remainder is port/ip, accounting & exit(no)): MaxConsensusAgeForDiffs 4 hours DirCache 0 MaxMemInQueues 64 MB (but "defaulting" to 256mb now) Thanks in advance Seb

2 1

Strong Flow Correlation Attacks on Tor Using Deep Learning
by procmem 21 Sep '18

21 Sep '18

Hi I wanted to bring your attention to this recent Tor attack paper published at the CCS conference: https://arxiv.org/pdf/1808.07285.pdf > We show that with moderate learning, DeepCorr can correlate Tor connections (and therefore break its anonymity) with accuracies significantly higher than existing algorithms, and using substantially shorter lengths of flow observations. For instance, by collecting only about 900 packets of each target Tor flow (roughly 900KB of Tor data), DeepCorr provides a flow correlation accuracy of 96% compared to 4% by the state-of-the-art system of RAPTOR using the same exact setting. > > We hope that our work demonstrates the escalating threat of flow correlation attacks on Tor given recent advances in learning algorithms, calling for the timely deployment of effective countermeasures by the Tor community. It has an extremely high true positive rate under real world conditions. The two main suggested countermeasures are padding and AS-aware path selection. I think you are working on the former but no practical implementation of the latter is ready?

1 0

Proposal 297: Relaxing the protover-based shutdown rules
by Nick Mathewson 21 Sep '18

21 Sep '18

Filename: 297-safer-protover-shutdowns.txt Title: Relaxing the protover-based shutdown rules Author: Nick Mathewson Created: 19-Sep-2018 Status: Open Target: 0.3.5.x 1. Introduction In proposal 264 (now implemented) we introduced the subprotocol versioning mechanism to better handle forward-compatibility in the Tor network. Included was a mechanism for safely disabling obsolete versions of Tor that no longer ran any supported protocols. If a version of Tor receives a consensus that lists as "required" any protocol version that it cannot speak, Tor will not start--even if the consensus is in its cache. The intended use case for this is that once some protocol has been provided by all supported versions for a long time, the authorities can mark it as "required". We had thought about the "adding a requirement" case mostly. This past weekend, though, we found an unwanted side-effect: it is hard to safely *un*-require a currently required protocol. Here's what happened: - Long ago, we created the LinkAuth=1 protocol, which required direct access to the ClientRandom and ServerRandom fields. (0.2.3.6-alpha) - Later, once we implemented Ed25519 identity keys, we added an improved LinkAuth=3 protocol, which uses the RFC5705 "key export" mechanism. (0.3.0.1-alpha) - When we added the subprotocols mechanism, we listed LinkAuth=1 as required. (backported to 0.2.9.x) - While porting Tor to NSS, we found that LinkAuth=1 couldn't be supported, because NSS wisely declines to expose the TLS fields it uses. So we removed "LinkAuth=1" from the required list (backported to 0.3.2.x), and got a bunch of authorities to upgrade. - In 0.3.5.1-alpha, once enough authorities had upgraded, we removed "LinkAuth=1" from the supported subprotocols list when Tor is running with NSS. [*] - We found, however, that this change could cause a bug when Tor+NSS started with a cached consensus that was created before LinkAuth=1 was removed from the requirements. Tor would decline to start, because the (old) consensus told it that LinkAuth=1 was required. This proposal discusses two alternatives for making it safe to remove required subprotocol versions in the future. [*] There was actually a bug here where OpenSSL removed LinkAuth=1 too, but that's mostly beside the point for this timeline, other than the fact it would have made things waaay worse if people hadn't caught it. 2. Recommended change: consider the consensus date. I propose that when deciding whether to shut down because of subprotocol requirements, a Tor implementation should only shut down if the consensus is dated to some time after the implementation's release date. With this change, an old cached consensus cannot cause the implementation to shut down, but a newer one can. This makes it safe to put out a release that does not support a formerly required protocol, so long as the authorities have upgraded to stop requiring that protocol. (It is safe to use the *scheduled* release date for the implementation, plus a few months -- just so long as we don't plan to start requiring a subprotocol that's not supported by the latest version of Tor.) 3. Not-recommended change: ignore the cached consensus. Was it a mistake to have Tor consider a cached consensus when deciding whether to shut down? The rationale for considering the cached consensus was that when a Tor implementation is obsolete, we don't want it hammering on the network, probing for new consensuses, and possibly reconnecting aggressively as its handshakes fail. That still seems compelling to me, though it's possible that if we find some problem with the methodology from section 2 above, we'll need to find some other way to achieve this goal.

5 6

Back to the action!
by Fernando Fernandez Mancera 18 Sep '18

18 Sep '18

Greetings! I have been out this summer but I am back and I want to continue contributing. Starting next week I will attend the network-team meetings if you don't mind. If there is any task you could think it fits with my experience, please let me know. If there isn't, I am going to search in the ticket list. I am preparing my environment right now, and by tomorrow I will be ready to work! Thank you and see you soon at #tor-dev, ffmancera.

1 0