[tor-dev] [tor-talk] Exit Node Scanning Status
mikeperry at torproject.org
Thu Jan 31 21:25:13 UTC 2013
Thus spake Damian Johnson (atagar at torproject.org):
> > Stem seems like a good choice and something I've been meaning to get
> > back in to. I've been using the old Python library. I'd be happy to
> > work on this project and get up to speed with what Mike wrote a while
> > back.
> Great! Just let me know if you have any stem questions.
> > I've got to go through the old SOAT code, but can anyone tell me
> > a structural reason not to begin by re-implementing his original tests
> > (DNS manipulations, http traffic tampering, etc)?
> Either porting SoaT or reimplementing the same tests to initially aim
> for feature parity would be a fine place to start. I'd suggest taking
> a look at its codebase and deciding for yourself which would be
One of the problems with SoaT is that I over-engineered the tests to
try to catch lots of subtle manipulations and also filter out lots of
dynamic content, hoping to dial the detection mechanisms in later as we
saw results. Unfortunately, I became overwhelmed with other Tor tasks
and never got around to this tuning.
Roger insists it may be wiser to start simple with a fixed test server
that you control and work your way up to something as exhaustive as SoaT
later. If you don't want to be watching huge volumes of result feeds
like a hawk for the rest of your life, this might be a better plan.
Unfortunately, Roger's approach also means you're very unlikely to
actually catch anything malicious beyond script kiddies who just deploy
sslsniff/sslstrip. Fortunately, there actually are enough of those to
mean you're not wasting your time if you go this route. SoaT has caught
plenty of those whenever anyone actually kept it running long enough and
sifted through the result feeds :).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the tor-dev