Re: Rogue exit nodes - checking?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 - -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Sat, Jun 19, 2010 at 10:20:19PM +0100, Matthew wrote: I am curious to know if there is a way of identifying bad exit nodes? Do people who are more technical than me (not hard!) somehow search for exit nodes with interesting configurations? Or, unless you use StrictExitNodes and are confident of the honesty of the operator, are you simply hoping the exit node owner is benign? In addition to Marek's scanner (which I'd be very interested in hearing more about ;)) there's also the SoaT Exit Scanner which Mike Perry wrote. It compares the results of queries made across Tor to those made over a direct connection to look for things like SSL certificate tampering and HTTP header or content modification. It also checks for suspicious exit policies such as allowing insecure protocols like POP and IMAP, but not allowing the corresponding secure protocol (POPS/IMAPS). There's a nice overview of its capabilities in Mike's Tor Network Analysis paper [0]. The scanner occasionally finds interesting things, but it's not seeing a lot of use at the moment as it's a bit of a chore to wade through the false positives. I'm working on improving it as part of Google Summer of Code, so if you're really interested, I post occasional updates on my progress with it at [1], and hopefully by the end of the summer things will have have progressed enough for the scanner to see more active use. [0] http://fscked.org/talks/TorFlow-HotPETS-final.pdf [1] http://anomos.info/~john/gsoc - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkweis8ACgkQke2DTaHTnQmwUACgn2SzALUfDJWEugnu/I2hm/2u ArcAmwQ6XQ/XrQMOMNh6g052VDjNAOvT =dv8M - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkweixEACgkQke2DTaHTnQnnswCghF390y5dUOv/qyn4qRX3XgsE yjIAn2/xiG4dtBmTvuobOvU8/dV/yYPU =C4RN -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Rogue exit nodes - checking?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 - -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Sun, Jun 20, 2010 at 11:58:45PM +0200, slush wrote: [snip] There are two ways how to fight attackers: a) Opensource scanner and beat them by spending months on scanner improvements. b) Leave scanner closed and piss them up (my way) I think you and Anders are both oversimplifying the situation. An attacker may be able to determine the profile for a normal Tor user, and they may determine the profile for an exit scanner - but our job in designing any scanner (open or closed source) is to make the task of delineating between the two as difficult as possible. As I'm sure you're aware, we can actually quantify how difficult such a task is using information theoretic techniques, and so we may develop an objective measure for comparing scanners which is entirely independent of their being open or closed source. That said, SoaT also has a closed source component, specifically the configuration file we actually use when running it. Withholding this information makes an attackers job somewhat harder, so there is something to be said for not revealing your hand too soon. I think your irony isn't outright. Trust me I didn't spend almost year of my life on bullshit. John: I know SoaT quite well, I originally consider to improve it. But my attitude is quite different. SoaT checks everything else than content (as you wrote: SSL, policy etc) - and throws many false positives once content differs a bit. I'm interested just in content. Marek Marek: I for one highly doubt that you spent a year of your life on bullshit and would be very interested in reading your thesis and discussing this topic further - is it available online? SoaT does somewhat more subtle content scans than you make it out to, but I'll agree they're far from perfect, and that's why I'm spending several months of my life working to improve them :). Cheers, John - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkwen5EACgkQke2DTaHTnQlJ1gCeJllRlBoUnE7KL9laDCJbIwkc vikAoI9rtTJUunqWoUUtDVUuY/E0KjpG =K4Aw - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkwen8AACgkQke2DTaHTnQlFZwCfRmOtDdaD+ffz/ZBoNl785f7T 9qwAni5D4vJAuqjE/tAe2AuS3ZlTwQH8 =rg20 -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [GSoC] Improving Snakes on a Tor
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Sat, May 15, 2010 at 11:58:44PM -0400, Roger Dingledine wrote: On Sat, May 15, 2010 at 06:37:54PM -0700, Damian Johnson wrote: Hmmm... so we aren't interested in having a clearer definition of what makes up a bad exit? From the following I thought this is something we were interested in John looking into: On the bright side though, it's looking good that we'll be able to get a google summer of code student to revive Mike Perry's Snakes on a Tor project, and hopefully that means we will a) have some automated scans looking for really obviously broken relays, and *b) build a clearer policy about what counts as badexit and what doesn't, so we can react faster next time.* [0] Good point. I didn't mean to discourage him from working on more than one direction at once. I suspect that working on good clean tests that don't produce false positives, and setting up the infrastructure to automatically launch them and gather results, is something that can actually be clearly accomplished and finished; whereas trying to sort out the right balance between subtly not working right and still worth letting ordinary users exit from is a rat-hole that may well lead to madness plus no useful results. In short, it sounds like both are worth pursuing in parallel. :) I definitely think both can be pursued in parallel. I've set up a blog for documenting my progress, http://anomos.info/~john/gsoc, the most recent post (5/17/2010) is about the goals of SoaT, and the definition of BadExit. One thing I would really like help with is compiling a list of reasons for which nodes have been given the BadExit flag. I've collected information on seven cases where a BadExit flag was given, or suggested, but I'm sure there are others. This strikes me as something very easy he could do to both: 1. start integrating with the community more (all the gsoc students have been very quiet so far, hence I'm trying to encourage him to spark a discussion on or-talk) Had to finish up finals ;-) 2. it'll provide ideas of things that SoaT can look for later for both misconfigured and malicious exits I agree that we should try and either fix or find safe ways of using bad exits, and that using SoaT to try and protect the network from all the evils exit relays can dish at us is an arms race we'd lose. However, for many of the nastier active attacks like sslstrip I don't see why we should be waving the white flag right away. Cheers! -Damian Yep. Is there a list somewhere of what active attacks SoaT would like to defend against, and how to do each of the corresponding tests? I remember Mike originally designed SoaT to have a secret config file, so bad guys couldn't learn what the tests are. https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/README.ExitScanning https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/soat_config.py While I can see some reasons for doing it that way, that shouldn't stop us from documenting whatever we can publically. https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/data/soat/ should give us a few hints about what Mike was thinking. I'm starting to build a list of the attacks SoaT should defend against; I'm confident that we can be completely public about what those attacks are, as well as what our defenses are - although I'd like Mike's input on that. The secret config file you mention is less about obscuring which tests are being run, and more about not publishing the fingerprintable characteristics of the scanner (rates at which certain operations occur, etc). Once we have that list would be a good time to solicit opinions for what's missing from it or whether it's doing tests is a suboptimal way. Agreed. There's a partial list on the blog now, I'll take comments there for a few days and then bring the discussion back here to get an idea of the relative importance of each attack and strategies for conducting the tests. Cheers! John -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkvwxWkACgkQke2DTaHTnQkZ0gCeOTmal1sGHpnA/oYZBRF3kVUo ghQAniwE/y5O1WeA01Uk54Nkkjj99ZOE =mjBs -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[GSoC] Improving Snakes on a Tor
Hi or-talk, My name is John Schanck, I'm a third year CS student at Hampshire College, and I'll be working with Tor this summer through Google Summer of Code. First, let me say how excited I am to have this opportunity - I've been following the Tor project for several years now and can think of no better place to devote my efforts. Many thanks to those of you who read my proposal, especially Mike Perry who has graciously agreed to mentor the project, and Damian and Erinn who have also offered up some of their time. I'm going to be working on improving the Snakes on a Tor (SoaT) exit scanner. For those of you not familiar with it, SoaT aims to detect malicious, misconfigured, or heavily censored exit nodes by comparing the results of queries fetched across those exits to results obtained without Tor. It's an ambitious project, originally developed by Mike Perry and crafted into its current form by Aleksei Gorney during GSoC 2008, so my goals are modest. I'm going to begin by stabilizing the existing codebase, and then work on minimizing the number of false positives generated by the current filters. If time permits I'll also begin designing new filters to handle adversaries not yet accounted for. If you'd like to talk about the project (or just say hello), you can find me on OFTC under the nickname 'susurrusus'. Cheers, John PS. Congratulations to the other accepted students, I look forward to meeting you and hearing about your projects :). signature.asc Description: Digital signature
