Hi everyone! After a big code review from Nick and help from a lot of people contributing and testing, this is the release candidate 4 for the new torsocks. Hopefully this is the last stretched before pushing this effort upstream but for that we need help with code/documentation review (again) and of course more and more testing! Multiple Signed-off on the code would be great so please go at it, ask questions, contribute! and let's make this new Torsocks awesomer! :) Some pointers on critical part of the code. --> src/lib/connect.c and close.c --> src/lib/getaddrinfo.c and gethostbyname.c --> src/lib/torsocks.c Also see the configuration file that has changed. --> doc/torsocks.conf If you are on OS X or/and BSD, please help make it work on those platforms. It's quite easy to break compatibility thus help make sure we didn't break it up :). https://github.com/dgoulet/torsocks.git Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc4.tar.gz Big thanks to all! David
David Goulet:
I was about to push the new version to Debian experimental, but it just breaks my SSH configuration too badly. The new version forbids listen() and accept(). That means that at least SSH options ControlMaster, LocalForward, and DynamicForward will not work. Being able to multiplex connections (ControlMaster) is pretty crucial to keep sanity when working over hidden services. Forwarding options allow a simple way to create to tunnel TCP connections to a remote system through SSH over Tor. I am not sure what is the right move here. Perhaps allowing listen on Unix sockets and localhost? Or maybe allowing listen() entirely? -- Lunar <lunar@torproject.org>
On Mar 4, 2014 4:26 AM, "Lunar" <lunar@torproject.org> wrote:
Those sound like good candidates for options. I think that listen-local is probably safe*, but arbitrary listen is broken in enough use cases that it should IMO be off by default. *do we need to do anything about fds transferred over Unix sockets? Probably. Yrs, -- Nick
On 04 Mar (08:36:13), Nick Mathewson wrote:
I agree here that this should not break the ssh -L. What I propose is an option that allows torsocks to accept inbound connection thus listen()/accept(). An option in the configuration file and an environment variable also (which adds a command line option to torsocks as well). What about "AllowInbound" or "AllowListen" or "AcceptListen" that is off by default. Thoughts?
*do we need to do anything about fds transferred over Unix sockets? Probably.
Right now, torsocks detects that and stops everything! Since we have no way of handling that already connected socket inside the torified application, the behavior is to abort, abort and abort... Cheers! David
On Tue, Mar 4, 2014 at 10:13 AM, David Goulet <dgoulet@ev0ke.net> wrote:
AllowInbound is probably okay, though still I think that "allow inbound locally only" is a good idea. (Could we implement that by checking getsockname() on the socket before the call to listen(), to make sure that it was localhost or unix?) -- Nick
On 04 Mar (10:30:40), Nick Mathewson wrote:
I'm comfortable with that having torsocks to allow localhost binding *but* denies by default non localhost. "AllowInbound 1" would allow non localhost inbound and yes getsockname() is probably the right call to use! :) /me implementing that. Thanks! David
participants (5)
-
David Goulet -
Jacob Appelbaum -
Lunar -
Nick Mathewson -
Nick Mathewson