Thus spake Fabio Pietrosanti (naif) (lists@xxxxxxxxxxxxxxx): > I fully underline what's told by Mike, it's a dangerous topic, but being > able to implement some kind of filering at exit node is required. > > Probably implementing something as an external tool is better to avoid > introducing "filtering logic" directly into TOR project. > > Do we want to try to setup a working group on this? If you are serious about this, there *must* be some feedback through the Tor protocol to clients who get hit by this censorship. Censorship is a reality everywhere, but that does not mean it is OK to add it to the Tor network for expedience or for marginal gains of Exit bandwidth. Maybe I'm too much of an Amurrican Capitalish, but I do not believe that data centers that impose censorship on Tor Exits deserve any of our collective hosting budgets. Any Exits where censorship is detected can, should, and will receive the BadExit flag, and this includes those that censor for "security reasons". *HOWEVER*, it is in theory possible to provide notification when streams are closed on the fly. The Tor Protocol supports sending the "EXITPOLICY" close reason upstream. The Tor Control Protocol can be extended to allow exits to tell Tor to close streams with this reason. Clients will then automatically, transparently retry their streams at new exits. This ability to transparently route around censorship is the *only* way that it can be acceptable on Tor Exits. And not all forms of IDS can even fit under this model. We must be able to close streams *before* the TCP handshake. We can use circuit correlation to see that one stream on a circuit did something "bad", and then send the EXITPOLICY close reason to all future streams on this circuit. This would also reduce "hacking" attempts and still allow clients to carry on transparently as if nothing ever happened (except a little extra latency). This is not a small project, but it is not an impossible one. The building blocks are all there. If you'd like to discuss this more, we can chat on #tor-dev on irc.oftc.net. It is unlikely that official Tor development time will be spent on this, so be prepared to be ready to hack some code yourself :). It may also be politically unpopular, but that doesn't need to stop you from building it either. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgplfvimeEyWu.pgp
Description: PGP signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays