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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev