Ian Goldberg: > On Wed, Jun 26, 2013 at 03:55:58PM -0400, David Goulet wrote: >> Hi everyone, >> >> For those who don't know, I've been working on a new version of Torsocks >> in the last three weeks or so. >> >> https://lists.torproject.org/pipermail/tor-dev/2013-June/004959.html >> >> I just wanted to give a quick status report on the state of the development. >> >> The DNS resolution is working for domain name (PTR) and IPv4 address. >> Currently, Tor does not support IPv6 resolution but the torsocks code >> support it. >> >> Hidden service onion address resolution is also working using a "dead IP >> range" acting as cookie that is sent back to the user and mapped to the >> .onion address on the hijacked connect(). >> >> I've changed quite a bit the configuration file (torsocks.conf) to fit >> the style of tor (torrc). At this point, the tor address and port can be >> configured as well as the "dead IP range" mention above. More is coming >> but pretty simple for now. >> >> Logging is working, connection registry and thread safety as well. There >> is also a compat layer for mutexes and once I start porting the project >> to other *nix system (BSD, OS X, ...) probably more subsystem will be >> added to that compat layer. >> >> So, in a nutshell, some libc calls still need to be implemented, *moar* >> tests and other OS supports. I'm confident to have a beta version to >> present to the community in a couple of weeks (if nothing goes wrong). >> >> Feel free to browse the code, comment on it, contribute!, etc... >> >> https://github.com/dgoulet/torsocks/tree/rewrite > > Are non-blocking sockets, select/poll/etc. (especially at connect() > time), and optimistic data on the to-do list? Yes! Good point I should have put the todo list. So yes, non block socket support. For optimistic data, it is kind of tricky. I can use it for DNS resolution without a problem because torsocks control the complete flow of data from opening a SOCKS5 connection to closing it after the DNS response is received however for actual real data (sendmsg, send, ...) a connect is needed before so it would means that a connect() call will return "yes OK socket connected" but where in fact it is not really true. So, when the first data are sent, there is a possibility that the Tor connections failed or even we block for an unknown amount of time during the send*/write() call. Now the question is, is this the kind of behavior that would be acceptable meaning basically lying to the caller at connect() and possibly blocking I/O calls and returning something like ECONNRESET or ENOTCONN if the Tor socks5 connection fails. This is *real* tricky especially with non blocking socket, if torsocks needs to do some possible blocking call for the SOCKS5 replies during an I/O call from the caller that is not suppose to block. Furthermore, having pending data that *might* come at any time on the connection from the SOCKS5 negotiation, the caller could put the file descriptor in poll() mode, wake up and try to receive the data but where in fact it's the socks5 reply... it's possible to handle that but it seems here a VERY intrusive behavior. Does optimistic data worth it here vis-a-vis the complexity of handling that it and high intrusiveness ? Cheers! David > > Thanks, > > - Ian
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev