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 <[email protected]> wrote: > Thus spake Damian Johnson ([email protected]): > >> > 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
