- tor-dev - lists.torproject.org

CollecTor Release 1.1.1
by iwakeh 24 Nov '16

24 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! another small CollecTor version is available: https://dist.torproject.org/collector/1.1.1/ The release provides two changes * CollecTor now handles a rare internal error gracefully instead of escalating the problem [0], and * hidserv-* lines are now kept in sanitized extra-info descriptors [1]. In addition, the released .jar files are signed again, and a simple test during the release process ensures they'll get signed in future releases. Please direct comments and questions to the metrics-team mailing list [2]. And, of course, bug reports [3] or feature requests [4] can be filed in trac. Cheers, iwakeh [0] https://trac.torproject.org/projects/tor/ticket/20695 [1] https://trac.torproject.org/projects/tor/ticket/20714 [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team [3] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… [4] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlg3Yc4ACgkQsANAxTOj/abH6wD/bi7z7uysfbc4TIBG8poXD5yk GrSWrgfTAwhk0YHyfEIA/09jUs/JSGeTFJ8Y08QYV5ursBrYs/2rKVDL33A+1mwL =iAUd -----END PGP SIGNATURE-----

1 0

Distributed RNG Research
by bancfc＠openmailbox.org 23 Nov '16

23 Nov '16

New research on Distributed RNGs is published: "Scalable Bias-Resistant Distributed Randomness" eprint.iacr.org/2016/1067

2 1

Onionoo 3.1-1.0.0
by iwakeh 23 Nov '16

23 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! More than five years of development [0] led to the very first release of Onionoo, which is now available here: https://dist.torproject.org/onionoo/3.1-1.0.0/ For those who haven't heard of Onionoo: Onionoo [0] is a web-based protocol to learn about currently running Tor relays and bridges. Onionoo responds to HTTP GET requests with JSON-formatted replies. As reading JSON-files is not everyones favorite, there are quite a few client applications building on Onionoo's data and providing human-readable information [0]. In case you're wondering about the version number: The version of Onionoo consists of the current protocol version [2], which is 3.1 and the software's version 1.0.0. The first Onionoo protocol was already released two years ago. With the first Onionoo release and the accompanying operating guide [3] you're just one download away from running your own Onionoo mirror. Please direct comments and questions to the metrics-team mailing list [4]. Cheers, iwakeh [0] https://gitweb.torproject.org/onionoo.git/log/?ofs=500 [1] https://onionoo.torproject.org/ [2] https://onionoo.torproject.org/protocol.html [3] see release tar-ball: INSTALL.md [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlg12wIACgkQsANAxTOj/aaXjwEAj9NWFefHYPlY9UmIR7oflh/y U/DfO0kVf/aAigyI4u0A+QF6atK+Yqw1B+E7jjOL8wMhA4sDsnsRr7KxBA7QqwVG =NQpw -----END PGP SIGNATURE-----

1 0

Browsers, VMs and Targeted Hardware Bit-Flips
by teor 18 Nov '16

18 Nov '16

Hi all, There have been a series of recent attacks that take advantage of "rowhammer" (a RAM hardware bit-flipping vulnerability) to flip bits in security-critical data structures. VMs sharing the same physical RAM are vulnerable, and browsers and mobile apps are remote vectors with proof-of-concept implementations. Rowhammer summary: https://en.wikipedia.org/wiki/Row_hammer An attack that flips targeted bits in another virtual machine on the same physical RAM, targeting OpenSSH public keys, GPG public keys, and Debian package sources: https://www.vusec.net/projects/flip-feng-shui/ A similar proof-of-concept Android app: https://www.vusec.net/projects/drammer/ A JavaScript-based in-browser remote proof-of-concept: https://arxiv.org/pdf/1507.06955v1.pdf It seems like a short step from these existing attacks to targeting Tor Browser users remotely. I wonder whether it might be possible to target relays (or clients) using OR cells or directory documents with specific content, but this seems much less likely. I have been thinking about how we could make Tor (and browsers, and other processes, and OSs) less vulnerable to these kinds of attacks. In general, some of the process-level defences against one or more of the above attacks are: * sign or checksum all security-critical data structures, * implement and check cross-certification, * don't rely on cached checks (or checks performed at load time) continuing to be accurate, * minimise time between checking validity and using the data, (this includes signatures, checksums, data structure consistency) * make the content of memory pages (including loaded files) less predictable, * make sure the hamming distance between trusted, valid inputs and untrusted, valid inputs is large, in particular: * register domains that are one bit-flip away from trusted domains, (or, alternately, mandate SSL, and pin certificates, and fix broken CA roots) Some of the OS-level defences are: * turn off memory deduplication, * write and verify checksums on each page, Some of the firmware/hardware defences are: * increase the RAM refresh rate, * improve RAM design, * use ECC RAM. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

2 1

Adaptive CircuitStreamTimeout
by carlo von lynX 16 Nov '16

16 Nov '16

Hola! Documentation says if I do not set a CircuitStreamTimeout manually, then some internal logic will come to play. I presumed the timeout measurement protocol would influence that value, so performance of circuits would adapt to the radically different network conditions... but then I thought I'd check the source code and all the internal logic I can see is how a default of 15 seconds is used unless, given the complexity of it, I am overlooking something. So should I be configuring that value? -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/

