On Fri, Sep 23, 2011 at 03:52:25PM +0200, robvanderhoeven@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