[tor-dev] MITM for TOR

[Rob van der Hoeven]

> On Fri, Sep 23, 2011 at 03:52:25PM +0200, robvanderhoeven at ziggo.nl wrote 0.5K bytes in 20 lines about:
> : I build a small Monitor In The Middle (MITM) proxy that can be used to
> : study the communication between TOR and the browser. Hope this can be
> : used to improve TOR.
> : 
> : It's small but quite powerful. Wrote an article about it on my blog:
> : 
> : http://freedomboxblog.nl/mitm-for-tor/
> 
> It seems you responded to another thread with a new subject, perhaps
> this has confused others.
> 
> How does this differ from the tamper data extension in Firefox?
> https://addons.mozilla.org/en-US/firefox/addon/tamper-data/
> 

I don't know tamper-data but i tried firebug and was not happy with it.

MITM is written for Tor, it measures Tor performance.
MITM is not a Firefox extension, it can be used with any browser.
MITM can be used at both the entry as the exit node of the Tor network.
MITM is written in Python and can (in my opinion) be easily adapted to
produce all kinds of reports. The code can be used as a base for an
automatic monitoring program.

> In either case, did you find anything in the interaction between firefox
> and the Tor socks proxy? From you blog post, it looks like Tor socks
> interaction is quick, and the performance of everything else is
> dependent on the active circuit.

First: I'm not very up-to-date with the internal workings of Tor. I hope
to learn more in the future! For the moment i think it is best to have
an unbiased view. I just want to measure what the system does.   

Some results:

If you look at the graph in my article you see multiple parallel
connections to the same webserver. Each connection has the same Socks
DNS round-trip. Why? After the first round-trip the address of the
requested server is known to Tor. For *HTTP* traffic the DNS round-trip
is in my opinion not needed. If a server cannot be resolved the exit
node can simply send an error page back to the browser (just like the
browser does if it can't resolve a name)

I noticed that some connections stay open for a long time after the last
request (several minutes are not uncommon). This is bad because
connections use up valuable resources. Ideally the Tor exit node should
not keep *HTTP* connections open for more than lets say 10 seconds. It
is very cheap to reconnect. 

Note: Both remarks are ONLY valid for HTTP traffic. As i understand it
Tor is protocol neutral at the moment?

Another observation: Sometimes the DNS part is very slow (more than 10
seconds) Is this because a new circuit is being build?

> 
> And, it's Tor, not TOR.  See
> https://www.torproject.org/docs/faq.html.en#WhyCalledTor for the
> details.

Sorry, i will correct this.

Rob van der Hoeven.
http://freedomboxblog.nl