Browse code

Added 4 faq entries: My Tor keeps crashing. What protections does Tor provide? Can exit nodes eavesdrop on communications? Isn't that bad? What is Exit Enclaving?

Matt Pagan authored on 06/12/2013 03:57:45
Showing 1 changed files
... ...
@@ -102,6 +102,7 @@ tells
102 102
     <li><a href="#LogLevel">What log level should I use?</a></li>
103 103
     <li><a href="#DoesntWork">Tor is running, but it's not working
104 104
     correctly.</a></li>
105
+    <li><a href="#TorCrash">My Tor keeps crashing.</a></li>
105 106
     <li><a href="#VidaliaPassword">Tor/Vidalia prompts for a password at
106 107
     start.</a></li>
107 108
     <li><a href="#ChooseEntryExit">Can I control which nodes (or
... ...
@@ -156,6 +157,11 @@ relay.</a></li>
156 157
 
157 158
     <p>Anonymity and Security:</p>
158 159
     <ul>
160
+    <li><a href="#WhatProtectionsDoesTorProvide">What protections does Tor 
161
+    provide?</a></li>
162
+    <li><a href="#CanExitNodesEavesdrop">Can exit nodes eavesdrop on 
163
+    communications? Isn't that bad? </a></li>
164
+    <li><a href="#ExitEnclaving">What is Exit Enclaving?</a></li>
159 165
     <li><a href="#KeyManagement">Tell me about all the keys Tor
160 166
 uses.</a></li>
161 167
     <li><a href="#EntryGuards">What are Entry Guards?</a></li>
... ...
@@ -1611,6 +1617,91 @@ about what's going wrong?</li>
1611 1617
 
1612 1618
 <hr />
1613 1619
 
1620
+<a id="TorCrash"></a>
1621
+<h3><a class="anchor" href="#TorCrash">My Tor keeps crashing.</a></h3>
1622
+<p>
1623
+ We want to hear from you! There are supposed to be zero crash bugs in Tor. 
1624
+ This FAQ entry describes the best way for you to be helpful to us. But even 
1625
+ if you can't work out all the details, we still want to hear about it, so 
1626
+ we can help you track it down. 
1627
+</p>
1628
+<p>
1629
+First, make sure you're using the latest version of Tor (either the latest 
1630
+stable or the latest development version). 
1631
+</p>
1632
+<p>
1633
+Second, make sure your version of libevent is new enough. We recommend at 
1634
+least libevent 1.3a. 
1635
+</p>
1636
+<p>
1637
+Third, see if there's already an entry for your bug in the <a 
1638
+href="https://bugs.torproject.org/">Tor bugtracker</a>. If so, 
1639
+check if there are any new details that you can add. 
1640
+</p>
1641
+<p>
1642
+Fourth, is the crash repeatable? Can you cause the crash? Can 
1643
+you isolate some of the circumstances or config options that 
1644
+make it happen? How quickly or often does the bug show up? 
1645
+Can you check if it happens with other versions of Tor, for 
1646
+example the latest stable release? 
1647
+</p>
1648
+<p>
1649
+Fifth, what sort of crash do you get? 
1650
+</p>
1651
+<ul>
1652
+<li>
1653
+Does your Tor log include an "assert failure"? If so, please 
1654
+tell us that line, since it helps us figure out what's going on. 
1655
+Tell us the previous couple of log messages as well, especially 
1656
+if they seem important. 
1657
+</li>
1658
+<li>
1659
+If it says "Segmentation fault - core dumped" then you need to 
1660
+do a bit more to track it down. Look for a file like "core" or 
1661
+"tor.core" or "core.12345" in your current directory, or in your 
1662
+Data Directory. If it's there, run "gdb tor core" and then "bt", 
1663
+and include the output. If you can't find a core, run "ulimit -c 
1664
+unlimited", restart Tor, and try to make it crash again. (This core 
1665
+thing will only work on Unix -- alas, tracking down bugs on Windows 
1666
+is harder. If you're on Windows, can you get somebody to duplicate 
1667
+your bug on Unix?)
1668
+</li>
1669
+<li>
1670
+If Tor simply vanishes mysteriously, it probably is a segmentation 
1671
+fault but you're running Tor in the background (as a daemon) so you 
1672
+won't notice. Go look at the end of your log file, and look for a 
1673
+core file as above. If you don't find any good hints, you should 
1674
+consider running Tor in the foreground (from a shell) so you can 
1675
+see how it dies. Warning: if you switch to running Tor in the foreground, 
1676
+you might start using a different torrc file, with a different default 
1677
+Data Directory; see the <a href="#UpgradeOrMove">relay-upgrade FAQ entry</a> 
1678
+for details. 
1679
+</li>
1680
+<li>
1681
+If it's still vanishing mysteriously, perhaps something else is killing it? 
1682
+Do you have resource limits (ulimits) configured that kill off processes 
1683
+sometimes? (This is especially common on OpenBSD.) On Linux, try running 
1684
+"dmesg" to see if the out-of-memory killer removed your process. (Tor will 
1685
+exit cleanly if it notices that it's run out of memory, but in some cases 
1686
+it might not have time to notice.) In very rare circumstances, hardware 
1687
+problems could also be the culprit. 
1688
+</li>
1689
+</ul>
1690
+<p>
1691
+Sixth, if the above ideas don't point out the bug, consider increasing your 
1692
+log level to "loglevel debug". You can look at the log-configuration FAQ 
1693
+entry for instructions on what to put in your torrc file. If it usually 
1694
+takes a long time for the crash to show up, you will want to reserve a whole 
1695
+lot of disk space for the debug log. Alternatively, you could just send 
1696
+debug-level logs to the screen (it's called "stdout" in the torrc), and then 
1697
+when it crashes you'll see the last couple of log lines it had printed. 
1698
+(Note that running with verbose logging like this will slow Tor down 
1699
+considerably, and note also that it's generally not a good idea security-wise 
1700
+to keep logs like this sitting around.) 
1701
+</p>
1702
+
1703
+<hr />
1704
+
1614 1705
 <a id="VidaliaPassword"></a>
1615 1706
 <h3><a class="anchor" href="#VidaliaPassword">Tor/Vidalia prompts for a
1616 1707
 password at start.</a></h3>
... ...
@@ -2610,12 +2701,180 @@ diversity,
2610 2701
     hidden service?</a></h3>
2611 2702
     
2612 2703
     <p>
2613
-    See the ‚Äč<a href="https://www.torproject.org/docs/tor-hidden-service.html.en">
2704
+    See the <a href="https://www.torproject.org/docs/tor-hidden-service.html.en">
2614 2705
     official hidden service configuration instructions</a>.
2615 2706
     </p>
2616 2707
 
2617 2708
     <hr>
2618 2709
     
2710
+    <a id="WhatProtectionsDoesTorProvide"></a>
2711
+    <h3><a class="anchor" href="#WhatProtectionsDoesTorProvide">What 
2712
+    protections does Tor provide?</a></h3>
2713
+    
2714
+    <p>
2715
+     Internet communication is based on a store-and-forward model that 
2716
+     can be understood in analogy to postal mail: Data is transmitted in 
2717
+     blocks called IP datagrams or packets. Every packet includes a source 
2718
+     IP address (of the sender) and a destination IP address (of the 
2719
+     receiver), just as ordinary letters contain postal addresses of sender 
2720
+     and receiver. The way from sender to receiver involves multiple hops of 
2721
+     routers, where each router inspects the destination IP address and 
2722
+     forwards the packet closer to its destination. Thus, every router 
2723
+     between sender and receiver learns that the sender is communicating 
2724
+     with the receiver. In particular, your local ISP is in the position to 
2725
+     build a complete profile of your Internet usage. In addition, every 
2726
+     server in the Internet that can see any of the packets can profile your 
2727
+     behaviour. 
2728
+    </p>
2729
+    
2730
+    <p>
2731
+    The aim of Tor is to improve your privacy by sending your traffic through 
2732
+    a series of proxies. Your communication is encrypted in multiple layers 
2733
+    and routed via multiple hops through the Tor network to the final 
2734
+    receiver. More details on this process can be found in the <a 
2735
+    href="https://www.torproject.org/about/overview">Tor overview</a>. 
2736
+    Note that all your local ISP can observe now is that you are 
2737
+    communicating with Tor nodes. Similarly, servers in the Internet just 
2738
+    see that they are being contacted by Tor nodes.
2739
+    </p>
2740
+    
2741
+    <p>
2742
+    Generally speaking, Tor aims to solve three privacy problems: 
2743
+    </p>
2744
+    
2745
+    <p>
2746
+    First, Tor prevents websites and other services from learning 
2747
+    your location, which they can use to build databases about your 
2748
+    habits and interests. With Tor, your Internet connections don't 
2749
+    give you away by default -- now you can have the ability to choose, 
2750
+    for each connection, how much information to reveal. 
2751
+    </p>
2752
+    
2753
+    <p>
2754
+    Second, Tor prevents people watching your traffic locally (such as 
2755
+    your ISP) from learning what information you're fetching and where 
2756
+    you're fetching it from. It also stops them from deciding what you're 
2757
+    allowed to learn and publish -- if you can get to any part of the Tor 
2758
+    network, you can reach any site on the Internet.     
2759
+    </p>
2760
+
2761
+    <p>
2762
+    Third, Tor routes your connection through more than one Tor relay 
2763
+    so no single relay can learn what you're up to. Because these relays 
2764
+    are run by different individuals or organizations, distributing trust 
2765
+    provides more security than the old <a href="#Torisdifferent">one hop proxy
2766
+    </a> approach. 
2767
+    </p>
2768
+    
2769
+    <p>
2770
+    Note, however, that there are situations where Tor fails to solve these 
2771
+    privacy problems entirely: see the entry below on <a 
2772
+    href="#AttacksOnOnionRouting">remaining attacks</a>.    
2773
+    </p>
2774
+    
2775
+    <hr>
2776
+    
2777
+    <a id="CanExitNodesEavesdrop"></a>
2778
+    <h3><a class="anchor" href="#CanExitNodesEavesdrop">Can exit nodes eavesdrop 
2779
+    on communications? Isn't that bad?</a></h3>
2780
+    
2781
+    <p>
2782
+    Yes, the guy running the exit node can read the bytes that come in and 
2783
+    out there. Tor anonymizes the origin of your traffic, and it makes sure 
2784
+    to encrypt everything inside the Tor network, but it does not magically 
2785
+    encrypt all traffic throughout the Internet. 
2786
+    </p>
2787
+    
2788
+    <p>
2789
+    This is why you should always use end-to-end encryption such as SSL for 
2790
+    sensitive Internet connections. (The corollary to this answer is that if 
2791
+    you are worried about somebody intercepting your traffic and you're 
2792
+    *not* using end-to-end encryption at the application layer, then something 
2793
+    has already gone wrong and you shouldn't be thinking that Tor is the problem.) 
2794
+    </p>
2795
+    
2796
+    <p>
2797
+    Tor does provide a partial solution in a very specific situation, though. 
2798
+    When you make a connection to a destination that also runs a Tor relay, 
2799
+    Tor will automatically extend your circuit so you exit from that circuit. 
2800
+    So for example if Indymedia ran a Tor relay on the same IP address as 
2801
+    their website, people using Tor to get to the Indymedia website would 
2802
+    automatically exit from their Tor relay, thus getting *better* encryption 
2803
+    and authentication properties than just browsing there the normal way. 
2804
+    </p>
2805
+
2806
+    <p>
2807
+    We'd like to make it still work even if the service is nearby the Tor 
2808
+    relay but not on the same IP address. But there are a variety of 
2809
+    technical problems we need to overcome first (the main one being "how 
2810
+    does the Tor client learn which relays are associated with which 
2811
+    websites in a decentralized yet non-gamable way?"). 
2812
+    </p>
2813
+            
2814
+    <hr>
2815
+    
2816
+    <a id="ExitEnclaving"></a>
2817
+    <h3><a class="anchor" href="#ExitEnclaving">What is Exit Enclaving?</a></h3>
2818
+
2819
+    <p>
2820
+    When a machine that runs a Tor relay also runs a public service, such as 
2821
+    a webserver, you can configure Tor to offer Exit Enclaving to that 
2822
+    service. Running an Exit Enclave for all of your services you wish to 
2823
+    be accessible via Tor provides your users the assurance that they will 
2824
+    exit through your server, rather than exiting from a randomly selected 
2825
+    exit node that could be watched. Normally, a tor circuit would end at 
2826
+    an exit node and then that node would make a connection to your service. 
2827
+    Anyone watching that exit node could see the connection to your service, 
2828
+    and be able to snoop on the contents if it were an unencrypted 
2829
+    connection. If you run an Exit Enclave for your service, then the exit 
2830
+    from the Tor network happens on the machine that runs your service, 
2831
+    rather than on an untrusted random node. This works when Tor clients 
2832
+    wishing to connect to this public service extend their their circuit 
2833
+    to exit from the Tor relay running on that same host. For example, if 
2834
+    the server at 1.2.3.4 runs a web server on port 80 and also acts as a 
2835
+    Tor relay configured for Exit Enclaving, then Tor clients wishing to 
2836
+    connect to the webserver will extend their circuit a fourth hop to exit 
2837
+    to port 80 on the Tor relay running on 1.2.3.4. 
2838
+    </p>
2839
+    <p>
2840
+    Exit Enclaving is disabled by default to prevent attackers from 
2841
+    exploiting trust relationships with locally bound services. For 
2842
+    example, often 127.0.0.1 will run services that are not designed to 
2843
+    be shared with the entire world. Sometimes these services will also 
2844
+    be bound to the public IP address, but will only allow connections if 
2845
+    the source address is something trusted, such as 127.0.0.1. 
2846
+    </p>
2847
+    <p>
2848
+    As a result of possible trust issues, relay operators must configure 
2849
+    their exit policy to allow connections to themselves, but they should 
2850
+    do so only when they are certain that this is a feature that they would 
2851
+    like. Once certain, turning off the ExitPolicyRejectPrivate option will 
2852
+    enable Exit Enclaving. An example configuration would be as follows: 
2853
+    </p>
2854
+    <pre>
2855
+    ExitPolicy accept 1.2.3.4:80
2856
+    ExitPolicy reject 127.0.0.1/8
2857
+    ExitPolicyRejectPrivate 0
2858
+    </pre>
2859
+    <p>
2860
+    This option should be used with care as it may expose internal network 
2861
+    blocks that are not meant to be accessible from the outside world or 
2862
+    the Tor network. Please tailor your ExitPolicy to reflect all netblocks 
2863
+    that you want to prohibit access. 
2864
+    </p>
2865
+    <p>
2866
+    This option should be used with care as it may expose internal network 
2867
+    blocks that are not meant to be accessible from the outside world or 
2868
+    the Tor network. Please tailor your ExitPolicy to reflect all netblocks 
2869
+    that you want to prohibit access. 
2870
+    </p>
2871
+    <p>
2872
+    While useful, this behavior may go away in the future because it is 
2873
+    imperfect. A great idea but not such a great implementation. 
2874
+    </p>
2875
+
2876
+    <hr>
2877
+    
2619 2878
     <a id="KeyManagement"></a>
2620 2879
     <h3><a class="anchor" href="#KeyManagement">Tell me about all the
2621 2880
 keys Tor uses.</a></h3>