Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
Tor
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Container Registry
Model registry
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
The Tor Project
Core
Tor
Commits
f33f2e95
Commit
f33f2e95
authored
15 years ago
by
Jacob Appelbaum
Browse files
Options
Downloads
Patches
Plain Diff
Update the port knocking SPA document to have more details. Still needs a packet filter.
svn:r19356
parent
7f4bfe51
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/spec/proposals/ideas/xxx-port-knocking.txt
+18
-1
18 additions, 1 deletion
doc/spec/proposals/ideas/xxx-port-knocking.txt
with
18 additions
and
1 deletion
doc/spec/proposals/ideas/xxx-port-knocking.txt
+
18
−
1
View file @
f33f2e95
...
...
@@ -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.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment