Stegotorus now available from gitweb.torproject.org
On Mon, Jun 4, 2012 at 8:21 AM, Zack Weinberg <zackw@panix.com> wrote:
For the moment, the source tree is visible on Github: <https://github.com/zackw/stegotorus>. It is likely to move to gitweb.torproject.org hosting in the near future.
You can now clone {git,https}://git.torproject.org/stegotorus.git . Be warned that due to a couple of very large files, a clone requires approximately 350MB of disk space and 140MB transferred over the network. (The troublesome files are unlikely to change in the near future, so this is a one-time cost.) You should also assume that all documentation is out of date until further notice. Patches are welcome. The TODO list currently exists only in my head, but I'll be getting that updated in-repo Real Soon. zw
On Mon, Jun 04, 2012 at 04:09:04PM -0700, Zack Weinberg wrote:
On Mon, Jun 4, 2012 at 8:21 AM, Zack Weinberg <zackw@panix.com> wrote:
For the moment, the source tree is visible on Github: <https://github.com/zackw/stegotorus>. It is likely to move to gitweb.torproject.org hosting in the near future.
You can now clone {git,https}://git.torproject.org/stegotorus.git . Be warned that due to a couple of very large files, a clone requires approximately 350MB of disk space and 140MB transferred over the network. (The troublesome files are unlikely to change in the near future, so this is a one-time cost.) You should also assume that all documentation is out of date until further notice.
Patches are welcome. The TODO list currently exists only in my head, but I'll be getting that updated in-repo Real Soon.
I tried these steps and got a segmentation fault: $ git clone https://git.torproject.org/stegotorus.git $ cd stegotorus $ autoreconf -i $ ./configure && make $ ./stegotorus null socks 127.0.0.1:5000 [info] ./stegotorus process 28359 now initialized $ tor ClientTransportPlugin "stegotorus socks4 127.0.0.1:5000" UseBridges 1 Bridge "stegotorus 87.73.82.145:8080" I found the bridge IP address in scripts/torrc. At this point stegotorus printed out: [info] 127.0.0.1:5000: new connection to socks client from 127.0.0.1:42233 [info] <1> trying to connect to 87.73.82.145:8080 [info] <1.1> network error in read: Connection reset by peer [error] Segmentation fault at 0000000000000010 ./stegotorus[0x4054b6] /lib/x86_64-linux-gnu/libc.so.6(+0x324f0)[0x7fcff4cee4f0] ./stegotorus[0x40ec11] ./stegotorus[0x405f7a] /usr/lib/libevent-2.0.so.5(+0x1bc4a)[0x7fcff5df8c4a] /usr/lib/libevent-2.0.so.5(event_base_loop+0x414)[0x7fcff5dee254] ./stegotorus[0x404e76] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7fcff4cdaead] ./stegotorus[0x405291] Segmentation fault I noticed that the start-stegotorus.sh script uses Socks4Proxy instead of ClientTransportPlugin, but that gives me the same segfault. Here's what GDB says: [info] <1> trying to connect to 87.73.82.145:8080 [info] <1.1> network error in read: Connection reset by peer Program received signal SIGSEGV, Segmentation fault. 0x000000000040760a in conn_t::outbound (this=0x0) at src/connections.h:43 43 { return this->buffer ? bufferevent_get_output(this->buffer) : 0; } (gdb) bt #0 0x000000000040760a in conn_t::outbound (this=0x0) at src/connections.h:43 #1 0x00000000004196f9 in (anonymous namespace)::null_circuit_t::send (this=0x63fd30) at src/protocol/null.cc:202 #2 0x00000000004070aa in circuit_send (ckt=0x63fd30) at src/connections.cc:241 #3 0x000000000040b6d1 in upstream_read_cb (bev=0x63f9c0, arg=0x63fd30) at src/network.cc:303 #4 0x00007ffff7bb0c4a in ?? () from /usr/lib/libevent-2.0.so.5 #5 0x00007ffff7ba6254 in event_base_loop () from /usr/lib/libevent-2.0.so.5 #6 0x00000000004056f3 in main (argv=0x7fffffffdef8) at src/main.cc:417 I tried running the "chop" mode but didn't figure out the usage. I seems I need a "down_address" but I don't know what to put there. $ ./stegotorus chop socks 127.0.0.1:5000 [warn] chop: not enough parameters [warn] chop syntax: chop <mode> <up_address> (<down_address> [<steg>])... mode ~ server|client|socks up_address, down_address ~ host:port A steganographer is required for each down_address. The down_address list is still required in socks mode. Examples: stegotorus chop client 127.0.0.1:5000 192.168.1.99:11253 http 192.168.1.99:11254 skype stegotorus chop server 127.0.0.1:9005 192.168.1.99:11253 http 192.168.1.99:11254 skype David Fifield
On 2012-06-04 8:13 PM, David Fifield wrote:
$ git clone https://git.torproject.org/stegotorus.git $ cd stegotorus $ autoreconf -i $ ./configure&& make $ ./stegotorus null socks 127.0.0.1:5000 [info] ./stegotorus process 28359 now initialized $ tor ClientTransportPlugin "stegotorus socks4 127.0.0.1:5000" UseBridges 1 Bridge "stegotorus 87.73.82.145:8080"
I found the bridge IP address in scripts/torrc. At this point stegotorus printed out:
[info] 127.0.0.1:5000: new connection to socks client from 127.0.0.1:42233 [info]<1> trying to connect to 87.73.82.145:8080 [info]<1.1> network error in read: Connection reset by peer
[error] Segmentation fault at 0000000000000010 ./stegotorus[0x4054b6] /lib/x86_64-linux-gnu/libc.so.6(+0x324f0)[0x7fcff4cee4f0] ./stegotorus[0x40ec11] ./stegotorus[0x405f7a] /usr/lib/libevent-2.0.so.5(+0x1bc4a)[0x7fcff5df8c4a] /usr/lib/libevent-2.0.so.5(event_base_loop+0x414)[0x7fcff5dee254] ./stegotorus[0x404e76] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7fcff4cdaead] ./stegotorus[0x405291] Segmentation fault
This looks like a genuine bug - probably failure to handle ECONNRESET correctly somewhere. I'll see if I can reproduce it, but it would be helpful to me if you changed your stegotorus invocation to ./stegotorus --log-min-severity=debug \ null socks 127.0.0.1:5000 >& stegotorus.log and sent me (off-list) the log file.
I tried running the "chop" mode but didn't figure out the usage. I seems I need a "down_address" but I don't know what to put there.
In "chop" mode, the information Tor provides StegoTorus via SOCKS is insufficient to contact the remote peer correctly, so it ignores that and just does what you tell it on the command line. You would need something like ./stegotorus chop socks 127.0.0.1:5000 \ 87.73.82.145:8080 http And then 87.73.82.145 had better be running ./stegotorus chop server 127.0.0.1:9000 \ 87.73.82.145:8080 with the actual Tor bridge listening on :9000. BTW, on the server side you should only specify each listener once, but on the client side, if you duplicate each address N times that allows making N simultaneous connections. ./stegotorus chop socks 127.0.0.1:5000 \ 87.73.82.145:8080 http \ 87.73.82.145:8080 http \ 87.73.82.145:8080 http \ 87.73.82.145:8080 http That's more like a real web browser, and also will give _much_ better performance (as in "Tor won't successfully build circuits if you don't do this"). zw
On Mon, Jun 04, 2012 at 09:35:10PM -0700, Zack Weinberg wrote:
On 2012-06-04 8:13 PM, David Fifield wrote:
$ git clone https://git.torproject.org/stegotorus.git $ cd stegotorus $ autoreconf -i $ ./configure&& make $ ./stegotorus null socks 127.0.0.1:5000 [info] ./stegotorus process 28359 now initialized $ tor ClientTransportPlugin "stegotorus socks4 127.0.0.1:5000" UseBridges 1 Bridge "stegotorus 87.73.82.145:8080"
I found the bridge IP address in scripts/torrc. At this point stegotorus printed out:
[info] 127.0.0.1:5000: new connection to socks client from 127.0.0.1:42233 [info]<1> trying to connect to 87.73.82.145:8080 [info]<1.1> network error in read: Connection reset by peer
[error] Segmentation fault at 0000000000000010 ./stegotorus[0x4054b6] /lib/x86_64-linux-gnu/libc.so.6(+0x324f0)[0x7fcff4cee4f0] ./stegotorus[0x40ec11] ./stegotorus[0x405f7a] /usr/lib/libevent-2.0.so.5(+0x1bc4a)[0x7fcff5df8c4a] /usr/lib/libevent-2.0.so.5(event_base_loop+0x414)[0x7fcff5dee254] ./stegotorus[0x404e76] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7fcff4cdaead] ./stegotorus[0x405291] Segmentation fault
This looks like a genuine bug - probably failure to handle ECONNRESET correctly somewhere. I'll see if I can reproduce it, but it would be helpful to me if you changed your stegotorus invocation to
./stegotorus --log-min-severity=debug \ null socks 127.0.0.1:5000 >& stegotorus.log
and sent me (off-list) the log file.
So, I don't get the crash today, but also the bridge address is today accepting my connections. So I can actually get Tor to build a circuit and everything. This is in stegotorus-null.log.gz. I also tried against a server that sends a RST to try to simulate what happened yesterday, but it appears to be gracefully handled. That log is stegotorus-rst.log.gz. Sorry, I should have tried this again yesterday. Maybe I had a glibc version skew or something that resolved itself upon rebooting. David
participants (2)
-
David Fifield -
Zack Weinberg