mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-14 07:03:44 +01:00
d230827912
Tor doesn't use SVN anymore, making $Revision$, $Id$ and $Date$ meaningless. Remove them without replacement.
92 lines
3.7 KiB
Plaintext
92 lines
3.7 KiB
Plaintext
Filename: xxx-port-knocking.txt
|
|
Title: Port knocking for bridge scanning resistance
|
|
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 to authenticate the bridge user to the private bridge.
|
|
|
|
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 Ghetto firewalling with opportunistic connection closing
|
|
|
|
Until a user has authenticated with Tor, Tor only has a UDP listener. This
|
|
listener should never send data in response, it should only open an ORPort
|
|
when a user has successfully authenticated. After a user has authenticated
|
|
with Tor to open an ORPort, only users who have authenticated will be able
|
|
to use it. All other users as identified by their ip address will have their
|
|
connection closed before any data is sent or received. This should be
|
|
accomplished with an access policy. By default, the access policy should block
|
|
all access to the ORPort.
|
|
|
|
2.x Timing and reset of access policies
|
|
|
|
Access to the ORPort is sensitive. The bridge should remove any exceptions
|
|
to its access policy regularly when the ORPort is unused. Valid users should
|
|
reauthenticate if they do not use the ORPort within a given time frame.
|
|
|
|
2.x Additional considerations
|
|
|
|
There are many. A format of the packet and the crypto involved is a good start.
|