Re: [GSoC] Improving Snakes on a Tor
One thing I would really like help with is compiling a list of reasons for which nodes have been given the BadExit flag. Hi John. Here's a couple more past discussions concerning bad exits: JustaNode (ssl mitm?) - http://www.mail-archive.com/or-talk@freehaven.net/msg11540.html spacecowboy (content injection?) - http://www.mail-archive.com/or-talk@freehaven.net/msg10998.html There's currently four relays marked as a bad exit according to http://torstatus.blutmagie.de *capoteATWO* Misconfiguration - http://archives.seul.org/or/relays/Apr-2010/msg00108.html http://torstatus.blutmagie.de/router_detail.php?FP=dd0f0a72a773ed5f2ea298be0dd1177560f97a9a *networkcc958ca* / *netwroke421d2a* Not really sure why... kinda weird since it's not configured to be an exit anyway (Reject */*) http://torstatus.blutmagie.de/router_detail.php?FP=7621f6493a49a4f9da13ff89ca75a08316993a31 http://torstatus.blutmagie.de/router_detail.php?FP=db0e1ce11e3ac37eb4190ffde7653eae9cbdbf20 *PrivacyNow* Misconfiguration (DNS) http://torstatus.blutmagie.de/router_detail.php?FP=cf8e39514ddd90512ebe6498ded006419b0d8f85 Cheers! -Damian On Sun, May 16, 2010 at 9:26 PM, John M. Schanck jm...@hampshire.eduwrote: -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/gsochttp://anomos.info/%7Ejohn/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,
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/
Re: [GSoC] Improving Snakes on a Tor
The way to do better at that one is to teach users and service providers about end-to-end authentication and encryption. From what I've seen I don't think there is any realistic hope for any significant number of web pages to be served with end-to-end encryption (not sure what your reference is to end-to-end authentication) in the foreseeable future. Jim I take it that you don't consider HTTPS to be end-to-end encryption then? Because I don't see why it would be unlikely for at least sensitive websites to switch to HTTPS. // pipe *** 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
Anders Andersson wrote: The way to do better at that one is to teach users and service providers about end-to-end authentication and encryption. From what I've seen I don't think there is any realistic hope for any significant number of web pages to be served with end-to-end encryption (not sure what your reference is to end-to-end authentication) in the foreseeable future. Jim I take it that you don't consider HTTPS to be end-to-end encryption then? Because I don't see why it would be unlikely for at least sensitive websites to switch to HTTPS. Of course HTTPS is end-to-end encryption! And, of course, it is already used some. We apparently have different assements of what the future holds and how quickly. Time will tell ... Cheers, Jim *** 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
On Sat, May 01, 2010 at 02:55:53PM -0700, Damian Johnson wrote: An easy place to start would be to solicit input on or-talk for a better definition and enumerable attributes we can look for. Some obvious starting ones would be ssl stripping, certificate tampering (checking for differences like the Perspectives addon [2]), and bad DNS responses. I'd imagine Scott Bennett would be glad to jump in with some more ideas. :) The balance here is between making use of imperfect exit resources that people volunteer, and keeping the content you can reach through Tor clean. If we had infinite exit relays, it would be clear that we should hunt for any differences and ban all relays that don't behave perfectly. I think John's starting point, of doing very simple tests and trying to reduce false positives, is a good way to go. The goal would be identifying exit relays that are *accidentally* broken, for example because their ISP or upstream or software AV system messes with the traffic. Detecting these can be as simple as fetching an html page with known content, and seeing if you get the right content. Then we can focus on doing tests as soon as possible when a new exit relay shows up (rather than waiting for the relay to get into the consensus, go to clients, see some use, etc), and on automating the process of getting the directory authorities to change its status. The next missing steps there are a) how to contact exit relays that are accidentally broken so they have a hope of fixing the problem, and b) how to let broken exits still be somewhat useful. These aren't problems that John needs to tackle (at least not this summer ;), but solving them will will make his work more useful. For a, it's easy if they set their ContactInfo. Problem is, many exits don't set it, or don't set it accurately. We could set a message at the directory authorities that their relay gets every time it publishes a descriptor, and then have their relay log the message (and/or tell Vidalia to pop up a message). We're on our way to supporting that approach, but we never finished all the steps. If anybody wants to pick that up, please do. For b, it could be smart to just remove certain ports from the exit policy. We can't change the exit policy in the descriptor clients get (because it's self-signed by the relay), but for example in the consensus we can say that exiting on port 80 of that relay is bad but the rest of the ports are ok. I guess how much energy we put into part b depends on how many broken relays we find, and how successful we are at part a. There is a separate arms race of detecting intentionally broken exits. But imo that isn't really an arms race we can win with SoaT. The way to do better at that one is to teach users and service providers about end-to-end authentication and encryption. Oh, and solve the fact that the whole Certificate Authority infrastructure idea is a mess. --Roger *** 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
On 05/01/10 00:15, John M. Schanck wrote: [] 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. [] GSoC is God's work; thank you! *** 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
Hi there John - glad to have you working with Tor! We're really anxious to see where you go with this project since, as exemplified by the recent incident with PrivacyNow [0], we're currently pretty miserable about noticing and flagging bad exits. Unfortunately our definition of a bad exit is pretty vague [1]: BadExit if the router is believed to be useless as an exit node (because its ISP censors it, because it is behind a restrictive proxy, or for some similar reason). An easy place to start would be to solicit input on or-talk for a better definition and enumerable attributes we can look for. Some obvious starting ones would be ssl stripping, certificate tampering (checking for differences like the Perspectives addon [2]), and bad DNS responses. I'd imagine Scott Bennett would be glad to jump in with some more ideas. :) Also, have you thought about setting up a site or blog where people can check how things are coming along? Here's what I did when doing GSoC with the SIP Communicator project: http://www.atagar.com/misc/gsocBlog/ Again, glad to have you and looking forward to working with you this summer! -Damian [0] http://archives.seul.org/or/talk/Apr-2010/msg00120.html [1] http://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=doc/spec/dir-spec.txt [2] http://www.cs.cmu.edu/~perspectives/index.html On Fri, Apr 30, 2010 at 9:15 PM, John M. Schanck jm...@hampshire.eduwrote: 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 :). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkvbquAACgkQke2DTaHTnQlItQCgkFWuzOYTTA1ctpRTaa54q5Zf kmAAnR5Z8jzMOaFErAkSXyGEdtRbXbBJ =9a6k -END PGP SIGNATURE-
[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
