Aaron, Do you know the answer or where I can find the information? a doc file perhaps?
When Tor sends out packets over the Tor network, are they always the same size? If not is there a max size? thanks On Thu, Apr 11, 2013 at 1:17 PM, Andrew F <andrewfriedman...@gmail.com>wrote: > Aaron, thanks for clarification. I thought we were talking about exit > nodes that are run by people that are sniffing data. > Sure would be nice to identify those exit nodes and deal with them. > > > On Wed, Apr 3, 2013 at 9:15 PM, Aaron <aag...@extc.org> wrote: > >> On Mon, Apr 1, 2013 at 10:01 PM, Andrew F <andrewfriedman...@gmail.com> >> wrote: >> > Why kick of bad exits? If you identify an exit that is gathering data >> or >> > manipulating data, then simply take them out of rotation and feed them >> > false connections so that they stay on line and wast resources. >> Otherwise >> > they will shut down and be back up the same day. >> >> BadExit means that relays will not pick this relay as an exit, but it >> will still be used as a non-exit relay. >> >> --Aaron >> > >> > If you can lead them on for a while it will make all tor users safer. >> > >> > >> > On Mon, Apr 1, 2013 at 8:21 PM, Aaron <aag...@extc.org> wrote: >> > >> >> On Sun, Mar 31, 2013 at 4:45 PM, Roc Admin <onionrou...@gmail.com> >> wrote: >> >> > I took another look at the OONI project. Although it's oriented >> towards >> >> > ISPs etc, isn't this almost exactly what's needed - or at least a >> start? >> >> > The tests for many of the items that Mike Perry identified in the >> spec >> >> are >> >> > already there. >> >> > >> >> > >> >> >> https://gitweb.torproject.org/ooni-probe.git/blob/16ec7a88d426b30a7bd604e97e6b5d7225b9bb91:/README.md >> >> > >> >> > Thoughts? >> >> >> >> This is a thought I've also had. There are some missing parts (namely, >> >> Tor circuit control) that don't yet exist, but intend to add in the >> >> future. There should be an OONI test template (see ooni/templates) for >> >> tests that need to interact with Tor. >> >> >> >> Some other things to address: >> >> * how are exits selected for testing? From an input file? Or Tor >> consensus? >> >> * how are the output reports formatted? What data is included? Where >> >> are they submitted? >> >> * Who runs the tool? Would it work like the current BwAuth, where a >> >> DirAuth and BwAuth operator pair up, or could anyone report BadExit? >> >> >> >> This sounds like a project needing a proposal (see tor-spec.git if >> >> you're not familiar). I'd be happy to collaborate, if anyone is >> >> interested in going this direction. >> >> >> >> --Aaron >> >> >> >> > ROC >> >> > >> >> > >> >> > On Sun, Mar 31, 2013 at 11:12 AM, Aaron <aag...@extc.org> wrote: >> >> > >> >> >> On Sat, Mar 30, 2013 at 4:18 PM, Roc Admin <onionrou...@gmail.com> >> >> wrote: >> >> >> >> Does this mean that you're planning to expand the SoaT codebase? >> >> Write >> >> >> >> a revised version? If the project is going to be revived then it >> >> would >> >> >> >> make sense for it to take advantage of one of our newer >> controller >> >> >> >> libraries... >> >> >> > >> >> >> > Yeah the plan is to do a complete rerwrite of SoaT. That guy was a >> >> >> > beast and almost did its job too well. I talked a little about >> this on >> >> >> > the tor-dev side but I'm definitely using Stem. I didn't know >> about >> >> >> > the other project though so thank you. There was also some >> discussion >> >> >> > about interfacing with Onionoo but now we're talking too far down >> the >> >> >> > line. >> >> >> > >> >> >> >> 2. Even when a bad exit *is* reported our process for flagging >> it is >> >> >> >> pretty well broken. To be flagged at least two of the three >> authority >> >> >> >> operators that vote on the BadExit flag need to take manual >> action. >> >> >> >> All three operators are highly busy people so in practice relays >> >> don't >> >> >> >> get flagged without considerable nagging. >> >> >> > >> >> >> > Exactly. I think Mike Perry's proposal that Aaron linked to is >> still >> >> >> > spot on in terms of what we want from a solution. In the >> deployment >> >> >> > section it notes three phases where the final one is an automatic >> >> >> > communication between the scanning engine and the Tor Network so >> that >> >> >> > it alerts Directory Authorities. This interface in itself requires >> >> >> > some thought. It's threat model includes accidentally causing a >> DoS on >> >> >> > all hosts on the network if something goes wrong, or >> inappropriately >> >> >> > flag a good node, or the fact that knowing how to tool works, a >> >> >> > malicious node could change it's activities to avoid detection. >> >> >> > >> >> >> > The other issue that is stuck in my head is that I think exit >> scanning >> >> >> > is always going to be a losing battle and this is a best-effort >> game. >> >> >> > I see it in the same way that Android has tried to keep track of >> >> >> > malware on the Play market. It will be days in even the best case >> >> >> > scenario before we find out an exit node is malicious and properly >> >> >> > report them. It's high effort for little return. >> >> >> >> >> >> While it may be an arms race. I don't think it's as bad as you might >> >> >> think. For starters, there's a lot of low hanging/high reward fruit >> -- >> >> >> just two volunteers running BadExit scans collaboratively would be a >> >> >> huge improvement. >> >> >> >> >> >> > In an ideal - not-Tor world - there could be some kind of >> activation >> >> >> > process for exit nodes that validate configurations and performs >> >> >> > simple checks before they join the network, and contact >> information is >> >> >> > confirmed (or at least attempted). This assuredly will never >> happen >> >> >> > for a variety of reasons one of which is that it's a deterrent for >> >> >> > those volunteer operators that we need lots and lots of. I wonder >> if >> >> >> > this has already been discussed or if it's worth at least >> documenting >> >> >> > the design decision somewhere. It's valid to say "We won't do this >> >> >> > because of X Y and Z" but I would like to see how the debate >> would go >> >> >> > against a realistic solution (that has yet to be proposed). >> >> >> >> >> >> This isn't likely to work either, as bad exits can wait arbitrary >> >> >> amount of time after passing any tests before attacking clients. I >> >> >> think it's preferable that tests are unpredictable, periodic, and >> >> >> looks as much like a real user as possible. >> >> >> >> >> >> > >> >> >> > ROC >> >> >> > _______________________________________________ >> >> >> > tor-talk mailing list >> >> >> > tor-talk@lists.torproject.org >> >> >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> >> >> _______________________________________________ >> >> >> tor-talk mailing list >> >> >> tor-talk@lists.torproject.org >> >> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> >> >> >> >> > _______________________________________________ >> >> > tor-talk mailing list >> >> > tor-talk@lists.torproject.org >> >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> >> _______________________________________________ >> >> tor-talk mailing list >> >> tor-talk@lists.torproject.org >> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> >> >> > _______________________________________________ >> > tor-talk mailing list >> > tor-talk@lists.torproject.org >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> _______________________________________________ >> tor-talk mailing list >> tor-talk@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> > > _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
