- tor-dev - lists.torproject.org

MATor: A live-monitor for anonymity guarantees
by Esfandiar Mohammadi 28 Oct '14

28 Oct '14

Hi, tl;dr: we have a CCS paper coming up about a client-based live-monitor, called MATor [1], that assesses the influence of Tor's path selection to a user's anonymity. The paper is a first step towards a useful live-monitor that assesses a user's anonymity in a provable manner. We would appreciate your feedback on our approach and the direction in general. In detail, we implemented a live-monitor that computes upper bounds of the de-anonymization probability for sender, receiver, and relationship anonymity, based on Tor consensus data and the ports that the client needs. We formalized the guarantees that the live-monitor outputs in (an extension of) the AnoA framework [2] for circuit creation against passive attackers that do not control infrastructure (ASNs or IXPs). We use safe approximations in the live-monitor to be able to efficiently (a few seconds [3]) compute upper bounds for de-anonymization. At the moment the MATor monitor is a separate tool, but we are working on integrating it into the Tor client code. We envision an integration into Tor Browser Bundle. Since MATor is an ongoing project, we would appreciate your opinion about the approach in general. Best wishes, - Sebastian & Esfandiar [1] Michael Backes, Aniket Kate, Sebastian Meiser, Esfandiar Mohammad. (Nothing else) MATor(s): Monitoring the Anonymity of Tor's Path Selection. to appear in Proceedings of 21st ACM CCS, ACM, 2014. The MATor project page (containing the paper and the implementation): http://www.infsec.cs.uni-saarland.de/projects/anonymity-guarantees/mator.ht… [2] Michael Backes, Aniket Kate, Praveen Manoharan, Sebastian Meiser, and Esfandiar Mohammadi. AnoA: A Framework For Analyzing Anonymous Communication Protocols Unified Definitions and Analyses of Anonymity Properties. Proceedings of 26th IEEE CSF, pages 163-178, IEEE, 2013. The AnoA project page (containing the paper): http://www.infsec.cs.uni-saarland.de/~meiser/paper/anoa.html [3] The running time is as follows on a MacBook Air 2GHz Intel i7 with 4GB RAM: Preparation time: 3.39 seconds For sender anonymity: 0.73 seconds For recipient anonymity: 6.07 seconds For relationship anonymity: 9.10 seconds

1 0

Link protocol version
by Владимир Мартьянов 28 Oct '14

28 Oct '14

I'm trying to understand link protocol versions, but I have some problems. I requested descriptor from the root server and it contains line "protocols Link 1 2 Circuit 1". Then I connected to the node, sent VERSIONS cell and got a responce: "00 00 07 00 04 00 03 00 04". But according to that responce, the node supports link protocol v3 and v4, not v1 and v2. Could you please explain that moment?

2 4

Using Mozilla Persona for "Helping Internet services accept anonymous users"
by isis 27 Oct '14

27 Oct '14

[pre scriptum] This email particularly concerns the people on the Tor Browser team, and to those interested in progress on Roger's "A Call To Arms: Helping Internet services accept anonymous users" blog post. [0] Hello all, While setting up a Mozilla Persona Identity Provider (IdP) server for testing ways to provide a system for anonymous users to log in to websites, I discovered some serious problems [1] which, in my opinion, make Persona unusable for our case. One of these problems [2] essentially boils down to forcing us to choose between two options for real-world deployment, due to a lack of forward compatibility in the existing Mozilla Persona deployment: 1. We could deploy a version which is compatible with the legacy Persona implementation but which has privacy issues. We would need to accept that the so-called "anonymous" users of the Tor Project IdP would be sent from the website they are trying to log into (Wikipedia, for example) to https://login.persona.org, and that the latter would speak to the Tor Project IdP. There is not even remotely a chance for even pseudonymity, if we went this route, as the https://login.persona.org server could: * Log which websites a Tor user tries to log into, * Log when a Tor user tried to log into or out of any website, * Potentially link a user's pseudonyms (yes, even if we handed out blinded signatures in our credentials), * Arbitrarily decide to block all Tor users without the consent of either Wikipedia or the Tor Project IdP, * and probably a bunch of other horrible stuff. 2. We could make a version based on the so-called "native" Persona implementation within Firefox. This would result in fewer privacy issues, however it would be incompatible with all the rest of existing Persona infrastructure. Mozilla's "native" Persona implementation is already incompatible with the legacy version currently deployed on all Persona-enabled websites and IdPs today. If we decide to go this route, and create a version of Persona which does not redirect our users through third-party IdPs, we would need to try to force every website that wants to allow anonymous users to login to source custom Javascript that we make available, [3] which is specific to allowing logins from our IdP. In addition, sites which include this Javascript would no longer be compatible with the regular (non-Tor Browser) Firefox userbase and any existing Persona infrastructure (both Persona-enabled websites and other Persona IdPs). For a more verbose explanation, please see [4]. I think we can all agree that Option #1 is unacceptable. If we were to do Option #2, we would essentially be taking over maintenance of Persona from Mozilla *and* creating an entirely new, incompatible authentication system on top of the dilapidated remains. Before going that route we should pay attention to the fact that Mozilla pulled support for the project because of lack of adoption. If our goal was to save work by using Persona for this purpose, I estimate that we would be doing more work by using Persona than if we were to build something completely from scratch. [0]: https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… [1]: https://trac.torproject.org/projects/tor/ticket/12193 [2]: https://trac.torproject.org/projects/tor/ticket/12193#comment:12 [3]: https://github.com/isislovecruft/browserid-certifier/blob/master/srv/login.… [4]: https://trac.torproject.org/projects/tor/ticket/12193#comment:13 -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Understanding Tor and SOCKS
by spriver 27 Oct '14

27 Oct '14

Hi everyone! I am trying to understand the communication between an application and Tor (especially connecting to a hidden service). I am tracing packets on loopback between a torified netcat request to connect to a .onion address. When the connection gets granted I am getting a response from the socks server: (hex data of the tcp payload) 0x05 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Regarding to the SOCKS specification this means that the request is granted. But I don't understand the 0x01 in byte no 4. It means IPv4 address in the SOCKS specification, but the following part of the destination address and port (the following 0x00's) are empty. So what does that 0x01 mean? Can someone explain me that? Thank you! Cheers, spriver

4 5

Vidalia Relay Bundle(win) Tor version, obfs4proxy package in deb.tp.o
by s7r 26 Oct '14

26 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. I have noticed that the Vidalia Relay Bundles for Windows available to download on torproject.org are using Tor 0.2.4.23, while we are on 0.2.5.10 as stable branch. I know 0.2.4.23 is still on the recommended list in the consensus, but since someone is downloading the bundles fresh from the Tor home page, I think it is expected to include the latest stable Tor version. 2. Configured some obfs4 bridges using obfs4proxy. They work very good, however it's a little bit complicated since package obfs4proxy exists in Debian sid, but not in deb.torproject.org, so you have to add sid repo to sources.list, install obfs4proxy and then make sure you edit apt preferences or comment the sid repo from the list in order not to upgrade you entire Debian system with packages from unstable/testing branch. Received couple of emails from users wanted to deploy obfs4 bridges and were confused. Is it possible to include obfs4proxy in deb.torproject.org for Debian, and while at it also make a rpm package for RHEL/CentOS? obfsproxy (python based pluggable transport) was easy to install in RHEL/CentOS using EPEL repo and `pip` but obfs4proxy should come as a rpm from deb.torproject.org. 3. Last thing, the page https://bridges.torproject.org/ does not contain obfs4 in the drop-down list where the user needs to select the pluggable transport. It only allows requests for obfs2, obfs3, scramblesuit and fteproxy bridges. Don't know about fteproxy, but shouldn't obfs2 be deprecated or is it still working/used? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUTRBeAAoJEIN/pSyBJlsR2zwH/2mnA2GNomxNQZI7Eeumt1sM uA6iXvlUiILJdQRG8EcHx8sfHU5MD20V5mOH774XsX7elAG47/ePL+/SKL69OfuR nl/X4IzH34CaqbMLGVHotl9Bcugfgw71fAF+Gm5nymM8VRxsdQnS51nnz7pwphon /DeeMfCE45eCYpVYyOqXZcSM4DA6Hr5bWG5TlCVJXTOl67fMr/pEBFgfpc6RIAL/ 8GXk+Cv6k/vW0AsEb/XoHBNbIzfHhOlb9O9q3giq3kGmJahMheKKLVOP5FNiEWi1 S6AhlxOYNnoAc9jhSAmNsMmJCteVVBV96c9jgeP9QOF2WtLnq6md8/uFocOelUc= =iUXk -----END PGP SIGNATURE-----

3 4

Request to expunge project 'torsocks' on Google Code
by Virgil Griffith 26 Oct '14

26 Oct '14

Sitting with David Goulet, it's problematic that when I search for "torsocks" I get the old Google Code page instead of the up-to-date page on http://gitweb.torproject.org This is problematic because people report bugs to the Google Code repository instead of the torproject repository. Jake/Robert: You are the project owners on Google Code. Could you please remove the project? Much love, -Virgil

6 8

tor-fw-helper redux
by Yawning Angel 26 Oct '14

26 Oct '14

Hello, "You are in a maze of twisty little firmwares, all terrible". I'm at the point where the new and improved firewall helper could use some additional testing by various users, though there's some issues with the design that still need to be resolved. But not being one to keep issues inherited from the original from stopping progress... Code: https://github.com/yawning/go-fw-helper Bug: https://trac.torproject.org/projects/tor/ticket/13338 Yes, it's another Go app. It should work both as a helper for tor (PortForwardingHelper in the torrc), and for flashproxy. I am currently only concerned about the latter use case since it will immediately make flashproxy more useful in various environments, and I'm not sure people that can't setup port forwarding should be running relays in the first place. How to test it: $ go build github.com/yawning/go-fw-helper One of: * Play with it by hand. "-h" dumps usage. * Edit the torrc-defaults file shipped with Tor Browser to have flashproxy use the helper. On the Linux bundle the file in question is located at tor-browser_en-US/Browser/TorBrowser/Data/Tor The flashproxy ClientTransportPlugin line should look something like: ClientTransportPlugin flashproxy exec ./TorBrowser/Tor/PluggableTransports/flashproxy-client --port-forwarding-helper=/path/to/go-fw-helper --register :0 :9000 You *can* edit where it says "9000" to use a different port, but having it auto assigned will lead to it being harder to remove when done. * Try running a tor relay using PortForwardingHelper. I personally don't recommend this, and haven't tested it at all, but there's no reason why it won't work unless the tor side of the code rotted (unlikely?). Caveats: * Not sure which version of the Go compiler/runtime this requires. Development was done on 1.3.3. It probably requires 1.2.x but it may work on older versions (Not a bug/WONTFIX). * UPnP discovery requires being able to listen on a UDP traffic and accept incoming packets. Your local firewall may prevent this. (Not a bug/WONTFIX). * flashproxy does not know how to deal with mappings expiring, so things will stop working after 2 hours if NAT-PMP is used. * Neither flashproxy nor tor know how to use go-fw-helper to delete mappings, because tor-fw-helper did not have such a thing. WARNING: If UPnP is used as the protocol, mappings are indefinite. You will need to use the router's admin interface or "go-fw-helper -d" to remove it. Yes, there is a very good reason why this is like this, despite the protocol on paper having the length as a registration time parameter. Note: NAT-PMP mappings obtained by go-fw-helper last for 2 hours. * go-fw-helper's "-T" option doesn't do everything tor-fw-helper's does. (Meh?) * The UPnP mapping description is hard coded to "Tor relay" to match tor-fw-helper. Useful extensions over tor-fw-helper: Dump all current mappings with: $ go-fw-helper -l Remove mappings with: $ go-fw-helper -d ([<external port>]:<internal port>] Both of those options only work with UPnP because NAT-PMP does not have a method of querying mapping information, and because at least one NAT-PMP implementation deployed on a lot of routers does not handle removal correctly (Bug reported to maintainer, and fixed in master but people do not update router firmware enough. There is a way to force go-fw-helper to let you delete port forwarding entries, but it's intentionally undocumented, because I don't want to support it.) Force a certain protocol (Case sensitive): $ go-fw-helper --protocol=NAT-PMP ... $ go-fw-helper --protocol=UPnP ... Tested on: * 64 bit Linux * 64 bit FreeBSD 9.3 * 32 bit Windows 7 Need testing on: * Darwin (esp with NAT-PMP) * With more routers than the 2 I have immediate access to. If something breaks "-v" gets you debug output. Questions, Comments, Feedback appreciated, -- Yawning Angel

2 2

repo: TLS vs. GPG signed files (#12871)
by Nusenu 24 Oct '14

24 Oct '14

Hi Ondrej, [I felt it is better to discuss this via email if you feel otherwise feel free to move the discussion back to trac.] even though it was also me requesting the use of HTTPS for the repos [1] - and I'm glad it has been (partially) accepted and implemented I do not follow your comment that HTTPS is "better" than repo_gpgcheck [2]. It is my opinion that even in the case of HTTPS GPG signatures provide a security improvement since (I hope) the private GPG key used to sign the repo is less exposed than the wildcard certificate for *.tpo. (I filed #13553 [4] to address rogue CAs / certificate pinning for yum.) Could you elaborate on your issue regarding repo_gpgcheck not showing fingerprints? (It does show the gpg key fingerprint on a fc20 system after adding repo_gpgcheck=1 and running 'yum update' [3]). thanks for providing and maintaining the RPM repo, Nusenu [1] https://trac.torproject.org/projects/tor/ticket/12897 [2] https://trac.torproject.org/projects/tor/ticket/12871#comment:8 [3] Importing GPG key 0x5AC001F1: Userid : "torproject.org RPM signing key" Fingerprint: 3b9e eeb9 7b1e 827b cf0a 0d96 8af5 653c 5ac0 01f1 From : https://deb.torproject.org/torproject.org/rpm/RPM-GPG-KEY-torproject.org.asc Is this ok [y/N]: [4] https://trac.torproject.org/projects/tor/ticket/13553

2 1

Pluggable transports meeting tomorrow (16:00UTC Wednesday 22nd of October 2014)
by George Kadianakis 21 Oct '14

21 Oct '14

Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention!

1 0

Re: [tor-dev] Potential projects for SponsorR (Hidden Services)
by str4d 21 Oct '14

21 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 George Kadianakis wrote: > == Opt-in HS indexing service == > > This seems like a fun project that can be used in various ways in > the future. Of course, the feature must remain opt-in so that only > services that want to be public will surface. > > For this project, we could make some sort of 'HS authority' which > collects HS information (the HS descriptor?) from volunteering > HSes. It's unclear who will run an HS authority; maybe we can work > with ahmia so that they integrate it in their infrastructure? > > If we are more experimental, we can even build a basic petname > system using the HS authority [2]. Maybe just a "simple" NAME <-> > PUBKEY database where HSes can register themselves in a FIFO > fashion. This might cause tons of domain camping and attempts for > dirty sybil attacks, but it might develop into something useful. > Worst case we can shut it down and call the experiment done? > AFAIK, I2P has been doing something similar at > https://geti2p.net/en/docs/naming > We have been running our petname system for at least five years (probably longer), mostly without incident. The above linked page covers details of the current system; see [0] for a (slightly dated) more general discussion of the reasons behind the I2P naming system, common arguments and possible alternatives. We have also started looking at GNS as an option[1,2]. I like the concept, and the ability for users to easily control their own domain name zones, which replaces the problem of a user losing their Destination keys (.onion equivalent) down to only needing to securely maintain their zone key. But the UI/UX needs vast improvement if everyday users are to understand it, and we need to research the trade-offs carefully. I am happy to discuss this further if anyone is interested, because a combined / general approach would benefit multiple networks. str4d [0] https://geti2p.net/en/docs/discussions/naming [1] http://zzz.i2p/topics/1545 (in I2P) [2] http://trac.i2p2.de/wiki/GNS -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJURgOtAAoJEIA97kkaNHPnfUQP/RQIBUCjCQcRvDyXL5l+D0Cv yoE7JT2vr7mqQx+/4nT9w/EhuQvakS5lK8gsod3yHDErtbNa8Ot/NylDbPYvdSo0 mXYOWRtaozv/8VIrRZuFc1NLne/08RYAIrnC3A9NCbpCcvwVLMxWXdl3DzEuZ+R5 rVijvHXW2nhVKjEYFez4dtErA+qTC/nKtdlG5hG1gq4mTTbWyYPEVmUonZe7t8l6 +iVc5jG9bKS6ng1Mcvmj5XwDN2rRRk3igo+64gyk7GsHSi3IXxq2S8H+hVD16hk+ gPmS0+oX5Vy6Ww04xM+x55X3NBHbLzkb+dEMYC/gYVLZrmxeG76iAQ/vBDCJncGC 8JI+KhoCx/hQGzvIby1T2VEf8t/fyREKwDq/jmAQdraxqoA5/z5xHwgpetNRRJOM 6LuOtc3jkxe0fOrsJcvHXLQybOKE8bLrLf0jLlmOpKR60EqmFAZaXC8qbzfItvaA KBHKO9t4e1F0t96PH0qhTJjlqqJVunfHyaulC6i9/HBRIZAnjrDtxvN9oQgtyYzI TRw/uxqR0o4c3iDet472YOjLR0JDwz23OHGT66VG/xiNYN2siNpSeBoVXmpc7YuC PGqjgZJkl3EZ/AIU+2mS+lAvmouT9UmW58fIF0BD+bmsr1//zfCIxXH8/EeOZBCw sXUQa30VVMdDYCmQc8dX =HUK1 -----END PGP SIGNATURE-----

1 0