[tor-dev] [tor-talk] Exit Node Scanning Status

AntiTree antitree at gmail.com
Sun Feb 3 04:56:10 UTC 2013

I've gone through SOAT and my life is changed because of it. It's a
massive file that would take a long time to properly grok but much
respect to Mike, your mind is a wonderful tool of destruction.

Question, probably for Mike, where is the latest version? I'm looking
at the one packed into Torflow right now but there was also discussion
about a v0.0.3 with a metacontroller of some kind? Just want to make
sure I'm playing with the right code.

These are the current list of tests from SOAT (correct me if I missed
one) and what I'm considering as a feature list.
- DNS Rebinding
- Cookies
- JavaScript
- Exit Port Consistency (do they only have cleartext services open)
- Verify relays can extend to other relays. e.g. if a relay can extend
to relays running on ports 80 and 443, then it's a bad relay.

My plan is still to test the waters with detecting SSL stripping, SSL
cert manipulations, and HTTP mucking using STEM and make decisions
from there.


On Thu, Jan 31, 2013 at 4:25 PM, Mike Perry <mikeperry at torproject.org> wrote:
> 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
>> better.
> 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 :).
> --
> Mike Perry
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

More information about the tor-dev mailing list