Actually, I might be a good fit. Feel free to ping me off-list to discuss.
Unless there's a reason that you'd like to make this private it's better to have development discussions in the open (though tor-dev@ is probably more appropriate). Imho writing a SoaT counterpart based on either stem [1] or txtorcon [2] would be a great project if you're interested in improving our bad-exit detection infrastructure.
Cheers! -Damian
[1] https://stem.torproject.org/ [2] https://txtorcon.readthedocs.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. 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)?
@
On Wed, Jan 30, 2013 at 1:47 PM, Damian Johnson atagar@torproject.org wrote:
Actually, I might be a good fit. Feel free to ping me off-list to discuss.
Unless there's a reason that you'd like to make this private it's better to have development discussions in the open (though tor-dev@ is probably more appropriate). Imho writing a SoaT counterpart based on either stem [1] or txtorcon [2] would be a great project if you're interested in improving our bad-exit detection infrastructure.
Cheers! -Damian
[1] https://stem.torproject.org/ [2] https://txtorcon.readthedocs.org/ _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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.
Cheers! -Damian
Thus spake Damian Johnson (atagar@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 :).
On 1/31/13 10:25 PM, Mike Perry wrote:
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.
I agree and additionally i think that you should use and customize OONI to run such kind of tests.
Additionally you should also setup a set of DECOY email accounts, facebook accounts, twitter accounts, etc and use them trough clear-text protocol by checking in an automated way access-log.
Fabio
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@torproject.org wrote:
Thus spake Damian Johnson (atagar@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
AntiTree -
Damian Johnson -
Fabio Pietrosanti (naif) -
Mike Perry