Re: [tor-dev] TOR C# application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I don't know if it's possible to use Tor as a library, but there are a few Java apps that communicate over Tor by launching a Tor process and using it as a SOCKS proxy. Does that sound like what you're aiming to do? Here's a quick rundown of what you need to do: 1. Compile tor.exe from source, or copy it from the latest Tor Browser Bundle (your app won't need to execute the Tor Browser). 2. Launch tor.exe from within your app, using command-line arguments to pass the location of the config file and the PID of the controlling process (i.e. your app). The complete command will look something like this: /path/to/tor.exe -f /path/to/config __OwningControllerProcess pid 3. Control tor.exe via the local control port using the Tor control protocol. There's a Java library that implements this protocol, but I don't know of a C# library, so you may need to write your own using the Java library as guidance. You can set the control port in the config file so it doesn't conflict with the Tor Browser. You should use the AUTHENTICATE command to prevent other apps from accessing the control port, and the TAKEOWNERSHIP command to ensure tor.exe exits when your app exits. https://gitweb.torproject.org/torspec.git/plain/control-spec.txt https://github.com/guardianproject/jtorctl 4. Communicate over Tor by connecting to the local SOCKS port. You can set this port in the config file so it doesn't conflict with the Tor Browser. Here's some Java source code that may be useful for guidance: https://code.briarproject.org/akwizgran/briar/blob/master/briar-android/src/org/briarproject/plugins/tor/TorPlugin.java https://github.com/Psiphon-Labs/ploggy/blob/master/AndroidApp/src/ca/psiphon/ploggy/TorWrapper.java https://github.com/thaliproject/Tor_Onion_Proxy_Library All of the above are based on Orbot by the Guardian Project: https://gitweb.torproject.org/orbot.git Cheers, Michael On 15/12/14 15:51, Hollow Quincy wrote: Hi all, I would like to write a C# application (IRC client) that is using TOR. I read a lot, but I still don't know how can I run TOR proxy in transparent way (from my c# code). I see that Tor Stem (https://stem.torproject.org/) can be used by Python code or there are packages for Linux, but not C# (.NET). How can I run Tor proxy from C# ? Is there a library (dll) that I can run ? (without need to have open Tor Bundle browser). Thanks for help ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUkT6TAAoJEBEET9GfxSfMKg0H/2K7bfcQEEBjo5LMmObNNNW5 3VjFNOsCSoAL/ZxYqwKWa94UArFDA3GS1ucVDlxMdNWFDU2slNLKZfZ2CZhhFX7P 3zAYAbEGDfHJ4u38UPUAay9ND8pLEo/81BrJm2dZDgrB32pcojFIWfIfIgKxbE1J +XuGz+DHMSWb/foOQzp9fozzPzWkAYjlauqHB/1SK3eVuvc8jn5pB3gKwEKs8WKF YaOCEh4dVtw/WUQZPEoah44aT7UXsz62snBAPPVq0KYTs4aqQrSyK4aglmq6x632 /9/Okl4OjOmhkApnQQAunrfiBAyB1o6kA0ESfRb13hHgP8nLsoBL2TNBbF+Wt4s= =DI+O -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Suggestions for Projects
If you're into android Orbot always comes to mind. On Tuesday, December 16, 2014, Abhiram Chintangal abhiram.chintan...@gmail.com wrote: Hello, I am a student and I am thinking of getting myself more involved in the tor project over the winter break. Previously, I worked briefly on the tor-weather rewrite project which eventually turned into an gsoc project in March 2014. Are there any projects that are in need of a volunteer? I am well versed in C, Python and Java (Android). Cheers! -- Abhiram Chintangal ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] basket: More eggs in the Guard basket.
On Tue, Dec 16, 2014 at 9:53 AM, Yawning Angel yawn...@schwanenlied.me wrote: Hi all, For several reasons I've been working on a bit of code that I named basket. It's almost at the point where the brave members of the general public should be aware that it exists as a potential option in the privacy toolbox, though using it in any capacity beyond testing on a loopback device IS CURRENTLY ACTIVELY DISCOURAGED unless users are comfortable debugging it (This means, DO NOT USE IT. I will likely break backward compatibility in the future, and you will be sad.). basket is my stab at designing something that significantly increases Tor's resistance to upcoming/future attacks, by providing a link layer cryptographic handshake that uses post-quantum cryptographic primitives and defenses against website fingerprinting (and possibly e2e correlation) attacks. For the ease of development it is in the form of a pluggable transport with the expected tradeoffs (you must absolutely trust your Bridge, since both features only run to the Bridge). It is worth noting that it is anything but subtle, and it is blatantly obvious that a given connection is speaking basket as no attempt was made to obfuscate the handshake. The link layer handshake works roughly like thus: Setup: * Bob generates a long term SPHINCS256 keypair s,S used to sign responses. The handshake: 1. Alice generates a Curve25519 keypair x,X and a NTRUEncrypt EES1171EP1 keypair n,N. 2. Alice sends X | N to Bob. 3. Bob generates a Curve25519 keypair y,Y, and calculates Curve25519(y,X) as the shared secret. 4. Bob sends NTRUEncrypt(N,Y) | S | SPHINCS256(s, ntru_ciphertext | S) to Alice. 5. Alice verifies the SPHINCS256 signature (Alice's copy of S is saved/trusted in a Trust-On-First-Use manner), and decrypts the NTRU ciphertext to obtain Y. 6. Alice calculates Curve25519(x,Y) as the shared secret. NB: Some details omitted for brevity. Should the handshake also a signature by Bob of (X|N), and should maybe the shared secret also include a digest of all the other parts of the communication? -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Internet-wide scanning for bridges
Hi there, On 14 Dec 2014, at 20:06, Vlad Tsyrklevich v...@tsyrklevich.net wrote: I'm not against keeping some around, but this warning is unlikely to turn around the thousands that currently match this configuration--hopefully it'll just encourage future bridge operators to use a 'safer' configuration. The obfs4proxy README shows users how to set-up obfs4 running over port 443 which is probably the most desirable option: those users can evade network restrictions without enabling discovery by scanning. I really dislike warnings unless we absolutely need to have them, and this imo is in the category of change the default, update the docs, especially because just changing the port is not a real solution in my book. Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Internet-wide scanning for bridges
I totally agree with you, the ideal solution is for bridges to be security to by default: Either by getting rid of the ORPort for bridges and requiring the use of PTs, or changing the behavior of 'auto' for ports and having ORPort be set to auto by default. However, these changes don't appear trivial to me. I do plan to also update the documentation to use 'ORPort auto' for bridges, but I think it's also useful to nudge bridge operators to a safer configuration in the short term (the same way tor already does for HS+relay colocation and a couple of other cases.) On Wed Dec 17 2014 at 11:12:01 AM Sebastian Hahn sebast...@torproject.org wrote: Hi there, On 14 Dec 2014, at 20:06, Vlad Tsyrklevich v...@tsyrklevich.net wrote: I'm not against keeping some around, but this warning is unlikely to turn around the thousands that currently match this configuration--hopefully it'll just encourage future bridge operators to use a 'safer' configuration. The obfs4proxy README shows users how to set-up obfs4 running over port 443 which is probably the most desirable option: those users can evade network restrictions without enabling discovery by scanning. I really dislike warnings unless we absolutely need to have them, and this imo is in the category of change the default, update the docs, especially because just changing the port is not a real solution in my book. Cheers Sebastian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] basket: More eggs in the Guard basket.
On Wed, 17 Dec 2014 13:51:02 -0500 Nick Mathewson ni...@alum.mit.edu wrote: [snipity] Should the handshake also a signature by Bob of (X|N), and should maybe the shared secret also include a digest of all the other parts of the communication? Hmm, maybe I shouldn't have left bits out, and I really do need to document the handshake component of the protocol. The former is actually done, a BLAKE-256 digest of the entire client request is included in Bob's response and is covered by the signature. The client verifies that Bob received a unmodified request, after checking the signature. There's no reason why the signature can't just include the entire request here if that's better. Including a digest of everything sent as part of the shared secret seems like a good idea, so I shall revise the protocol to do that (digesting 50 KiB of data isn't that big of a deal given how heavyweight the other crypto bits are). Regards, -- Yawning Angel pgpI20qKE8Gnl.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Hidden service performance
Hello tor-dev, This email is to detail the work being done on a framework to do performance measurements for hidden service. I'm looking to get some feedback on the whole idea, improvement and help on possible analysis. If this work is not thrown out the window, I'll definitely do a Wiki page for a detail documentation but for now this is still a bit too early I think. *** PLEASE NOTE THAT THIS FRAMEWORK IS _NOT_ INTENDED TO BE USED ON THE REAL TOR NETWORK, ONLY TEST NETWORK! *** (I'll even add a check to make sure TestingTorNetwork is set to 1 else tor should not run.) The whole idea of this effort is to have a way to do very precise measurements of hidden service so we can come up with a performance baseline and have a reliable way to measure our progress on improving HS. We want to run this on large private network such as Shadow in order to get a better understanding of this whole HS subsystem. Finally, this can be extended to all sorts of component in tor in the future to help us analyze the beast that tor has become. :) This work uses tracing[0] for measurements. For that, I've instrumented the Tor code base with tracepoints that allows us to hook a tracer to those so we can collect data and do analysis afterward. The following branch contains a bunch of tracepoints mostly for HS and uses the LTTng[1] user space tracer. It's based on tor 0.2.5 version because we wanted to measure regression or improvement between 0.2.5 and upcoming 0.2.6 (especially with Andrea's new scheduler work). https://gitweb.torproject.org/user/dgoulet/tor.git [branch: hs-lttng-025] To compile this branch you need to install lttng-ust (tracer). It's pretty easy to install, you can find out how here[2]. (You will need version 2.4.0 or above). ./configure --enable-lttng-tracing In src/or/trace/events.h, you can find all tracepoints that have been added with the data they collect. It is a bit too tidious to explain them all to you in this email but every tor_trace_* line is a tracepoint that you can grep in the code to see their location thus have a clearer picture of what they record. First, if you see any tracepoints that record something but are not at the right place in the code, you should definitely let me know. Second, telling me where tracepoint should be added also is very useful! No need to understand the full tracing system, just that function should have a tracepoint to record this, I'll do the rest. Now to use tracing with Tor and analyze the data, you can find useful information and examples in this repository. (Pretty sure it's missing some documentation so please point it out!) https://gitorious.org/tor-hs-stats/tor-hs-stats Here are examples of graph that we can do with the collected data from the traces. (Introcuction Points Ready Time) https://people.torproject.org/~dgoulet/hs/ip-025.png or (Rendezvous Point Ready Time) https://people.torproject.org/~dgoulet/hs/rp-025.png Now to make analysis, I've build what is called in the tracing world a state system. See that as a way to represent different objects in an application that are populated by the data that has been collected with tracing (trace). For this, please take a look at lttng-analyze.py in the gitorious repository. That script parses the trace event by event (event is what a tracepoint generated), populates the state system which is analyzed after the trace is fully parsed. It's pretty straight forward and here is the power of the state system. Once build from a trace, we can run *ALL* sorts of analysis on it to measure timings, find bad behaviors, etc.. If that interests you, I encourage you to play with all this and see for yourself what can be achieved thus opening your eyes on the possibilities. :) Ok, so there is a lot to explain to make things clear. I'm pretty sure I'm forgetting some here. Understanding the benifits of tracing is not that trivial at first glance so I'll be really happy to explain it to anyone asking. Any feedback is positive feedback! I'm happy to answer any questions. I'll most probably follow up this with a post about some results at some point. Cheers! David [0] https://en.wikipedia.org/wiki/Tracing_%28software%29 [1] https://lttng.org [2] https://lttng.org/download/ signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Internet-wide scanning for bridges
On Fri, Dec 12, 2014 at 04:33:05PM -0800, Vlad Tsyrklevich wrote: Hello, while taking a looking at TorCloud I it used static OR and obfs2+obfs3 ports making them trivial to discover by scanning EC2's IP address space. This led me to consider the more general attack of internet-wide scanning to discover Tor bridges. Most Tor relays run their ORPorts on port 443 or 9001 so I began investigating there. I began by looking at Project Sonar's port 443 SSL certificate database looking for certificates matching the tor certificate pattern. In talking with Eric Wustrow about ZMap, I discovered that he and the other ZMap authors had already published about this attack in their original paper. Eric mentioned that in his discussion with Roger that the response to the attack was going to be the soon-to-be-deployed obfuscated transports which were intended to be run on random high ports; however, the eventual roll out of obfsproxy did not change the fact that bridge's ORPorts continue to be publicly accessible. While I was analyzing Internet-wide survey-data for port 443 and 9001 (helpfully provided by Project Sonar/H D Moore) I found the Onionoo data set. I was able to quantify the impact of the attack using the Onionoo data and verify it using the ZMap scans. There are 4267 bridges, of them 1819 serve their ORPort on port 443 and 383 serve on port 9001. That's 52% of tor bridges. There are 1926 pluggable-transports enabled bridges, 316 with ORPort 443 and 33 with ORPort 9001. That's 18% of Tor bridges. 203 (64%) of PT-enabled bridges with ORPort 443 were TorCloud. I was able to approximately verify these figures using the Internet-wide scans. By grabbing bridge's certificates and calculating their hashed fingerprint I realized I was also discovering a fair amount of private bridges not included in the Onionoo data set. Eliminating the ORPort entirely for PT-enabled bridges seems like the ultimate solution to this attack, but the implications of such a change are unclear to me. Another change to mitigate this issue is changing the behavior of ports specified as 'auto' and then changing defaults and documentation to use auto by default. Currently specifying 'auto' in your torrc lets the OS decide the port; however, if tor were to generate a random port on first use that it continued to use across restarts it would it possible to use this for ORPorts and pluggable transports by default (as opposed to the current situation where for bridges you want ORPort auto but constant PT ports and a constant ORPort for relays which is confusing.) Thanks, these are great results. You're right that disabling the ORPort for PT bridges is the right solution. There are some technical obstacles summarized in this ticket: Obfsbridges should be able to 'disable' their ORPort https://trac.torproject.org/projects/tor/ticket/7349 Basically, whatever tests bridges for reachability is ignorant of PTs, so it only tries connecting to the ORPort. Since the bridge appears unreachable, it doesn't go into BridgeDB to be handed out. So there are a few different tasks that need to be unraveled to make it possible. The reachability testing also caused problems for us with obfs2/obfs3. People would set up an obfsbridge, and obfsproxy would pick a random port to listen on, and people didn't know that and so didn't open the port on their firewall. There were a lot of bridges with a reachable ORPort but unreacable obfsport. Because the ORPort was reachable, they were in BridgeDB, even though they were useless as PT bridges. Having an easily findable ORPort definitely makes it easier for those censors that do proactive or reactive scanning to find bridges. (Only the GFW does reactive scanning as far as I know, and I haven't seen evidence for or against proactive scanning like you did.) Even if the ORPort is hidden on some random port, it still gives the censor a good distinguisher for, say, suspected obfs3 streams: When you see something that might be obfs3, scan all the other ports on the IP and see if you find an ORPort. Bridges that are easy to scan for aren't totally useless, because they still work in places where the censor isn't as sophisticated---like the default Tor Browser bridges, which are easily blockable because their addresses are hardcoded in the source code, but for whatever reason aren't blocked in many places that censor vanilla Tor. I wouldn't say that it's always a mistake for a bridge to be running on 443. Sometimes you need it to get through a firewall. And then it depends on the censor's capabilities, whether you want vanilla Tor on 443 or obfs3 on 443. Vanilla Tor is fingerprintable as Tor, but it is at least TLS; while obfs3 doesn't look like Tor but doesn't look like TLS either. One configuration might get past a censor that blacklists Tor; the other might get past one that whitelists TLS. But I think you're right, that a lot more people are exposing
Re: [tor-dev] Suggestions for Projects
Are there any projects that are in need of a volunteer? I am well versed in C, Python and Java (Android). Go here and pick random interesting tickets to complete... https://trac.torproject.org/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
