[tor-dev] Proposal 187: Reserve a cell type to allow client authorization
George Kadianakis
desnacked at gmail.com
Sat Oct 29 13:21:20 UTC 2011
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.
More information about the tor-dev
mailing list