Re: Tor Port-Scanning Resistance Specification

[Shane Pope <Shane.M.Pope@xxxxxxxxx>]

For archival sake, here's the spec in textual format. -Shane

Tor Port-Scanning Resistance

Shane Pope

0. Preliminaries

0.1 Definitions, Notation and encoding

    OR Port -- The port running the OR protocol on the server.


    Tor bridge -- A relay running Tor
    Bug-compatible -- Any inputs into an altered system will respond with the
      exact same response the unaltered system would respond with.
    Bridge-specific password -- A password set by the bridge operator. This


      password will be sent as a query string from a Tor client to the webserver.
      Example: GET /tor/?passwordGoesHere

1. System Overview

   An adversary who wants to identify a machine running Tor can try connecting to


   ports on the machine and following Tor protocol. If any of the ports respond
   following Tor protocol, we know they are running Tor. This system aims to prevent
   port-scanning tools from detecting Tor servers. To do this we attempt to hide


   the server behind an HTTPS webserver(Apache). Another goal is making the system
   usable enough that it will be easy to widely deploy.


2.  Protocol

    Tor runs on a local port, which cannot be connected to from the outside. Apache


    runs on the standard https port (and http, as an average webserver would).
    Anyone connecting to the webserver will receive a bug-compatible response,
    typically a 404 or the page at the url passed, unless they know a 


    bridge-specific password. If the bridge-specific password is sent, the
    connection begins proxying all data to and from the local Tor server.

2.1 Bridge-Specific Password

    - Stub. Generated?


2.2 Required Changes to Tor Client

    - Client needs a flag when given a bridge to know to treat the bridge as normal
      or scanning resistant (Easy)
    - Client must use a web browser-identical TLS handshake.


    - After creating the TLS connection the client must send the bridge-specific
      password.
    - Client must then be changed to send all data under this SSL connection
      instead of the normal Tor SSL protocol.


2.3 Required features of the Apache module

    - Authenticate the user if the correct password is sent, otherwise let Apache
      handle the request. (DONE)
    - Create a socket to local Tor bridge (DONE - Socket per connection)


    - Pass all bits from authenticated client connection to Tor
    - Pass all bits from local Tor back to authenticated client

2.4 Required Changes to Tor Server

    - Add directives to know if the server is a scanning resistant bridge or not. (Easy)


    - Rewrite connection code to accept unencrypted OR connections (Eek)
    - More?

2.5 Benefits

    - Completely hides initial Tor handshake
    - No window of time to be scanned at all.














3.  Another Protocol (Much easier to implement, not working on due to problems with it)

    Tor runs it's OR port on a high numbered port. Tor stops accepting connections.


    Apache accepts a bridge-specific password over https. Apache then sends a
    command to Tor to begin accepting connections for a few minutes or until the
    user has connected. Any user attempting to port scan Tor would only be able to


    scan between the window that the port accepts connections.

3.1 Required Changes to Tor Client

    - Client needs a flag when given a bridge to know to treat the bridge as normal
      or scanning resistant (Easy)


    - Client must follow the same TLS protocol that Apache runs, and send the
      bridge-specific password after connecting.

3.2 Required features of the Apache module

    - Authenticate the user if the correct password is sent, otherwise let Apache


      handle the request. (DONE)
    - Connect to Tor's controller port and sending "open port" command to Tor.

3.3 Required Changes to Tor Server

    - Add directives to know if the server is a scanning resistant bridge or not.


    - Add code to disable accepting connections on the OR Port unless some flag is
      true, and time out that flag to false.
    - Add code to turn the flag above to false if the set of users who
      authenticated through the webserver has connected.


    - Set the above flag using the controller port.

3.4 Benefits

    - Possibly easier to port to other webservers.
    - Much easier to implement
    - Small window of time in which Tor can be detected.


3.5 Problems with design

    - Does not hide inital Tor handshake
    - Tor can still be detected, via port scan, in a small timeframe

On Tue, Oct 20, 2009 at 8:11 PM, Shane Pope <Shane.M.Pope@xxxxxxxxx> wrote:

I've written up a specification for the project I'm working on. Any feedback would be much appreciated.

http://scanresisttor.googlecode.com/svn/mod_tor/tor_sr_spec.txt

-Shane