Le vendredi 23 juillet 2010 17.03:09, vous avez écrit : > Hello, > > Nick blessed me as a co-proposal editor last night at PETS2010; I've > given the following proposal an initial number of 171. > > The proposal in question will be updated in my git repository until it > is accepted into master: > https://gitweb.torproject.org/ioerror/tor.git/blob/refs/heads/isolated-stre > ams:/doc/spec/proposals/171-separate-streams-by-port-or-host.txt > > Here's the proposal in question: > > 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: 22-Jul-2010 > Status: Draft > > Motivation: > > Streams are currently attached to circuits without regard to their > content, destination host, or destination port. We propose two options, > 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 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 nodes 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 connections attached to streams will be isolated to separate > circuits by port number. > > IsolateStreamsByHost will take a boolean value. When enabled, all > 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. > > 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 of their > traffic at a single exit node during a given time window. > > 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. > > 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. Hi Jacob, Thanks very much to sahre with us, it look a good idea for me, some site still resitant against ssl and little help for security will welcome.... I will give a try. I will give my feedback, best regrads SwissTorExit
Attachment:
signature.asc
Description: This is a digitally signed message part.