mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2025-02-26 15:42:34 +01:00
77 lines
2.9 KiB
Text
77 lines
2.9 KiB
Text
|
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.
|