torproject/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-06 19:41:15 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

This change creates proposal 171: 171-separate-streams-by-port-or-host.txt

Browse Source 
This numbers the proposal to reflect the current discussion on or-dev and irc
This change updates the proposal index to reflect prop 171
This change also includes an update about Nick blessing me as a proposal editor

Proposal 171 is the product of many comments from many contributors including
but not limited to:

    Damon McCoy
    Linus Nordberg
    Nick Matthewson
    Robert Hogan
    Robert Ransom
    Sebastian Hahn
This commit is contained in:
Jacob Appelbaum
2010-07-22 18:14:54 +02:00
parent 64fc64c943
commit 6451519fa3
3 changed files with 102 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/spec/proposals/000-index.txt
+2
View File
@@ -91,6 +91,7 @@ Proposals by number:
168 Reduce default circuit window [OPEN]
169 Eliminate TLS renegotiation for the Tor connection handshake [DRAFT]
170 Configuration options regarding circuit building [DRAFT]
171 Separate streams across circuits by destination port or destination host [DRAFT]
Proposals by status:
@@ -103,6 +104,7 @@ Proposals by status:
144 Increase the diversity of circuits by detecting nodes belonging the same provider
169 Eliminate TLS renegotiation for the Tor connection handshake [for 0.2.2]
170 Configuration options regarding circuit building
171 Separate streams across circuits by destination port or destination host
NEEDS-REVISION:
131 Help users to verify they are using Tor
OPEN:
doc/spec/proposals/001-process.txt
+1 -1
View File
@@ -75,7 +75,7 @@ How new proposals get added:
To get your proposal in, send it to or-dev.
The current proposal editor is Nick Mathewson.
The current proposal editors are Nick Mathewson and Jacob Appelbaum.
What should go in a proposal:
doc/spec/proposals/171-separate-streams-by-port-or-host.txt
+99
View File
@@ -0,0 +1,99 @@
Filename: 171-separate-streams-by-port-or-host.txt
Title: Separate streams across circuits by destination port or destination host
Author: Robert Hogan, Jacob Appelbaum, Damon McCoy
Created: 21-Oct-2008
Modified: 30-Aug-2010
Status: Draft
Motivation:
Streams are currently attached to circuits without regard to their content,
destination host, or destination port. We propose three options,
IsolateBySOCKSUser, IsolateStreamsByPort and IsolateStreamsByHost to change the
default behavior.
The contents of some streams will always have revealing plain text information;
these streams should be treated differently than other streams that may or may
not have unencrypted PII content. DNS, with the exception of DNSCurve, is
always unencrypted. It is reasonable to assume that other protocols may exist
that have a similar issue and may cause user concern. It is also the case that
we must balance network load issues and stream privacy. The Tor network will not
currently scale to one circuit per application connection nor should it anytime
soon.
Circuits are currently created with a few constraints and are rotated within
a reasonable time window. This allows a rogue exit node to correlate all
streams on a given circuit.
Design:
We propose two options for isolation of streams that lessen the observability
and linkability of the Tor client's traffic.
IsolateStreamsByPort will take a list of ports or optionally the keyword 'All'
in place of a port list. The use of the keyword 'All' will ensure that all
application connections attached to streams will be isolated to separate
circuits by port number.
IsolateStreamsByHost will take a boolean value. When enabled, all application
connections, regardless of port number will be isolated with separate circuits
per host. If this option is enabled, we should ensure that the client has a
reasonable number of pre-built circuits to ensure perceived performance. This
should also intentionally limit the total number of circuits a client will
build to ten circuits to prevent abuse and load on the network. This is a
trade-off of performance for anonymity. Tor will issue a warning if a client
encounters this limit.
IsolateBySOCKSUser will take a boolean value. When enabled, all application
connections, regardless of port number will be isolated with separate circuits
per SOCKS username. This options ensures that any two streams that were created
with different SOCKS usernames will be sent over different circuits. The empty
username will be treated as its own username different from all other usernames.
Security implications:
It is believed that the proposed changes will improve the anonymity for end
user stream privacy. The end user will no longer link all streams at a single
exit node during a given time window.
There is a possible attack where a hostile web page possibly in collusion with
an exit node contains image links for images at (say) "evil.example.com:53" and
"evil.example.com:31337", and thereby (if they're lucky) correlate port-80
circuits with port-53 and port-31337 circuits.
Specification:
The Tor client circuit selection process is not entirely specified. Any client
circuit specification must take these changes into account.
Compatibility:
The proposed changes should not create any compatibility issues. New Tor clients
will be able to take advantage of this without any modification to the network.
Implementation:
It is further proposed that IsolateStreamsByPort will be enabled by default
for port 22, 53, and port 80.
It is further proposed that IsolateStreamsByHost will be disabled by default.
Implementation notes:
The implementation of this option may want to consider cases where the same
exit node is shared by two or more circuits and IsolateStreamsByPort is in
force. Since the purpose of the option is to reduce the opportunity of Exit
Nodes to attack traffic from the same source on multiple ports, the
implementation may need to ensure that circuits reserved for the exclusive use
of given ports do not share the same exit node.
Circuits should not be shared by unique clients. Tor should check to ensure
that peer IP addresses are identical when they connect to the SOCKS listener or
the TransPort listener before sharing a circuit. If the addresses are not
identical, Tor should ensure that the circuits are not shared.
Performance and scalability notes:
It is further proposed that IsolateStreamsByPort will be enabled by default for
all ports after a reasonable assessment is performed. Specifically, we should
determine the impact this option has on Tor clients and the Tor network.