|
|
@@ -0,0 +1,76 @@
|
|
|
+Filename: xxx-port-knocking.txt
|
|
|
+Title: Port knocking for bridge scanning resistance
|
|
|
+Version: $Revision$
|
|
|
+Last-Modified: $Date$
|
|
|
+Author: Jacob Appelbaum
|
|
|
+Created: 19-April-2009
|
|
|
+Status: Draft
|
|
|
+
|
|
|
+ Port knocking for bridge scanning resistance
|
|
|
+
|
|
|
+0.0 Introduction
|
|
|
+
|
|
|
+This document is a collection of ideas relating to improving scanning
|
|
|
+resistance for private bridge relays. This is intented to stop opportunistic
|
|
|
+network scanning and subsequent discovery of private bridge relays.
|
|
|
+
|
|
|
+
|
|
|
+0.1 Current Implementation
|
|
|
+
|
|
|
+Currently private bridges are only hidden by their obscurity. If you know
|
|
|
+a bridge ip address, the bridge can be detected trivially and added to a block
|
|
|
+list.
|
|
|
+
|
|
|
+0.2 Configuring an external port knocking program to control the firewall
|
|
|
+
|
|
|
+It is currently possible for bridge operators to configure a port knocking
|
|
|
+daemon that controls access to the incoming OR port. This is currently out of
|
|
|
+scope for Tor and Tor configuration. This process requires the firewall to know
|
|
|
+the current nodes in the Tor network.
|
|
|
+
|
|
|
+1.0 Suggested changes
|
|
|
+
|
|
|
+Private bridge operators should be able to configure a method of hiding their
|
|
|
+relay. Only authorized users should be able to communicate with the private
|
|
|
+bridge. This should be done with Tor and if possible without the help of the
|
|
|
+firewall. It should be possible for a Tor user to enter a secret key into
|
|
|
+Tor or optionally Vidalia on a per bridge basis. This secret key should be
|
|
|
+used
|
|
|
+
|
|
|
+1.x Issues with low ports and bind() for ORPort
|
|
|
+
|
|
|
+Tor opens low numbered ports during startup and then drops privileges. It is
|
|
|
+no longer possible to rebind to those lower ports after they are closed.
|
|
|
+
|
|
|
+1.x Issues with OS level packet filtering
|
|
|
+
|
|
|
+Tor does not know about any OS level packet filtering. Currently there is no
|
|
|
+packet filters that understands the Tor network in real time.
|
|
|
+
|
|
|
+1.x Possible partioning of users by bridge operator
|
|
|
+
|
|
|
+Depending on implementation, it may be possible for bridge operators to
|
|
|
+uniquely identify users. This appears to be a general bridge issue when a
|
|
|
+bridge operator uniquely deploys bridges per user.
|
|
|
+
|
|
|
+2.0 Implementation ideas
|
|
|
+
|
|
|
+This is a suggested set of methods for port knocking.
|
|
|
+
|
|
|
+2.x Using SPA port knocking
|
|
|
+
|
|
|
+Single Packet Authentication port knocking encodes all required data into a
|
|
|
+single UDP packet. Improperly formatted packets may be simply discarded.
|
|
|
+Properly formatted packets should be processed and appropriate actions taken.
|
|
|
+
|
|
|
+2.x Using DNS as a transport for SPA
|
|
|
+
|
|
|
+It should be possible for Tor to bind to port 53 at startup and merely drop all
|
|
|
+packets that are not valid. UDP does not require a response and invalid packets
|
|
|
+will not trigger a response from Tor. With base32 encoding it should be
|
|
|
+possible to encode SPA as valid DNS requests. This should allow use of the
|
|
|
+public DNS infrastructure for authorization requests if desired.
|
|
|
+
|
|
|
+2.x Additional considerations
|
|
|
+
|
|
|
+There are many. A format of the packet and the crypto involved is a good start.
|
Jacob Appelbaum