[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Proposal 187: Reserve a cell type to allow client authorization

I like the proposal; what I think we now have to figure out, is what
kind and how much of 'scanning resistance' to put into the tor binary.

If we assume that tor must act as something innocuous in the case of a
false AUTHORIZE, we have to find out how much of that innocuous
behavior should be implemented into tor. 
We probably want to avoid putting megabytes of innocuous-looking HTML
pages or implement a bittorrent tracker into tor.
Not only because the implementation will make the tor codebase even
more bloated, but also because we would have to ship a new tor every
time the censors manage to block an obfuscation.

What I think is saner - at least for the short term future - is find a
couple of web services (not necessarily HTTP(S)) whose interface is
easy to implement and have bridges stick to one of them at random, for
as long as they stay on an IP address.

Some examples of such interfaces:

* A "HTTP server" whose index page is protected by HTTP basic access
  authentication. 
  It's easy to code (a couple of HTTP headers and some HTML), with a
  small distinguishing surface and it also defends the fact that the
  same "web server" serves lots of data to other clients (read: the
  actual bridge users).

* A "HTTP server" whose index page is an Apache "It Works!". It serves
  404s to any HTTP request.

* An "FTPS server" which asks for a username/password and obviously
  accepts none.

* An "SSH server" which asks for a username/password and obviously
  accepts none.

Then we can also add a torrc option, say
"ScanningResistanceServicePort", that takes a local port as an
argument and pipes all the input of the attacker (the person who
failed the AUTHORIZE) to that port. In that port the user should have
configured an actual web service which will handle that input.

In the future we can also code a project that pretends to be different
web services for the sake of sitting behind
"ScanningResistanceServicePort". That way we don't polute the tor
codebase and we can also use high level programming languages.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev