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

[AntiTree <antitree@xxxxxxxxx>]

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.
- HTTP
- SSL
- DNS Rebinding
- Cookies
- HTML
- JavaScript
- SSH
- POP3S
- SMTPS
- IMAPS
- 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@xxxxxxxxxxxxxx> wrote:
> Thus spake Damian Johnson (atagar@xxxxxxxxxxxxxx):
>
>> > 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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev