[tor-commits] [webwml/master] Fix merge conflicts

hiro at torproject.org hiro at torproject.org
Wed Aug 22 10:34:05 UTC 2018


commit ac08645cea83c2f900f81b57d70734de3ef9d099
Merge: a9e57ef3 d7568ec6
Author: hiro <hiro at torproject.org>
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>





More information about the tor-commits mailing list