Matt Pagan commited on 2014-01-29 06:13:10
Zeige 1 geänderte Dateien mit 80 Einfügungen und 19 Löschungen.
| ... | ... |
@@ -36,6 +36,8 @@ proxies?</a></li> |
| 36 | 36 |
<li><a href="#IsItWorking">How can I tell if Tor is working, and that my |
| 37 | 37 |
connections really are anonymized?</a></li> |
| 38 | 38 |
<li><a href="#FTP">How do I use my browser for ftp with Tor?</a></li> |
| 39 |
+ <li><a href="#NoDataScrubbing">Does Tor remove personal information |
|
| 40 |
+ from the data my application sends?</a></li> |
|
| 39 | 41 |
<li><a href="#Metrics">How many people use Tor? How many relays or |
| 40 | 42 |
exit nodes are there?</a></li> |
| 41 | 43 |
<li><a href="#SSLcertfingerprint">What are your SSL certificate |
| ... | ... |
@@ -246,6 +248,10 @@ packets, |
| 246 | 248 |
length.</a></li> |
| 247 | 249 |
<li><a href="#SplitEachConnection">You should split each connection over |
| 248 | 250 |
many paths.</a></li> |
| 251 |
+ <li><a href="#MigrateApplicationStreamsAcrossCircuits">You should migrate |
|
| 252 |
+ application streams across circuits.</a></li> |
|
| 253 |
+ <li><a href="#LetTheNetworkPickThePath">You should let the network pick |
|
| 254 |
+ the path, not the client.</a></li> |
|
| 249 | 255 |
<li><a href="#UnallocatedNetBlocks">Your default exit policy should block |
| 250 | 256 |
unallocated net blocks too.</a></li> |
| 251 | 257 |
<li><a href="#BlockWebsites">Exit policies should be able to block |
| ... | ... |
@@ -928,6 +934,22 @@ executive |
| 928 | 934 |
configure it to point to Tor as a "socks4a" proxy on "localhost" port |
| 929 | 935 |
"9050". |
| 930 | 936 |
</p> |
| 937 |
+ |
|
| 938 |
+ <hr> |
|
| 939 |
+ |
|
| 940 |
+ <a id="NoDataScrubbing"></a> |
|
| 941 |
+ <h3><a class="anchor" href="#NoDataScrubbing">Does Tor remove personal |
|
| 942 |
+ information from the data my application sends?</a></h3> |
|
| 943 |
+ |
|
| 944 |
+ <p>No, it doesn't. You need to use a separate program that understands |
|
| 945 |
+ your application and protocol and knows how to clean or "scrub" the data |
|
| 946 |
+ it sends. The Tor Browser Bundle tries to keep application-level data, |
|
| 947 |
+ like the user-agent string, uniform for all users. The Tor Browser can't |
|
| 948 |
+ do anything about text that you type into forms, though. <a |
|
| 949 |
+ href="https://www.torproject.org/download/download-easy.html.en#warning">Be |
|
| 950 |
+ careful and be smart.</a> |
|
| 951 |
+ </p> |
|
| 952 |
+ |
|
| 931 | 953 |
<hr> |
| 932 | 954 |
|
| 933 | 955 |
<a id="Metrics"></a> |
| ... | ... |
@@ -1091,13 +1113,9 @@ better vendor. |
| 1091 | 1113 |
Tar is a common archive utility for Unix and Linux systems. If your |
| 1092 | 1114 |
system has a mouse, you can usually open them by double clicking. |
| 1093 | 1115 |
Otherwise open a command prompt and execute |
| 1094 |
- <pre> |
|
| 1095 |
- tar xzf <FILENAME>.tar.gz |
|
| 1096 |
- </pre> |
|
| 1116 |
+ <pre>tar xzf <FILENAME>.tar.gz</pre> |
|
| 1097 | 1117 |
or |
| 1098 |
- <pre> |
|
| 1099 |
- tar xJf <FILENAME>.tar.xz |
|
| 1100 |
- </pre> |
|
| 1118 |
+ <pre>tar xJf <FILENAME>.tar.xz</pre> |
|
| 1101 | 1119 |
<p> |
| 1102 | 1120 |
as documented in tar's man page. |
| 1103 | 1121 |
</p> |
| ... | ... |
@@ -1152,9 +1170,7 @@ I'm using Ubuntu and I can't start Tor Browser.</a></h3> |
| 1152 | 1170 |
Ubuntu prevents its users from executing shell scripts by clicking them, |
| 1153 | 1171 |
even when the file permissions are set correctly. For now you need to |
| 1154 | 1172 |
start the Tor Browser from the command line by running </p> |
| 1155 |
-<pre> |
|
| 1156 |
-./start-tor-browser |
|
| 1157 |
-</pre> |
|
| 1173 |
+<pre>./start-tor-browser</pre> |
|
| 1158 | 1174 |
<p> |
| 1159 | 1175 |
from inside the Tor Browser directory. |
| 1160 | 1176 |
</p> |
| ... | ... |
@@ -1169,14 +1185,10 @@ fields, including the address bar, are blacked out and can not be used. |
| 1169 | 1185 |
This is not so great, and we hope to include a fix in a coming release. |
| 1170 | 1186 |
In the mean time, this issue can be worked around by editing the |
| 1171 | 1187 |
start-tor-browser script and adding the following line below line 1:</p> |
| 1172 |
-<pre> |
|
| 1173 |
-export GTK_IM_MODULE=xim |
|
| 1174 |
-</pre> |
|
| 1188 |
+<pre>export GTK_IM_MODULE=xim</pre> |
|
| 1175 | 1189 |
<p>This issue is related to the version of IBUS that ships with Ubuntu. |
| 1176 | 1190 |
Some users have also reported success by executing this command</p> |
| 1177 |
-<pre> |
|
| 1178 |
-ibus exit |
|
| 1179 |
-</pre> |
|
| 1191 |
+<pre>ibus exit</pre> |
|
| 1180 | 1192 |
<p>To follow the progress of this issue, see this <a |
| 1181 | 1193 |
href="https://trac.torproject.org/projects/tor/ticket/9353">bug ticket.</a> |
| 1182 | 1194 |
</p> |
| ... | ... |
@@ -1434,8 +1446,7 @@ of those names is "hl". If you set "hl" to "en" then Google will return |
| 1434 | 1446 |
search results in English regardless of what Google server you have been |
| 1435 | 1447 |
sent to. On a query this looks like: |
| 1436 | 1448 |
</p> |
| 1437 |
-<pre>https://encrypted.google.com/search?q=online%20anonymity&hl=en |
|
| 1438 |
-</pre> |
|
| 1449 |
+<pre>https://encrypted.google.com/search?q=online%20anonymity&hl=en</pre> |
|
| 1439 | 1450 |
<p> |
| 1440 | 1451 |
Another method is to simply use your country code for accessing Google. |
| 1441 | 1452 |
This can be google.be, google.de, google.us and so on. |
| ... | ... |
@@ -1695,8 +1706,8 @@ Bridge obfs3 83.212.101.2:42782 2ADFE7AA8D272C520D1FBFBF4E413F3A1B26313D |
| 1695 | 1706 |
Bridge obfs3 83.212.101.2:443 2ADFE7AA8D272C520D1FBFBF4E413F3A1B26313D |
| 1696 | 1707 |
Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9 |
| 1697 | 1708 |
Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9 |
| 1698 |
-Bridge obfs3 209.141.36.236:45496 |
|
| 1699 |
-Bridge obfs3 208.79.90.242:35658 |
|
| 1709 |
+Bridge obfs3 209.141.36.236:45496 58D91C3A631F910F32E18A55441D5A0463BA66E2 |
|
| 1710 |
+Bridge obfs3 208.79.90.242:35658 BA61757846841D64A83EA2514C766CB92F1FB41F |
|
| 1700 | 1711 |
Bridge obfs3 109.105.109.163:38980 9D7259A696F7DAB073043B28114112A46D36CFFD |
| 1701 | 1712 |
Bridge obfs3 109.105.109.163:47779 844B1F53FFD548C998F8D3B01B7E19FA07C3396E |
| 1702 | 1713 |
Bridge obfs2 83.212.100.216:47870 1F01A7BB60F49FC96E0850A6BAD6D076DFEFAF80 |
| ... | ... |
@@ -4465,6 +4476,56 @@ could possibly see. |
| 4465 | 4476 |
|
| 4466 | 4477 |
<hr> |
| 4467 | 4478 |
|
| 4479 |
+ <a id="MigrateApplicationStreamsAcrossCircuits"></a> |
|
| 4480 |
+ <h3><a class="anchor" href="#MigrateApplicationStreamsAcrossCircuits">You |
|
| 4481 |
+ should migrate application streams across circuits.</a></h3> |
|
| 4482 |
+ <p>This would be great for two reasons. First, if a circuit breaks, we |
|
| 4483 |
+ would be able to shift its active streams onto a new circuit, so they |
|
| 4484 |
+ don't have to break. Second, it is conceivable that we could get |
|
| 4485 |
+ increased security against certain attacks by migrating streams |
|
| 4486 |
+ periodically, since leaving a stream on a given circuit for many hours |
|
| 4487 |
+ might make it more vulnerable to certain adversaries.</p> |
|
| 4488 |
+ |
|
| 4489 |
+ <p>There are two problems though. First, Tor would need a much more |
|
| 4490 |
+ bulky protocol. Right now each end of the Tor circuit just sends the |
|
| 4491 |
+ cells, and lets TCP provide the in-order guaranteed delivery. If we |
|
| 4492 |
+ can move streams across circuits, though, we would need to add queues |
|
| 4493 |
+ at each end of the circuit, add sequence numbers so we can send and |
|
| 4494 |
+ receive acknowledgements for cells, and so forth. These changes would |
|
| 4495 |
+ increase the complexity of the Tor protocol considerably. Which leads |
|
| 4496 |
+ to the second problem: if the exit node goes away, there's nothing we |
|
| 4497 |
+ can do to save the TCP connection. Circuits are typically three hops |
|
| 4498 |
+ long, so in about a third of the cases we just lose.</p> |
|
| 4499 |
+ |
|
| 4500 |
+ <p>Thus our current answer is that since we can only improve things by |
|
| 4501 |
+ at best 2/3, it's not worth the added code and complexity. If somebody |
|
| 4502 |
+ writes a protocol specification for it and it turns out to be pretty |
|
| 4503 |
+ simple, we'd love to add it.</p> |
|
| 4504 |
+ |
|
| 4505 |
+ <p>But there are still some approaches we can take to improve the |
|
| 4506 |
+ reliability of streams. The main approach we have now is to specify |
|
| 4507 |
+ that streams using certain application ports prefer circuits to be |
|
| 4508 |
+ made up of stable nodes. These ports are specified in the "LongLivedPorts" |
|
| 4509 |
+ <a href="#torrc">torrc</a> option, and they default to |
|
| 4510 |
+ <pre>21,22,706,1863,5050,5190,5222,5223,6667,6697,8300</pre>. The |
|
| 4511 |
+ definition of "stable" is an open research question, since we can only |
|
| 4512 |
+ guess future stability based on past performance. Right now we judge |
|
| 4513 |
+ that a node is stable if it advertises that it has been up for more |
|
| 4514 |
+ than a day. Down the road we plan to refine this so it takes into |
|
| 4515 |
+ account the average stability of the other nodes in the Tor network.</p> |
|
| 4516 |
+ |
|
| 4517 |
+ <hr> |
|
| 4518 |
+ |
|
| 4519 |
+ <a id="LetTheNetworkPickThePath"></a> |
|
| 4520 |
+ <h3><a class="anchor" href="#LetTheNetworkPickThePath">You should |
|
| 4521 |
+ let the network pick the path, not the client</a></h3> |
|
| 4522 |
+ |
|
| 4523 |
+ <p>No. You cannot trust the network to pick the path for relays could |
|
| 4524 |
+ collude and route you through their colluding friends. This would give |
|
| 4525 |
+ an adversary the ability to watch all of your traffic end to end.</p> |
|
| 4526 |
+ |
|
| 4527 |
+ <hr> |
|
| 4528 |
+ |
|
| 4468 | 4529 |
<a id="UnallocatedNetBlocks"></a> |
| 4469 | 4530 |
<h3><a class="anchor" href="#UnallocatedNetBlocks">Your default exit |
| 4470 | 4531 |
policy should block unallocated net blocks too.</a></h3> |
| 4471 | 4532 |