Tor Port-Scanning Resistance Specification

[Shane Pope]

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 at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20091020/356edcc5/attachment.htm>