diff options
author | Jacob Appelbaum <jacob@appelbaum.net> | 2009-04-21 07:55:07 +0000 |
---|---|---|
committer | Jacob Appelbaum <jacob@appelbaum.net> | 2009-04-21 07:55:07 +0000 |
commit | f33f2e95913f4d444bb469ed92dee0d2dd3f7575 (patch) | |
tree | 5d52cbbda6f2203e6cbda570597e5326af8816d1 /doc/spec/proposals | |
parent | 7f4bfe5107b5e65c4c2531eed7d3cb52984bca4a (diff) | |
download | tor-f33f2e95913f4d444bb469ed92dee0d2dd3f7575.tar tor-f33f2e95913f4d444bb469ed92dee0d2dd3f7575.tar.gz |
Update the port knocking SPA document to have more details. Still needs a packet filter.
svn:r19356
Diffstat (limited to 'doc/spec/proposals')
-rw-r--r-- | doc/spec/proposals/ideas/xxx-port-knocking.txt | 19 |
1 files changed, 18 insertions, 1 deletions
diff --git a/doc/spec/proposals/ideas/xxx-port-knocking.txt b/doc/spec/proposals/ideas/xxx-port-knocking.txt index 04bbc7d45..9fbcdf354 100644 --- a/doc/spec/proposals/ideas/xxx-port-knocking.txt +++ b/doc/spec/proposals/ideas/xxx-port-knocking.txt @@ -35,7 +35,7 @@ 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 +used to authenticate the bridge user to the private bridge. 1.x Issues with low ports and bind() for ORPort @@ -71,6 +71,23 @@ 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. |