...
|
...
|
@@ -1,5 +1,5 @@
|
1
|
1
|
## translation metadata
|
2
|
|
-# Based-On-Revision: 8183 partial
|
|
2
|
+# Based-On-Revision: 8183
|
3
|
3
|
# Last-Translator: ygrekheretix/gmail
|
4
|
4
|
|
5
|
5
|
#include "head.wmi" TITLE="�����������" CHARSET="KOI8-R"
|
...
|
...
|
@@ -56,160 +56,155 @@ Tor'
|
56
|
56
|
����������� ������������ �� ����������, � ����� ���� ����������� ����� ���,
|
57
|
57
|
��� ������ ��������� ��������� ������ �� ���.</li>
|
58
|
58
|
</ul>
|
59
|
|
-<li>People running servers tell us they want to have one BandwidthRate
|
60
|
|
-during some part of the day, and a different BandwidthRate at other parts
|
61
|
|
-of the day. Rather than coding this inside Tor, we should have a little
|
62
|
|
-script that speaks via the <a href="<page gui/index>">Tor Controller Interface</a>,
|
63
|
|
-and does a setconf to change the bandwidth rate. Perhaps it would run out
|
64
|
|
-of cron, or perhaps it would sleep until appropriate times and then do
|
65
|
|
-its tweak (that's probably more portable). Can somebody write one for us
|
66
|
|
-and we'll put it into <a href="<svnsandbox>contrib/">contrib/</a>?
|
67
|
|
-This is a good entry for the <a href="<page gui/index>">Tor GUI
|
68
|
|
-competition</a>.</li>
|
69
|
|
-<li>Tor can <a
|
70
|
|
-href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">exit
|
71
|
|
-the Tor network from a particular exit node</a>, but we should be able
|
72
|
|
-to specify just a country and have something automatically pick. The
|
73
|
|
-best bet is to fetch Blossom's directory also, and run a local Blossom
|
74
|
|
-client that fetches this directory securely (via Tor and checking its
|
75
|
|
-signature), intercepts <tt>.country.blossom</tt> hostnames, and does
|
76
|
|
-the right thing.</li>
|
77
|
|
-<li>Speaking of geolocation data, somebody should draw a map of the Earth
|
78
|
|
-with a pin-point for each Tor server. Bonus points if it updates as the
|
79
|
|
-network grows and changes. Unfortunately, the easy ways to do this involve
|
80
|
|
-sending all the data to Google and having them draw the map for you. How
|
81
|
|
-much does this impact privacy, and do we have any other good options?</li>
|
|
59
|
+<li>�������� �������� ����� ����� ����������� ������� ����� ������� BandwidthRate
|
|
60
|
+� ���������� �� ������� ���. ������ ����, ����� ������ ��� ������ ����� Tor, �����
|
|
61
|
+������ ������ ������� ����� ����������� <a href="<page gui/index>">
|
|
62
|
+��������� Tor Controller</a>, � ������� setconf ��� ��������� ���������� �����.
|
|
63
|
+�������� �� ����� ��������� cron'��, ��� ����� ������������� ������ � ����������
|
|
64
|
+(�������� �������� �� ��������) � ������̣���� �����. �����-�� ���-������
|
|
65
|
+������ ���� � �� � �� ������� ���� ������ � <a href="<svnsandbox>contrib/">contrib/</a>?
|
|
66
|
+��� ����� ������� ���� � <a href="<page gui/index>">Tor GUI �����������</a>.</li>
|
|
67
|
+<li>Tor ����� <a
|
|
68
|
+href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">
|
|
69
|
+�������� �� ���� Tor ����� ������� ����</a>, �� � �� ����� ���� �����������
|
|
70
|
+����� ������ ����� � �������� ������ ������ ������������. ������ ������ ���
|
|
71
|
+������ ��������� Blossom, �������� ������� ������ Blossom, ������� ��������
|
|
72
|
+(����� Tor � �������� �������) ������� ��� ���������, ����������� ���� ���
|
|
73
|
+<tt>.country.blossom</tt>, � ����� �� �� �� ��� �����.</li>
|
|
74
|
+<li>�������� ���������, ���-�� ������ �������� ���� ����� � �����������
|
|
75
|
+�������� Tor. ����� ���� �� ��� ����� ����������� �� ��������. � ���,
|
|
76
|
+������� ������ ������ ��� - ������� ��� ����� � Google ����� ��� �������� ����
|
|
77
|
+� ��. �� ��� ������� � �����������, � ��� �� � �� ������ �������?</li>
|
82
|
78
|
</ol>
|
83
|
79
|
|
84
|
80
|
<a id="Documentation"></a>
|
85
|
|
-<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
|
|
81
|
+<h2><a class="anchor" href="#Documentation">�����������</a></h2>
|
86
|
82
|
<ol>
|
87
|
|
-<li>We hear that Tor users can fall victim to anonymity-breaking attacks
|
88
|
|
-from javascript, java, activex, flash, etc, if they don't disable
|
89
|
|
-them. Are there plugins out there (like NoScript for Firefox) that make
|
90
|
|
-it easier for users to manage this risk? What is the risk exactly?</li>
|
91
|
|
-<li>Is there a full suite of plugins that will replace all of Privoxy's
|
92
|
|
-functionality for Firefox 1.5+? We hear Tor is much faster when you take
|
93
|
|
-Privoxy out of the loop.</li>
|
94
|
|
-<li>Please help Matt Edman with the documentation and how-tos for his
|
95
|
|
-<a href="http://vidalia-project.net/">Tor Controller</a>.</li>
|
96
|
|
-<li>Evaluate and document
|
97
|
|
-<a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">our
|
98
|
|
-list of programs</a> that can be configured to use Tor.</li>
|
99
|
|
-<li>We need better documentation for dynamically intercepting
|
100
|
|
-connections and sending them through Tor. tsocks (Linux), dsocks (BSD),
|
101
|
|
-and freecap (Windows) seem to be good candidates.</li>
|
102
|
|
-<li>We have a huge list of <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">potentially useful
|
103
|
|
-programs that interface to Tor</a>. Which ones are useful in which
|
104
|
|
-situations? Please help us test them out and document your results.</li>
|
105
|
|
-<li>Help translate the web page and documentation into other
|
106
|
|
-languages. See the <a href="<page translation>">translation
|
107
|
|
-guidelines</a> if you want to help out. We also need people to help
|
108
|
|
-maintain the existing Italian, French, and Swedish translations -
|
109
|
|
-see the <a href="<page translation-status>">translation status
|
110
|
|
-overview</a>.</li>
|
|
83
|
+<li>�� ���� ������ ��� ����������� Tor ����� ���� ������� ��� ������
|
|
84
|
+�����������, ���� �� ������ JavaScript, Java, ActiveX, Flash, ���. ���������
|
|
85
|
+�� ����-������ ������ (�� ������� NoScript ��� Firefox), ������� �������
|
|
86
|
+������������ �������� ���� ������. ���� ����� ����� � ���� �������?</li>
|
|
87
|
+<li>���������� �� ���� ������� ������� ����� �������� ������� Privoxy ���
|
|
88
|
+Firefox 1.5+? �� ������ ��� Tor ������ ������ �������, ���� �� �����������
|
|
89
|
+Privoxy ��� ����.</li>
|
|
90
|
+<li>�������� �������� Matt Edman � ������������ � �������� �
|
|
91
|
+<a href="http://vidalia-project.net/">Vidalia</a>.</li>
|
|
92
|
+<li>���������
|
|
93
|
+<a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">������
|
|
94
|
+�������</a> ������� ����� ����������� ����� Tor.</li>
|
|
95
|
+<li>�� ����� ������ ����������� �� ������������ ��������
|
|
96
|
+���������� � ������������ �� � Tor. ������� - tsocks (Linux), dsocks (BSD),
|
|
97
|
+� freecap (Windows).</li>
|
|
98
|
+<li>� �� ���� ������� ������
|
|
99
|
+<a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">
|
|
100
|
+������� ������� ����� ���� ��������� � ������� ��������� � Tor</a>.
|
|
101
|
+������� �� ��� � ���� ��������� �������� ����� ����������? �������� �������� ��
|
|
102
|
+��������� � ��������������� ���������.</li>
|
|
103
|
+<li>�������� ��������� ���-������� � ���������� � ������ �����.
|
|
104
|
+�������� <a href="<page translation>">���������� ��� ������������</a>
|
|
105
|
+���� �� ������ ������. �� ���� ����� ���, ����� ����������� � ���������
|
|
106
|
+��������� ����������, ���������� � �������� �������� - ��������
|
|
107
|
+<a href="<page translation-status>">������� ��������� ���������</a>.</li>
|
111
|
108
|
</ol>
|
112
|
109
|
|
113
|
110
|
<a id="Coding"></a>
|
114
|
|
-<h2><a class="anchor" href="#Coding">Coding and Design</a></h2>
|
|
111
|
+<h2><a class="anchor" href="#Coding">���������� � �������������</a></h2>
|
115
|
112
|
<ol>
|
116
|
|
-<li>Right now the hidden service descriptors are being stored on just a
|
117
|
|
-few directory servers. This is bad for privacy and bad for robustness. To
|
118
|
|
-get more robustness, we're going to need to make hidden service
|
119
|
|
-descriptors even less private because we're going to have to mirror them
|
120
|
|
-onto many places. Ideally we'd like to separate the storage/lookup system
|
121
|
|
-from the Tor directory servers entirely. The first problem is that we need
|
122
|
|
-to design a new hidden service descriptor format to a) be ascii rather
|
123
|
|
-than binary for convenience; b) keep the list of introduction points
|
124
|
|
-encrypted unless you know the <tt>.onion</tt> address, so the directory
|
125
|
|
-can't learn them; and c) allow the directories to verify the timestamp
|
126
|
|
-and signature on a hidden service descriptor so they can't be tricked
|
127
|
|
-into giving out fake ones. Second, any reliable distributed storage
|
128
|
|
-system will do, as long as it allows authenticated updates, but as far
|
129
|
|
-as we know no implemented DHT code supports authenticated updates.</li>
|
130
|
|
-<li>Tor exit servers need to do many DNS resolves in parallel. But
|
131
|
|
-gethostbyname() is poorly designed --- it blocks until it has finished
|
132
|
|
-resolving a query --- so it requires its own thread or process. So Tor
|
133
|
|
-is forced to spawn many separate DNS "worker" threads. There are some
|
134
|
|
-asynchronous DNS libraries out there, but historically they are buggy and
|
135
|
|
-abandoned. Are any of them stable, fast, clean, and free software? (Remember,
|
136
|
|
-Tor uses OpenSSL, and OpenSSL is (probably) not compatible with the GPL, so
|
137
|
|
-any GPL libraries are out of the running.) If so
|
138
|
|
-(or if we can make that so), we should integrate them into Tor. See <a
|
139
|
|
-href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">Agl's
|
140
|
|
-post</a> for one potential approach. Also see
|
141
|
|
-<a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> and
|
|
113
|
+<li>����� ����������� ������� �������� ������� ������ � ����������
|
|
114
|
+������� ����������. ��� ����� ��� ���������� � �ģ������. ����� ���������
|
|
115
|
+�ģ������ �� ������ ������ ����������� ������� �������� ����� ��������,
|
|
116
|
+�� �� �� ��������� ����������� �� �� ������ �����. � ����� ��� ��
|
|
117
|
+�������� �������� ������� �������/����� �� ���������� �������� Tor. �����
|
|
118
|
+������� � ���, ��� ��� �������� ����� ����� ������� ������������ �������
|
|
119
|
+��������, ������� ����� �) ���������� ������ ��������; �) ������
|
|
120
|
+������ introduction ����� �����������, ��� ���� ��� �� ���� <tt>.onion</tt>
|
|
121
|
+�����, �� ��� ������ ���������� �� ����� ����� ����������; �) ��������� �����������
|
|
122
|
+��������� ������� ������� � ������� ���������� ������� ��������, �����
|
|
123
|
+������ ���� ��������� ������ ����������. ��-������, �����ģ� ���
|
|
124
|
+�ģ��� �������̣��� ������ �������, �������� ������������������
|
|
125
|
+����������, �� �������� �� ����, �� ��� �� �������� DHT �� �����������
|
|
126
|
+���� ����������.</li>
|
|
127
|
+<li>��������� ���� Tor ������ ��������� ��������� DNS ������� ������������. ��
|
|
128
|
+gethostbyname() ������������ ������� ��� ���� ��������� --- ���������� �����������
|
|
129
|
+�� �������� ���������� ����� --- ������� ��������� �������� ��������� �����
|
|
130
|
+��� �������. ���� ������ Tor �������� ������� ����� ������� ��� DNS. �������,
|
|
131
|
+��������� ���������� ��������� ����������� DNS ������, �� �� ������������
|
|
132
|
+�������, ����������� �� ��� ����� � �� ������������� �����������. �� �� �����
|
|
133
|
+���-������ ��������� ��������, ������, ������ � �������� ����?
|
|
134
|
+(�������, Tor ���������� OpenSSL, � OpenSSL (��������) �� GPL-���������, �.�.
|
|
135
|
+��� GPL ���������� �� �������.). ���� ���� ����, �� ����� ������������ ��
|
|
136
|
+� Tor. ��������
|
|
137
|
+<a href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">���� ���� by Agl</a>
|
|
138
|
+� ������� �������. ���� �������
|
|
139
|
+<a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> �
|
142
|
140
|
<a href="http://www.monkey.org/~provos/libdnsres/">libdnsres</a>.
|
143
|
141
|
</li>
|
144
|
|
-<li>Tor 0.1.1.x includes support for hardware crypto accelerators via
|
145
|
|
-OpenSSL. Nobody has ever tested it, though. Does somebody want to get
|
146
|
|
-a card and let us know how it goes?</li>
|
147
|
|
-<li>Because Tor servers need to store-and-forward each cell they handle,
|
148
|
|
-high-bandwidth Tor servers end up using dozens of megabytes of memory
|
149
|
|
-just for buffers. We need better heuristics for when to shrink/expand
|
150
|
|
-buffers. Maybe this should be modelled after the Linux kernel buffer
|
151
|
|
-design, where you have many smaller buffers that link to each other,
|
152
|
|
-rather than monolithic buffers?</li>
|
153
|
|
-<li>Implement reverse DNS requests inside Tor (already specified in
|
154
|
|
-Section 5.4 of <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</li>
|
155
|
|
-<li>Perform a security analysis of Tor with <a
|
156
|
|
-href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determine
|
157
|
|
-if there are good fuzzing libraries out there for what we want. Win fame by
|
158
|
|
-getting credit when we put out a new release because of you!</li>
|
159
|
|
-<li>How hard is it to patch bind or a
|
160
|
|
-DNS proxy to redirect requests to Tor via our <a
|
161
|
|
-href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">tor-resolve
|
162
|
|
-socks extension</a>? dsocks already does this on BSD. What about to
|
163
|
|
-convert UDP DNS requests to TCP requests and send them through Tor?</li>
|
164
|
|
-<li>Tor uses TCP for transport and TLS for link
|
165
|
|
-encryption. This is nice and simple, but it means all cells
|
166
|
|
-on a link are delayed when a single packet gets dropped, and
|
167
|
|
-it means we can only reasonably support TCP streams. We have a <a
|
168
|
|
-href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">list
|
169
|
|
-of reasons why we haven't shifted to UDP transport</a>, but it would
|
170
|
|
-be great to see that list get shorter. We also have a proposed <a
|
171
|
|
-href="<svnsandbox>doc/tor-spec-udp.txt">specification for Tor and
|
172
|
|
-UDP</a> — please let us know what's wrong with it.</li>
|
173
|
|
-<li>We're not that far from having IPv6 support for destination addresses
|
174
|
|
-(at exit nodes). If you care strongly about IPv6, that's probably the
|
175
|
|
-first place to start.</li>
|
|
142
|
+<li>Tor 0.1.1.x ������ ��������� �������� ����������� ���������������� �������
|
|
143
|
+� ������ OpenSSL. �������, ����� ������ ��� �� ��������. ����� �� �����
|
|
144
|
+��������� Tor � ����� ������� � �������� ��?</li>
|
|
145
|
+<li>�� �� Tor �������� � ����� ���� ������ (cell) ��� ��������,
|
|
146
|
+������-���������� ������ ��������� ����� �����, ������ ��� ��������� ����
|
|
147
|
+���� �������. �� ����� �������� ������������� ��������, ������� ����������
|
|
148
|
+���� ������/�������� ������. ����� ���� ����� ����������� �������� �� ���
|
|
149
|
+Linux, ��� ����� �������� ������� �������� � ���� ����, ������ ����
|
|
150
|
+����� ����������� ���������� ������?</li>
|
|
151
|
+<li>��������� ������� DNS ������ ������ Tor (��� ������ �
|
|
152
|
+������ 5.4 � <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</li>
|
|
153
|
+<li>��������� ����� ����������� Tor � ������
|
|
154
|
+<a href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. ����������,
|
|
155
|
+��������� �� ���������� ����������.</li>
|
|
156
|
+<li>�������� ������ ��������� bind ��� DNS ������ ��� ��������� �������
|
|
157
|
+� Tor ����� ��
|
|
158
|
+<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">tor-resolve</a>?
|
|
159
|
+� BSD ��� ��� ������� � ������ dsocks. �� ��ޣ� ���� ����� �������������
|
|
160
|
+UDP DNS ������ � TCP ������ � ������� �� ����� Tor?</li>
|
|
161
|
+<li>Tor ���������� TCP � ����������� ������ � TLS ��� ���������
|
|
162
|
+����������. ��� ������ � ������, �� ��� ����� ��� ��� ������ (cell)
|
|
163
|
+�����������, ���� ���� ���� ����������, � ��� ����� ��� �� �����
|
|
164
|
+����������� ������ TCP ������. � �� ����
|
|
165
|
+<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
|
|
166
|
+������ ������ �� ������� �� �� ���������� UDP ��������</a>, �� ��������
|
|
167
|
+�� �������� ���� ������. � �� ���� ���� ���������
|
|
168
|
+<a href="<svnsandbox>doc/tor-spec-udp.txt">����������� ��� Tor � UDP</a>
|
|
169
|
+ — �������� �������� ���� � ��� ��� �� ��.</li>
|
|
170
|
+<li>�� ��� ������ � ��������� IPv6 ��� ������� �������� (� ���������
|
|
171
|
+����). ���� �� ���������� IPv6, ������ ����� ���� � ����� �����.</li>
|
176
|
172
|
</ol>
|
177
|
173
|
|
178
|
174
|
<a id="Research"></a>
|
179
|
|
-<h2><a class="anchor" href="#Research">Research</a></h2>
|
|
175
|
+<h2><a class="anchor" href="#Research">�����������</a></h2>
|
180
|
176
|
<ol>
|
181
|
|
-<li>The "website fingerprinting attack": make a list of a few
|
182
|
|
-hundred popular websites, download their pages, and make a set of
|
183
|
|
-"signatures" for each site. Then observe a Tor client's traffic. As
|
184
|
|
-you watch him receive data, you quickly approach a guess about which
|
185
|
|
-(if any) of those sites he is visiting. First, how effective is
|
186
|
|
-this attack on the deployed Tor codebase? Then start exploring
|
187
|
|
-defenses: for example, we could change Tor's cell size from 512
|
188
|
|
-bytes to 1024 bytes, we could employ padding techniques like <a
|
189
|
|
-href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>,
|
190
|
|
-or we could add traffic delays. How much of an impact do these have,
|
191
|
|
-and how much usability impact (using some suitable metric) is there from
|
192
|
|
-a successful defense in each case?</li>
|
193
|
|
-<li>The "end-to-end traffic confirmation attack":
|
194
|
|
-by watching traffic at Alice and at Bob, we can <a
|
195
|
|
-href="http://freehaven.net/anonbib/#danezis:pet2004">compare
|
196
|
|
-traffic signatures and become convinced that we're watching the same
|
197
|
|
-stream</a>. So far Tor accepts this as a fact of life and assumes this
|
198
|
|
-attack is trivial in all cases. First of all, is that actually true? How
|
199
|
|
-much traffic of what sort of distribution is needed before the adversary
|
200
|
|
-is confident he has won? Are there scenarios (e.g. not transmitting much)
|
201
|
|
-that slow down the attack? Do some traffic padding or traffic shaping
|
202
|
|
-schemes work better than others?</li>
|
203
|
|
-<li>The "routing zones attack": most of the literature thinks of
|
204
|
|
-the network path between Alice and her entry node (and between the
|
205
|
|
-exit node and Bob) as a single link on some graph. In practice,
|
206
|
|
-though, the path traverses many autonomous systems (ASes), and <a
|
207
|
|
-href="http://freehaven.net/anonbib/#feamster:wpes2004">it's not uncommon
|
208
|
|
-that the same AS appears on both the entry path and the exit path</a>.
|
209
|
|
-Unfortunately, to accurately predict whether a given Alice, entry,
|
210
|
|
-exit, Bob quad will be dangerous, we need to download an entire Internet
|
211
|
|
-routing zone and perform expensive operations on it. Are there practical
|
212
|
|
-approximations, such as avoiding IP addresses in the same /8 network?</li>
|
|
177
|
+<li>"��� �� �������� ���": ������ ������ ���������� �����
|
|
178
|
+���������� �����, ����� �� �������, � �������� ���� "�������"
|
|
179
|
+���� ������. ����� ����� ������ Tor, �� �������� �����,
|
|
180
|
+��ԣ� ������������ ������� ����� ��������� ������ � ���� ��
|
|
181
|
+���� ����� ����� ���������� ����������. ��-������, �������� ���������
|
|
182
|
+�� ��� ������ Tor? ����� ����� � ���� ������, ������ ��������� �����:
|
|
183
|
+������� ����� ��������� ����� ������ � 512 �� 1024 ���, ����� ���������
|
|
184
|
+������� ���������� (padding), ���� ��
|
|
185
|
+<a href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>,
|
|
186
|
+��� ����� ������ ������� �����. �� ��� �������� � ����, � �� ��� �������
|
|
187
|
+� ��������?
|
|
188
|
+<li>��� �� "���������� ���������� �����": ����� ����� ����� � ���,
|
|
189
|
+�� ����� <a href="http://freehaven.net/anonbib/#danezis:pet2004">�������
|
|
190
|
+�������� ����� � ��������� ��� �� ������ ���� �����</a>.
|
|
191
|
+� ����� ���� Tor �������� ���� ��� �� ������� � ��������, ���
|
|
192
|
+��� ��������� ���������� � ���� �����. ��-������, ������� �� ���
|
|
193
|
+���������. ������� ����� � ���� ������������� ��� ������ �����
|
|
194
|
+������ ������ ����� ���� ������ � ���������? ���� �� �������
|
|
195
|
+�������� ���� (����� ���� ��������� ���-�� ���������� ���������)?
|
|
196
|
+����� ���� ��������� ����� ���������� ��� ��������� ������� �����
|
|
197
|
+��� ���� ���� ������ ����� ��� ������?</li>
|
|
198
|
+<li>��� "�� ���� ������": � ����������� ��������� ����������� ���
|
|
199
|
+���� �� ����� � �������� ��� (� �� ��������� ��� � ����) ��� ���� �����
|
|
200
|
+� ��������� ����. � �������-��, ���� �������� ����� ��������� "����������
|
|
201
|
+������" (AS), �
|
|
202
|
+<a href="http://freehaven.net/anonbib/#feamster:wpes2004">
|
|
203
|
+�� ��� ��� ��� � � �� AS �� ����� ������ � �������� � ��������� ����</a>.
|
|
204
|
+� �������, ����� ���������� ����������� ����� ���������� ���ף��� �� �����,
|
|
205
|
+��������� ���, ����������, � ���, �� ������ ��������� ����� �������� ������
|
|
206
|
+�������� � ��������� ������ϣ���� �������. ��������� �� ����-������ �����������
|
|
207
|
+�����������, ������� �������� IP ����� � ��� �� /8 ����?</li>
|
213
|
208
|
<li>Tor doesn't work very well when servers have asymmetric bandwidth
|
214
|
209
|
(e.g. cable or DSL). Because Tor has separate TCP connections between
|
215
|
210
|
each hop, if the incoming bytes are arriving just fine and the outgoing
|
...
|
...
|
@@ -250,13 +245,13 @@ streams that a given server can see. But if we want each stream to be safe,
|
250
|
245
|
the "shortest" path should be at least 3 hops long by our current logic, so
|
251
|
246
|
the rest will be even longer. We need to examine this performance / security
|
252
|
247
|
tradeoff.</li>
|
253
|
|
-<li>It's not that hard to DoS Tor servers or dirservers. Are client
|
254
|
|
-puzzles the right answer? What other practical approaches are there? Bonus
|
255
|
|
-if they're backward-compatible with the current Tor protocol.</li>
|
|
248
|
+<li>����� �������� ������ �DoS��� ������ Tor ��� ������ �������.
|
|
249
|
+��������� ����� - ��� � ����� � ��������? ���� �ݣ �����������
|
|
250
|
+������� �� ������ ����������? ��������� ����� ��� ���� ���������� � �����������
|
|
251
|
+����������.</li>
|
256
|
252
|
</ol>
|
257
|
253
|
|
258
|
|
-<a href="<page contact>">Let us know</a> if you've made progress on any
|
259
|
|
-of these!
|
|
254
|
+<a href="<page contact>">�������� ��</a> ���� �� � ���� � ������!
|
260
|
255
|
|
261
|
256
|
</div><!-- #main -->
|
262
|
257
|
|
263
|
258
|
|