For archival sake, here's the spec in textual format. -Shane<br><br><pre>Tor Port-Scanning Resistance<br><br>Shane Pope<br><br>0. Preliminaries<br><br>0.1 Definitions, Notation and encoding<br><br> OR Port -- The port running the OR protocol on the server.<br>
Tor bridge -- A relay running Tor<br> Bug-compatible -- Any inputs into an altered system will respond with the<br> exact same response the unaltered system would respond with.<br> Bridge-specific password -- A password set by the bridge operator. This<br>
password will be sent as a query string from a Tor client to the webserver.<br> Example: GET /tor/?passwordGoesHere<br><br>1. System Overview<br><br> An adversary who wants to identify a machine running Tor can try connecting to<br>
ports on the machine and following Tor protocol. If any of the ports respond<br> following Tor protocol, we know they are running Tor. This system aims to prevent<br> port-scanning tools from detecting Tor servers. To do this we attempt to hide<br>
the server behind an HTTPS webserver(Apache). Another goal is making the system<br> usable enough that it will be easy to widely deploy.<br><br><br>2. Protocol<br><br> Tor runs on a local port, which cannot be connected to from the outside. Apache<br>
runs on the standard https port (and http, as an average webserver would).<br> Anyone connecting to the webserver will receive a bug-compatible response,<br> typically a 404 or the page at the url passed, unless they know a <br>
bridge-specific password. If the bridge-specific password is sent, the<br> connection begins proxying all data to and from the local Tor server.<br><br>2.1 Bridge-Specific Password<br><br> - Stub. Generated?<br>
<br>2.2 Required Changes to Tor Client<br><br> - Client needs a flag when given a bridge to know to treat the bridge as normal<br> or scanning resistant (Easy)<br> - Client must use a web browser-identical TLS handshake.<br>
- After creating the TLS connection the client must send the bridge-specific<br> password.<br> - Client must then be changed to send all data under this SSL connection<br> instead of the normal Tor SSL protocol.<br>
<br>2.3 Required features of the Apache module<br><br> - Authenticate the user if the correct password is sent, otherwise let Apache<br> handle the request. (DONE)<br> - Create a socket to local Tor bridge (DONE - Socket per connection)<br>
- Pass all bits from authenticated client connection to Tor<br> - Pass all bits from local Tor back to authenticated client<br><br>2.4 Required Changes to Tor Server<br><br> - Add directives to know if the server is a scanning resistant bridge or not. (Easy)<br>
- Rewrite connection code to accept unencrypted OR connections (Eek)<br> - More?<br><br>2.5 Benefits<br><br> - Completely hides initial Tor handshake<br> - No window of time to be scanned at all.<br><br><br>
<br>
<br><br><br><br><br><br><br><br><br><br><br>3. Another Protocol (Much easier to implement, not working on due to problems with it)<br><br> Tor runs it's OR port on a high numbered port. Tor stops accepting connections.<br>
Apache accepts a bridge-specific password over https. Apache then sends a<br> command to Tor to begin accepting connections for a few minutes or until the<br> user has connected. Any user attempting to port scan Tor would only be able to<br>
scan between the window that the port accepts connections.<br><br>3.1 Required Changes to Tor Client<br><br> - Client needs a flag when given a bridge to know to treat the bridge as normal<br> or scanning resistant (Easy)<br>
- Client must follow the same TLS protocol that Apache runs, and send the<br> bridge-specific password after connecting.<br><br>3.2 Required features of the Apache module<br><br> - Authenticate the user if the correct password is sent, otherwise let Apache<br>
handle the request. (DONE)<br> - Connect to Tor's controller port and sending "open port" command to Tor.<br><br>3.3 Required Changes to Tor Server<br><br> - Add directives to know if the server is a scanning resistant bridge or not.<br>
- Add code to disable accepting connections on the OR Port unless some flag is<br> true, and time out that flag to false.<br> - Add code to turn the flag above to false if the set of users who<br> authenticated through the webserver has connected.<br>
- Set the above flag using the controller port.<br><br>3.4 Benefits<br><br> - Possibly easier to port to other webservers.<br> - Much easier to implement<br> - Small window of time in which Tor can be detected.<br>
<br>3.5 Problems with design<br><br> - Does not hide inital Tor handshake<br> - Tor can still be detected, via port scan, in a small timeframe<br></pre><div class="gmail_quote">On Tue, Oct 20, 2009 at 8:11 PM, Shane Pope <span dir="ltr"><<a href="mailto:Shane.M.Pope@gmail.com">Shane.M.Pope@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I've written up a specification for the project I'm working on. Any feedback would be much appreciated.<br>
<br clear="all"><a href="http://scanresisttor.googlecode.com/svn/mod_tor/tor_sr_spec.txt" target="_blank">http://scanresisttor.googlecode.com/svn/mod_tor/tor_sr_spec.txt</a><br><font color="#888888">
<br>-Shane<br>
</font></blockquote></div><br>