tortila as a bad exit

Drake Wilson drake at begriffli.ch
Tue Aug 12 09:09:13 UTC 2008


Quoth Scott Bennett <bennett at cs.niu.edu>, on 2008-08-11 23:30:20 -0500:
>      I'm not convinced.  It hasn't taken any 300 circuits for me.  It seems
> to happen every time I have a circuit that exits via tortila.  It happens
> with every destination web page.

I can confirm this.  I can't seem to find much pattern to it, though.

I've done some tests, though they're not completely rigorous.  HTTP
tests were performed with a single HTTP request of the form:

  GET / HTTP/1.1
  Host: HOSTNAME
  Connection: close

transmitted through a command line of the form:

  (printf "..."; sleep 10000) | \
    socat - socks4a:localhost:HOSTNAME.tortila.exit:80,socksport=9050 \
    > FILENAME

Pseudorandom echo tests were performed by running the program
"ditest.rb" listening on a port that was redirected via NAT from
sand.begriffli.ch:80, then using a command line of the form:

  (cat socket-send.bin; sleep 10000) | \
    socat - socks4a:localhost:sand.begriffli.ch.tortila.exit:80,socksport=9050 \
    > socket-recv2.bin

The relevant files are available at:

  http://begriffli.ch/files/2008/tortila-bogosity/

1-socket-*.bin and 2-socket-*.bin are the results of sending 1 MiB of
pseudorandom data looped through tortila through a local echo server
running on external port sand.begriffli.ch:80, with the data sent in
*-send.bin, the data received by the local echo server in *-recv1.bin,
and the data received from the local echo server after passing back
through tortila in *-recv2.bin.  There is truncation of the output
streams, but no insertions; in both cases, recv2 is a prefix of send,
and send is equivalent to recv1.  Trying the same test with looping
1-socket-send.bin through the "blockfreie" exit node yields an exact
copy of the input file at both recv1 and recv2.

e2-{1,2}.bin are the results of two tests retrieving
http://www.everything2.com/.  elreg-{1,2}.bin are the results of two
tests retrieving http://www.theregister.co.uk/.  One can clearly see
data corruption.  Retrieving the same sites via the same method using
the "blockfreie" exit node yields e2-x.bin and elreg-x.bin, with no
corruption.

The data corruption when using HTTP takes multiple forms: there are
gibberish bytes inserted that do not seem to follow any obvious
pattern; there are repeated fragments; there is truncation.

Setting up a pseudo-HTTP server at sand.begriffli.ch that ignored its
input and responded with a predetermined file containing an HTTP
response, then sending a bogus HTTP request to it through tortila, has
yielded definite corruption part of the time.  I haven't put those
files up because I think I'm out of energy for that approach for now
and I don't have very good results.

It certainly feels like buffers are being scrambled somewhere in the
part of the connection coming back from the remote server through
tortila.

   ---> Drake Wilson



More information about the tor-talk mailing list