[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [webwml/master] Fix merge conflicts
commit ac08645cea83c2f900f81b57d70734de3ef9d099
Merge: a9e57ef3 d7568ec6
Author: hiro <hiro@xxxxxxxxxxxxxx>
Date: Wed Aug 22 12:25:54 2018 +0200
Fix merge conflicts
docs/en/faq.wml | 3843 +++++++++++++++++++++++++++----------------------------
1 file changed, 1912 insertions(+), 1931 deletions(-)
diff --cc docs/en/faq.wml
index 70e63620,05eaff4e..ee197963
--- a/docs/en/faq.wml
+++ b/docs/en/faq.wml
@@@ -282,9 -294,21 +295,9 @@@
traffic.</a></li>
</ul>
- <a id="abuse"></a>
- <h4 style="margin-bottom: 18px"><a class="anchor" href="#abuse">Abuse:
- </a></h4>
- <ul>
- <li><a href="#Criminals">Doesn't Tor enable criminals to do bad things?
- </a></li>
- <li><a href="#RespondISP">How do I respond to my ISP about my exit
- relay?</a></li>
- <li><a href="#HelpPoliceOrLawyers">I have questions about a Tor IP address
- for a legal case.</a></li>
- </ul>
-
<p>For other questions not yet on this version of the FAQ, see the
- <a
- href="<wikifaq>">wiki FAQ</a> for now.</p>
+ <a href="<wikifaq>">wiki FAQ</a> for now.
+ </p>
<hr>
@@@ -2066,47 -2059,35 +2048,53 @@@ versions
#Accept from all interfaces
SocksListenAddress 0.0.0.0:9100
</pre>
+
<p>
- You can state multiple listen addresses, in the case that you are
- part of several networks or subnets.
+ You can state multiple listen addresses, in the case that you are
+ part of several networks or subnets.
</p>
+
<pre>
- SocksListenAddress 192.168.x.x:9100 #eth0
- SocksListenAddress 10.x.x.x:9100 #eth1
+ SocksListenAddress 192.168.x.x:9100 #eth0
+ SocksListenAddress 10.x.x.x:9100 #eth1
</pre>
+
<p>
- After this, your clients on their respective networks/subnets would specify
- a socks proxy with the address and port you specified SocksListenAddress
- to be.
+ After this, your clients on their respective networks/subnets would specify
+ a socks proxy with the address and port you specified SocksListenAddress
+ to be.
</p>
+
<p>
- Please note that the SocksPort configuration option gives the port ONLY for
- localhost (127.0.0.1). When setting up your SocksListenAddress(es), you need
- to give the port with the address, as shown above.
+ Please note that the SocksPort configuration option gives the port ONLY for
+ localhost (127.0.0.1). When setting up your SocksListenAddress(es), you need
+ to give the port with the address, as shown above.
+ </p>
+
<p>
- If you are interested in forcing all outgoing data through the central Tor
- client/relay, instead of the server only being an optional proxy, you may find
- the program iptables (for *nix) useful.
+ If you are interested in forcing all outgoing data through the central Tor
+ client/relay, instead of the server only being an optional proxy, you may
+ find the program iptables (for *nix) useful.
</p>
+ <a id="IPv6"></a>
+ <h3><a class="anchor" href="#IPv6">How do I use Tor from an IPv6 only host/computer?</a></h3>
+ <p>
+ IPv6 is supported since Tor version 0.2.8.x or newer. To activate it add
+ the following two entries into your torrc file:
+ </p>
+ <pre>
+ ClientUseIPv4 0
+ ClientUseIPv6 1
+ </pre>
+ <p>
+ Note that as of 2018 there aren't many IPv6 users, or IPv6 guards, so Tor over IPv6
+ is less anonymous than Tor over IPv4. You can review the IPv6 implemetation status at our
+ <a href="https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features";>IPv6Features</a>
+ wiki page, known issues can be found with the
+ <a href="https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~ipv6";>ipv6 keyword</a>.
+ </p>
+
<hr>
<a id="RunningATorRelay"></a>
@@@ -3912,111 -3874,105 +3881,106 @@@ Perhaps even run separate Tor clients f
Please help on all of these!
</p>
- <hr>
-
- <a id="TransportIPnotTCP"></a>
- <h3><a class="anchor" href="#TransportIPnotTCP">You should transport all
- IP packets, not just TCP packets.</a></h3>
-
- <p>
- This would be handy, because it would make Tor better able to handle
- new protocols like VoIP, it could solve the whole need to socksify
- applications, and it would solve the fact that exit relays need to
- allocate a lot of file descriptors to hold open all the exit
- connections.
- </p>
-
- <p>
- We're heading in this direction: see <a
- href="https://trac.torproject.org/projects/tor/ticket/1855";>this trac
- ticket</a> for directions we should investigate. Some of the hard
- problems are:
- </p>
-
- <ol>
- <li>IP packets reveal OS characteristics. We would still need to do
- IP-level packet normalization, to stop things like TCP fingerprinting
- attacks. Given the diversity and complexity of TCP stacks, along with <a
- href="#RemotePhysicalDeviceFingerprinting">device
- fingerprinting attacks</a>, it looks like our best bet is shipping our
- own user-space TCP stack.
- </li>
- <li>Application-level streams still need scrubbing. We will still need
- user-side applications like Torbutton. So it won't become just a matter
- of capturing packets and anonymizing them at the IP layer.
- </li>
- <li>Certain protocols will still leak information. For example, we must
- rewrite DNS requests so they are delivered to an unlinkable DNS server
- rather than the DNS server at a user's ISP; thus, we must understand
- the protocols we are transporting.
- </li>
- <li><a
- href="http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html";>DTLS
- </a>
- (datagram TLS) basically has no users, and IPsec sure is big. Once we've
- picked a transport mechanism, we need to design a new end-to-end Tor
- protocol for avoiding tagging attacks and other potential anonymity and
- integrity issues now that we allow drops, resends, et cetera.
- </li>
- <li>Exit policies for arbitrary IP packets mean building a secure
- IDS. Our node operators tell us that exit policies are one of the main
- reasons they're willing to run Tor. Adding an Intrusion Detection System
- to handle exit policies would increase the security complexity of Tor,
- and would likely not work anyway, as evidenced by the entire field of
- IDS
- and counter-IDS papers. Many potential <a href="<page docs/faq-abuse>">abuse</a> issues are resolved by the
- fact that Tor only transports valid TCP streams (as opposed to arbitrary
- IP including malformed packets and IP floods), so exit policies become
- even <i>more</i> important as we become able to transport IP packets. We
- also need to compactly describe exit policies in the Tor directory,
- so clients can predict which nodes will allow their packets to exit
- —
- and clients need to predict all the packets they will want to send in
- a session before picking their exit node!
- </li>
- <li>The Tor-internal name spaces would need to be redesigned. We support
- onion service ".onion" addresses by intercepting the addresses when
- they are passed to the Tor client. Doing so at the IP level will require
- a more complex interface between Tor and the local DNS resolver.
- </li>
- </ol>
-
- <hr>
-
- <a id="HideExits"></a>
- <h3><a class="anchor" href="#HideExits">You should hide the list of Tor
- relays, so people can't block the exits.</a></h3>
-
- <p>
- There are a few reasons we don't:
- </p>
-
- <ol>
- <li>We can't help but make the information available, since Tor clients
- need to use it to pick their paths. So if the "blockers" want it, they
- can get it anyway. Further, even if we didn't tell clients about the
- list of relays directly, somebody could still make a lot of connections
- through Tor to a test site and build a list of the addresses they see.
- </li>
-
- <li>If people want to block us, we believe that they should be allowed
- to
- do so. Obviously, we would prefer for everybody to allow Tor users to
- connect to them, but people have the right to decide who their services
- should allow connections from, and if they want to block anonymous
- users,
- they can.
- </li>
-
- <li>Being blockable also has tactical advantages: it may be a persuasive
- response to website maintainers who feel threatened by Tor. Giving them
- the option may inspire them to <a href="<page docs/faq-abuse>#Bans">stop
- and think</a> about whether they really want to eliminate private access
- to their system, and if not, what other options they might have. The
- time they might otherwise have spent blocking Tor, they may instead
- spend rethinking their overall approach to privacy and anonymity.
- </li>
- </ol>
+ <hr>
+
+ <a id="TransportIPnotTCP"></a>
+ <h3><a class="anchor" href="#TransportIPnotTCP">You should transport all
+ IP packets, not just TCP packets.</a></h3>
+
+ <p>
+ This would be handy, because it would make Tor better able to handle
+ new protocols like VoIP, it could solve the whole need to socksify
+ applications, and it would solve the fact that exit relays need to
+ allocate a lot of file descriptors to hold open all the exit
+ connections.
+ </p>
+
+ <p>
+ We're heading in this direction: see
+ <a href="https://trac.torproject.org/projects/tor/ticket/1855";>this trac
+ ticket</a> for directions we should investigate. Some of the hard problems
+ are:
+ </p>
+
+ <ol>
+ <li>IP packets reveal OS characteristics. We would still need to do
+ IP-level packet normalization, to stop things like TCP fingerprinting
+ attacks. Given the diversity and complexity of TCP stacks, along with
+ <a href="#RemotePhysicalDeviceFingerprinting">device fingerprinting
+ attacks</a>, it looks like our best bet is shipping our own user-space TCP
+ stack.
+ </li>
+ <li>Application-level streams still need scrubbing. We will still need
+ user-side applications like Torbutton. So it won't become just a matter
+ of capturing packets and anonymizing them at the IP layer.
+ </li>
+ <li>Certain protocols will still leak information. For example, we must
+ rewrite DNS requests so they are delivered to an unlinkable DNS server
+ rather than the DNS server at a user's ISP; thus, we must understand
+ the protocols we are transporting.
+ </li>
+ <li><a href="http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html";>
+ DTLS</a> (datagram TLS) basically has no users, and IPsec sure is big. Once
+ we've picked a transport mechanism, we need to design a new end-to-end Tor
+ protocol for avoiding tagging attacks and other potential anonymity and
+ integrity issues now that we allow drops, resends, et cetera.
+ </li>
+ <li>Exit policies for arbitrary IP packets mean building a secure IDS. Our
+ node operators tell us that exit policies are one of the main reasons
+ they're willing to run Tor. Adding an Intrusion Detection System to handle
+ exit policies would increase the security complexity of Tor, and would
+ likely not work anyway, as evidenced by the entire field of IDS and
+ counter-IDS papers. Many potential abuse issues are resolved by the fact
+ that Tor only transports valid TCP streams (as opposed to arbitrary IP
+ including malformed packets and IP floods), so exit policies become even
+ <i>more</i> important as we become able to transport IP packets. We also
+ need to compactly describe exit policies in the Tor directory, so clients
+ can predict which nodes will allow their packets to exit — and
+ clients need to predict all the packets they will want to send in a session
+ before picking their exit node!
+ </li>
+ <li>The Tor-internal name spaces would need to be redesigned. We support
+ onion service ".onion" addresses by intercepting the addresses when they
+ are passed to the Tor client. Doing so at the IP level will require a more
+ complex interface between Tor and the local DNS resolver.
+ </li>
+ </ol>
+
+ <hr>
+
+ <a id="HideExits"></a>
+ <h3><a class="anchor" href="#HideExits">You should hide the list of Tor
+ relays, so people can't block the exits.</a></h3>
+
+ <p>
+ There are a few reasons we don't:
+ </p>
+
+ <ol>
+ <li>We can't help but make the information available, since Tor clients
+ need to use it to pick their paths. So if the "blockers" want it, they
+ can get it anyway. Further, even if we didn't tell clients about the
+ list of relays directly, somebody could still make a lot of connections
+ through Tor to a test site and build a list of the addresses they see.
+ </li>
+
+ <li>If people want to block us, we believe that they should be allowed to
+ do so. Obviously, we would prefer for everybody to allow Tor users to
+ connect to them, but people have the right to decide who their services
+ should allow connections from, and if they want to block anonymous users,
+ they can.
+ </li>
+
+ <li>Being blockable also has tactical advantages: it may be a persuasive
+ response to website maintainers who feel threatened by Tor. Giving them
+ the option may inspire them to <a href="<page docs/faq-abuse>#Bans">stop
+ and think</a> about whether they really want to eliminate private access
+ to their system, and if not, what other options they might have. The
+ time they might otherwise have spent blocking Tor, they may instead
+ spend rethinking their overall approach to privacy and anonymity.
+ </li>
+ </ol>
++>>>>>>> faq-datadir
<hr>
@@@ -4095,25 -4028,33 +4063,34 @@@
each connection over many paths.</a></h3>
<p>
- We don't currently think this is a good idea. You see, the attacks we're
- worried about are at the endpoints: the adversary watches Alice (or the
- first hop in the path) and Bob (or the last hop in the path) and learns
- that they are communicating.
+ We don't currently think this is a good idea. You see, the attacks we're
+ worried about are at the endpoints: the adversary watches Alice (or the
+ first hop in the path) and Bob (or the last hop in the path) and learns
+ that they are communicating.
+ </p>
+
+ <p>
+ If we make the assumption that timing attacks work well on even a few
+ packets end-to-end, then having *more* possible ways for the adversary to
+ observe the connection seems to hurt anonymity, not help it.
</p>
+
<p>
- If we make the assumption that timing attacks work well on even a few packets
- end-to-end, then having *more* possible ways for the adversary to observe the
- connection seems to hurt anonymity, not help it.
++
+ Now, it's possible that we could make ourselves more resistant to
+ end-to-end attacks with a little bit of padding and by making each circuit
+ send and receive a fixed number of cells. This approach is more
+ well-understood in the context of high-latency systems. See e.g.
+ <a href="http://freehaven.net/anonbib/#pet05-serjantov";>
+ Message Splitting Against the Partial Adversary by Andrei Serjantov and
+ Steven J. Murdoch</a>.
</p>
+
<p>
- Now, it's possible that we could make ourselves more resistant to end-to-end
- attacks with a little bit of padding and by making each circuit send and
- receive a fixed number of cells. This approach is more well-understood in
- the context of high-latency systems. See e.g.
- <a href="http://freehaven.net/anonbib/#pet05-serjantov";>
- Message Splitting Against the Partial Adversary by Andrei Serjantov and
- Steven J. Murdoch</a>. Also see our <a href="SendPadding">update on netflow
- padding below</a>.
+ But since we don't currently understand what network and padding
+ parameters, if any, could provide increased end-to-end security, our
+ current strategy is to minimize the number of places that the adversary
+ could possibly see.
</p>
<hr>
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits