Hello,
I've first sent this e-mail to help@rt.torproject.org and the answer was to send a copy of it to the "tor-dev mailing list". So that's what I do:
I just wanted to let you know that I've created a small new tool for Windows called InjectSOCKS that can force other Windows software to do TCP connections via SOCKS. This way software not supporting SOCKS can be used together with Tor. You don't need any additional HTTP proxy or other proxies. As an example it works for passive FTP, too. Additionally it handles the DNS requests of that other software in a way that while creating the SOCKS connection, Tor gets the textual address - so the exit node can resolve it (which is the way favored by the Tor developers). This way Tor hidden services work as well. And it works per Windows process, so it doesn't influence the whole operating system. In case you're interested in my software, I've put it on sourceforge to make it open source: http://sourceforge.net/projects/injectsocks The tool is far from being perfect yet, but I think some of the ideas are interesting.
By the way, I've also created DNS2SOCKS, which is already listed on Tor's Wiki: http://sourceforge.net/projects/dns2socks It seems like several people like it, so I hope that some people will also like InjectSOCKS.
Regards, ghostmaker
On Fri, Dec 6, 2013 at 12:59 PM, tor@herr-der-mails.de wrote:
Hello,
I've first sent this e-mail to help@rt.torproject.org and the answer was to send a copy of it to the "tor-dev mailing list". So that's what I do:
I just wanted to let you know that I've created a small new tool for Windows called InjectSOCKS that can force other Windows software to do TCP connections via SOCKS. This way software not supporting SOCKS can be used together with Tor. You don't need any additional HTTP proxy or other proxies. As an example it works for passive FTP, too. Additionally it handles the DNS requests of that other software in a way that while creating the SOCKS connection, Tor gets the textual address - so the exit node can resolve it (which is the way favored by the Tor developers). This way Tor hidden services work as well. And it works per Windows process, so it doesn't influence the whole operating system. In case you're interested in my software, I've put it on sourceforge to make it open source: http://sourceforge.net/projects/injectsocks The tool is far from being perfect yet, but I think some of the ideas are interesting.
By the way, I've also created DNS2SOCKS, which is already listed on Tor's Wiki: http://sourceforge.net/projects/dns2socks It seems like several people like it, so I hope that some people will also like InjectSOCKS.
Hi, Ghostmaker!
This sounds cool; I hope I have a chance to start looking through the code soon.
One quick question that I didn't see on the website or in the codebase -- what license are you distributing this under? Assuming that you didn't use anybody else's code to write it, you can pick any open source license that you'd like -- but without a license, people technically don't have permission to read or modify your software.
Most of Tor is under the fairly permissive 3-clause BSD license; Torsocks is under the more restrictive "GPL v2 or later"; and if you want to explicitly disclaim all rights, the CC0 public domain grant is probably the best public domain grant to use.
best wishes,
Hello Nick,
thank you very much for the fast response.
Assuming that you didn't use anybody else's code to write it, you can pick any open source license that you'd like
That's a good advice. I've set the BSD license in sourceforge for both tools now. You can see it on the summary page.
On the next updates I'll put the license text also into the ReadMe.txt files.
I have to do some more testing on InjectSOCKS with different network tools - I've mainly used the well known browsers so far for testing. On some tools it still fails (e.g. Internet Explorer only works partly) - but it's at least a proof of concept :-)
Regards, ghostmaker
Hi!
On 06 Dec (18:59:33), tor@herr-der-mails.de wrote:
Hello,
I've first sent this e-mail to help@rt.torproject.org and the answer was to send a copy of it to the "tor-dev mailing list". So that's what I do:
I just wanted to let you know that I've created a small new tool for Windows called InjectSOCKS that can force other Windows software to do TCP connections via SOCKS. This way software not supporting SOCKS can be used together with Tor. You don't need any additional HTTP proxy or other proxies. As an example it works for passive FTP, too. Additionally it handles the DNS requests of that other software in a way that while creating the SOCKS connection, Tor gets the textual address - so the exit node can resolve it (which is the way favored by the Tor developers). This way Tor hidden services work as well. And it works per Windows process, so it doesn't influence the whole operating system.
This is really great. I didn't look at the code but getting Windows support in torsocks would be awesome! Not sure yet how much work it would require but definitely having it would be amazing.
In case you're interested in my software, I've put it on sourceforge to make it open source: http://sourceforge.net/projects/injectsocks The tool is far from being perfect yet, but I think some of the ideas are interesting.
Do you think you can put your code into a git repository (github, gitourious, ...). That would be *very* helpful to review/contribute and track changes.
Thanks! David
By the way, I've also created DNS2SOCKS, which is already listed on Tor's Wiki: http://sourceforge.net/projects/dns2socks It seems like several people like it, so I hope that some people will also like InjectSOCKS.
Regards, ghostmaker _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hello David,
thank you for your reaction. I've read some information about "Torsocks" now and yes, it seems to be similar. Unfortunately the information on Torsocks's homepage is rather short. So I can't tell you if the internal technology is similar. It tells that it explicitly rejects UDP traffic. It would be possible to block UDP traffic in InjectSOCKS as well. By the way, why does Tor not support UDP via SOCKS? The Torsocks documents also say that it blocks local traffic as well. While implementing InjectsSOCKS I saw that some Windows software needs local traffic in order to work for internal inter process communication (maybe Internet Explorer - not sure anymore). So I've explicitly prevented using the SOCKS server for local traffic (wouldn't make sense) and don't reject it - otherwise this software wouldn't work anymore.
Do you think you can put your code into a git repository (github, gitourious, ...). That would be *very* helpful to review/contribute and track changes.
Unfortunately I'm not familiar with git. However, the source code is rather small. The most important parts are in InjectSOCKS_DLL.c The sources are already commented a little bit, but I think that I'll add Visual C++ XML or doxygen style documentation. This way it's easier to understand and review/analyze the code. For the moment I'd like to suggest sending me any change suggestions or questions via e-mail. If we detect that this is not manageable, we can still switch to a different solution.
By the way, I've released V1.1 of InjectSOCKS now. This adds the BSD license text and a dialog for creating a Windows shortcut file to call InjectSOCKS correctly. The dialog pops up when you start InjectSOCKS without any parameter. This helps users not familiar with the command line. Known bug: There is a small possible memory leak in the function "CreateLink" of that dialog; it will be fixed in the next release :-)
Regards, ghostmaker
Hi again,
Sorry for the delay to respond!
On 10 Dec (20:27:14), tor@herr-der-mails.de wrote:
Hello David,
thank you for your reaction. I've read some information about "Torsocks" now and yes, it seems to be similar. Unfortunately the information on Torsocks's homepage is rather short. So I can't tell you if the internal technology is similar.
Currently, an effort is still ongoing on rewriting torsocks and in code review process right now. Thus, the webpage is probably out of date big time.
It tells that it explicitly rejects UDP traffic. It would be possible to block UDP traffic in InjectSOCKS as well. By the way, why does Tor not support UDP via SOCKS?
Yes, UDP is simply not supported by Tor thus it will be rejected when opening the socket. Actually, it's not only UDP that should be blocked but *every* other protocol except TCP. For instance, there is no way to send icmp request through Tor thus we don't want that to leak.
The Torsocks documents also say that it blocks local traffic as well. While implementing InjectsSOCKS I saw that some Windows software needs local traffic in order to work for internal inter process communication (maybe Internet Explorer - not sure anymore). So I've explicitly prevented using the SOCKS server for local traffic (wouldn't make sense) and don't reject it - otherwise this software wouldn't work anymore.
This is dangerous and the reason why it's denied is that the application could easily make a DNS request for instance to a local server that will then resolve it on a remote one thus leaking.
You should really reconsider that, going locally can be fine but also really dangerous.
Do you think you can put your code into a git repository (github, gitourious, ...). That would be *very* helpful to review/contribute and track changes.
Unfortunately I'm not familiar with git. However, the source code is rather small. The most important parts are in InjectSOCKS_DLL.c The sources are already commented a little bit, but I think that I'll add Visual C++ XML or doxygen style documentation. This way it's easier to understand and review/analyze the code. For the moment I'd like to suggest sending me any change suggestions or questions via e-mail. If we detect that this is not manageable, we can still switch to a different solution.
Maybe you can use one you are familiar with? SVN, bazaar ... ? It's just that for an open source project, having it easily browsable on a public server that *anyone* can clone the latest, it helps a great deal.
Maybe it's a good time to get familiar with the most awesome tool you'll ever play with, git! :P
By the way, I've released V1.1 of InjectSOCKS now. This adds the BSD license text and a dialog for creating a Windows shortcut file to call InjectSOCKS correctly. The dialog pops up when you start InjectSOCKS without any parameter. This helps users not familiar with the command line. Known bug: There is a small possible memory leak in the function "CreateLink" of that dialog; it will be fixed in the next release :-)
I'll take a look at it and if I can find a Windows, test it. From that point on, I'll check how feasible it is to integrate what you did in the new torsocks code so we can have *nix and Windows support in the same tool, that would be quite awesome.
Cheers and thanks for this! David
Regards, ghostmaker _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hello David,
Yes, UDP is simply not supported by Tor thus it will be rejected when opening the socket. Actually, it's not only UDP that should be blocked but *every* other protocol except TCP. For instance, there is no way to send icmp request through Tor thus we don't want that to leak.
...
This is dangerous and the reason why it's denied is that the application could easily make a DNS request for instance to a local server that will then resolve it on a remote one thus leaking.
You should really reconsider that, going locally can be fine but also really dangerous.
Thanks for all the advice. I've uploaded a new version now where the default behavior is to block any other sockets than TCP sockets and to block 127.x.x.x traffic. However, there is the optional switch /a to allow this as some software just needs it, e.g. Internet Explorer uses local UDP traffic to communicate between its processes. So the user can decide per process which mode to use. The new version also has some additional tweaks and fixes.
Concerning the upper "security" feature I think that everybody using a software like InjectSOCKS should be aware that there are a lot of ways to bypass all this. You shouldn't rely on it. The goal of InjectSOCKS is to use software together with Tor (or other SOCKS servers) even if it doesn't support this. Creating a sandbox or disabling malware is not the goal of InjectSOCKS. There are other tools for that and it's a good idea to have a firewall preventing any "bad" traffic.
Well, at least it's a proof of concept that you can manipulate the process behavior using this technique :-)
I'll take a look at it and if I can find a Windows, test it.
If you just want to test it you could use the official Microsoft trial version running for 90 days or something like that.
From that point on, I'll check how feasible it is to integrate what you did in the new torsocks code so we can have *nix and Windows support in the same tool, that would be quite awesome.
This sounds very interesting. My guess is that while the tools are similar, the internals are quite different. But this is just a guess :-)
Thanks for the effort.
Cheers ghostmaker
-
David Goulet -
Nick Mathewson -
tor＠herr-der-mails.de