1 0

Release: obfs4proxy-0.0.7.
by Yawning Angel 15 Nov '16

15 Nov '16

Hello all, I just tagged obfs4proxy-0.0.7. This affects relay side functionality and fixes bugs, so it is a recommended upgrade for relay operators. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.7… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.7… Changes in version 0.0.7 - 2016-11-15: - Support configuring the obfs4 IAT parameter as the sole ServerTransportOption on bridges, and correctly checkpoint the argument to the state file. - Correctly use the derived epoch hour when generating the server obfs4 ntor handshake response to be more tollerant of clock skew. - Reuse the read buffer when consuming obfs4 frames over the network to reduce memory consumption. Patch by oxtoacart. Thanks to the Lantern people for the memory consumption fix. Regards, -- Yawning Angel

1 0

Joining Tor Project's software infrastructure
by Jesse V 14 Nov '16

14 Nov '16

Hey everyone, Although it hasn't been obvious, I actually have been making some serious progress on my Onion Name System (OnioNS) project. The paper was accepted into PoPETS, the design is finally stable, and the software is looking really promising, although not yet ready for use. I've focused on improving the maturity of the software and set up the following: * PGP-signed commits using my torproject identity * Continuous integration via Travis CI * Use clang-analyzer and cppcheck static analysis scanners * Automated enforcement of code styling via clang-format * Inclusion of a manpage and command-line help menu * Packaging for Debian (Wheezy+) on my own machine * Automated building for Ubuntu (14.04+) on Launchpad * Protection against memory leaks and buffer overflows * Software is split to minimize installation footprint * Use of CMake, which should help the port to Windows * No RPATH hacks * Support for release and debug builds * Support for Clang and GCC; all warnings enabled for debug * No reliance on OpenSSL (CVE-2016-6309, are you serious?!) * Use of well-maintained libraries for networking and parsing * Minimal dependencies: Botan, JsonCpp, libcurl, libmicrohttpd * Non-native dependencies included as git submodules At this point, I am interested in taking the next step and try to integrate with the Tor Project infrastructure. I am looking for information on the following: 1) How do I upload packages to deb.torproject.org? 2) How do I join Gitian to generate reproducible builds? 3) How do I set up an Onion Name System component in Trac so that I can migrate bug tracking from Github to Trac? 4) How do I set up a repository on gitweb.torproject.org? I'm more comfortable using Github, but there's no need to centralize git. I have a LDAP account, which should help with some of these. I wasn't able to find much useful documentation on these topics, so I would appreciate some help. Also, if anyone has any experience with RPM packaging, I would like to figure that out. I haven't had too much luck with Alien. As I approach a proper release, my overall goal is to improve the maturity, trust, usability of the OnioNS software. Please let me know how I can accomplish the above tasks. Recent commits: https://github.com/Jesse-V/OnioNS-common/tree/json-rpc https://github.com/Jesse-V/OnioNS-server/tree/json-rpc https://github.com/Jesse-V/OnioNS-client/tree/json-rpc I've also updated https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems -- Jesse

3 4

[PATCH] FreeBSD's Tor port (security/tor-devel) update; 0.2.9.5-alpha
by Vinícius Zavam 08 Nov '16

08 Nov '16

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203014#c36 -- Vinícius Zavam keybase.io/egypcio/key.asc

1 0

Removing Countries with Low Counts from Metrics
by teor 07 Nov '16

07 Nov '16

Hi, Have we considered removing countries with low counts from metrics? (This probably means removing the metrics at the relays, not just the graphs.) For example, two places that are close to home for me: https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… If you suspected that someone was one of the few users on either of these small islands, it would be easy to monitor these graphs and determine when they were using Tor. Particularly in combination with the Australian Government's ISP-based metadata retention. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------

2 1

Different trust levels using single client instance
by bancfc＠openmailbox.org 07 Nov '16

07 Nov '16

Summarized question: Do you recommend allowing Workstation VMs of different security levels to communicate with the same Tor instance? Note that they connect via separate internal networks to the Gateway and have different interfaces & controlports so inter-workstation communication should not be possible. Single Tor Gateway, Multiple Workstations Pros: *Same guard node means less chance of picking a malicious one *Single Gateway VM uses less resources Cons: *Some unforeseen way malicious VM "X" can link activities of or influence traffic of VM "Y" **Maybe sending NEWNYM requests in a timed pattern that changes exit IPs of VM Y's traffic, revealing they are behind the same client? **Maybe eavesdropping on HSes running on VM Y's behalf? **Something else we are not aware of? Multi-Tor Gateways mapped 1:1 to Workstation VMs Pros: *Conceptually simple. Uses a different Tor instance so no need to worry about all these questions. Cons: *Uses a different entry guard which can increase chance of running into a malicious relay that can deanonymize some of the traffic. * Uses extra resources (though not much as a Tor Gateway can run with as little as 192MB RAM)

4 6