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:
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.
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?
I think that torsocks shouldn't break your use of ssh - it closely matches many other uses of ssh or similar programs.
All the best, Jacob
On 3/4/14, Lunar lunar@torproject.org wrote:
David Goulet:
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.
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:
David Goulet:
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.
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?
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,
On 04 Mar (08:36:13), Nick Mathewson wrote:
On Mar 4, 2014 4:26 AM, "Lunar" lunar@torproject.org wrote:
David Goulet:
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.
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?
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.
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
Yrs,
Nick
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Tue, Mar 4, 2014 at 10:13 AM, David Goulet dgoulet@ev0ke.net wrote:
On 04 Mar (08:36:13), Nick Mathewson wrote:
On Mar 4, 2014 4:26 AM, "Lunar" lunar@torproject.org wrote:
David Goulet:
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.
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?
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.
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.
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?)
On 04 Mar (10:30:40), Nick Mathewson wrote:
On Tue, Mar 4, 2014 at 10:13 AM, David Goulet dgoulet@ev0ke.net wrote:
On 04 Mar (08:36:13), Nick Mathewson wrote:
On Mar 4, 2014 4:26 AM, "Lunar" lunar@torproject.org wrote:
David Goulet:
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.
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?
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.
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.
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?)
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
-- Nick _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 04 Mar (10:46:06), David Goulet wrote:
On 04 Mar (10:30:40), Nick Mathewson wrote:
On Tue, Mar 4, 2014 at 10:13 AM, David Goulet dgoulet@ev0ke.net wrote:
On 04 Mar (08:36:13), Nick Mathewson wrote:
On Mar 4, 2014 4:26 AM, "Lunar" lunar@torproject.org wrote:
David Goulet:
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.
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?
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.
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.
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?)
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.
I just pushed this feature that adds "AllowInbound 0|1" option. Also by default now the Unix socket and localhost are allowed.
Again, time for testing and review!
Thanks! David
Thanks! David
-- Nick _______________________________________________ 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
-
David Goulet -
Jacob Appelbaum -
Lunar -
Nick Mathewson -
Nick Mathewson