November 2016 - tor-dev - lists.torproject.org

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

Revisiting prop224 client authorization
by George Kadianakis 04 Nov '16

04 Nov '16

Hello, we've reached the point in prop224 development where we need to pin down the precise cell formats, so that we can start implementing them. HS client authorization has been one of those areas that are not yet finalized and are still influencing cell format. Here are some topics based on special's old notes, plus some further recent discussion with David and Yawning. a) I think the most important problem here is that the authorization-key logic in the current prop224 is very suboptimal. Specifically, prop224 uses a global authorization-key to ensure that descriptors are only read by authorized clients. However, since that key is global, if we ever want to revoke a single client we need to change the keys for all clients. The current rend-spec.txt does not suffer from this issue, hence I adapted the current technique to prop224. Please see my torspec branch `prop224_client_auth` for the proposed changes: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_au… Some further questions here: i) Should we fake the client-auth-desc-key blob in case client authorization is not enabled? Otherwise, we leak to the HSDir whether client auth is enabled. The drawback here is the desc size increase (by about 330 bytes). Alternatively, we can try to put it in the encrypted part of the descriptor. So that we require subcredential knowledge to access the encrypted part, and then client_auth_cookie knowledge to get the encryption key to decrypt the intro points etc. I feel that this double-encryption design might be too annoying to implement, but perhaps it's worth it? ii) Should we use the descriptor ASCII format to encode all the client-auth-desc-key data? Or is that weird binary format OK? iii) Should we use a fresh IV for each ENCRYPTED_DESC_COOKIE? rend-spec.txt does not do that, and IIUC that's OK because it uses a fresh key for every encryption (even though the plaintext and IV is the same). b) Do we want a NACK from the HS for when client authorization fails? Currently the only way for a client to learn that they are not authorized (or that their keys changed or got revoked) is that they never complete the rendezvous. To achieve that we would need a whole new cell (INTRODUCE_SERVICE_NACK) from the hidden service all the way to the client. Worth it? c) Another suggestion here by special, is to introduce an additional layer of access control at the HSDir request level, such that HSDirs don't even serve descriptors to clients that do not prove knowledge of a pre-shared fetch key. This way unauthorized clients cannot even learn presense information of hidden services. This might be quite useful for applications like Ricochet, who want to hide their presense from revoked clients. Of course this assumes that the HSDir is honest and will honor the fetch key protocol. However, even if the HSDir is dishonest we are just back to the current security level. We started sketching out a solution in the bottom of these notes: https://people.torproject.org/~asn/hs_notes/client_auth.jpg but the solution is not trivial to implement and we are not sure whether it's worth complicating the protocol further (e.g. we need to design a way for apps like Ricochet to get access to the fetch key). d) It might be worthwhile padding the encrypted part of INTRODUCE1 to obscure whether client authorization is in place. As you can see I have mainly worked on point (a) which I consider the most urgent. I welcome feedback on all points, so that we move forward with the design here. Thanks :)

5 14