commit ac08645cea83c2f900f81b57d70734de3ef9d099 Merge: a9e57ef3 d7568ec6 Author: hiro hiro@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%22%3Ethis 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%22%3EDTLS - </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@lists.torproject.org