tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 12228

3) # Last-Translator: ruben at ugr es
4) 
5) #include "head.wmi" TITLE="Volunteer" CHARSET="UTF-8"
6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->
10) <h2>Tres cosas que todo el mundo puede hacer ahora:</h2>
11) <ol>

12) <li>Por favor considere <a href="<page docs/tor-doc-relay>">ejecutar
13) un repetidor</a> para ayudar a crecer a la red Tor.</li>
14) <li>¡Dígaselo a sus amigos! Consiga que ejecuten repetidores. Consiga que ejecuten 

15) servicios ocultos. Consiga que se lo digan a sus amigos.</li>
16) <li>Estamos buscando financiación y esponsors. Si le gustan los fines de Tor,
17) por favor <a href="<page donate>">tomese un momento para donar para apoyar 
18) el nuevo desarrollo de Tor</a>. Además, si conoce compañías, NGOs, agencias,
19) u otras organizaciones que quieran seguridad en las comunicaciones, hágales
20) saber de nosotros.</li>
21) </ol>
22) 
23) <a id="Usability"></a>
24) <h2><a class="anchor" href="#Usability">Soporte de Aplicaciones</a></h2>
25) <ol>
26) <li>Necesitamos buenas maneras de interceptar peticiones DNS para que 
27) no se filtre su petición a un observador local mientras intentamos ser
28) anónimos. (Esto pasa porque la aplicación hace la resolución DNS antes
29) de ir al proxy SOCKS.)</li>

30) <li>Asuntos de Tsocks/dsocks:

31) <ul>
32) <li>Necesitamos <a

33) href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">aplicar

34) todos nuestros parches de tsocks</a> y mantener un nuevo fork. Nosotros lo hospedaremos
35) si quiere.</li>
36) <li>Deberíamos parchear el programa "dsocks" de Dug Song para que use las 
37) órdenes <i>mapaddress</i> de Tor desde el interfaz de control, para que
38) no desperdiciemos un viaje de ida y vuelta dentro de Tor haciendo la
39) resolución antes de conectar.</li>
40) <li>Necesitamos hacer que nuestro script <i>torify</i> detecte cuál de tsocks o
41) dsocks está instalado, y llamarlos apropiadamente. Esto probablemente significa
42) unificar sus interfaces, y podria suponer compartir código entre ellos o 
43) descartar uno enteramente.</li>
44) </ul>

45) </li>

46) <li>La gente que ejecuta repetidores nos dice que quieren tener un BandwidthRate

47) durante una parte del día, y un BandwidthRate diferente en otras partes 
48) del día. Mejor que codificar esto dentro de Tor, deberíamos tener un pequeño
49) script que hable via el <a href="<page gui/index>">Interfaz de Control de Tor</a>,

50) y que use setconf para cambiar el ancho de banda usado. 
51) Hay uno ya para Unix y Mac (usa bash y cron), pero los usuarios de Windows
52) todavía necesitan una solución.

53) </li>
54) <li>Tor puede <a

55) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">salir

56) de la red Tor desde un nodo de salida particular</a>, pero deberiamos poder
57) especificar simplemente un país y que se elija uno automáticamente. Lo
58) mejor es obtener el directorio de Blossom también, y ejecutar un cliente
59) Blossom local que obtenga este directorio de forma segura (via Tor y comprobando
60) la firma), que intercepte hostnames <tt>.country.blossom</tt>, y que haga
61) lo correcto.</li>
62) <li>A propósito de datos de geolocalización, alguien debería dibujar un

63) mapa de la tierra con una marca para cada repetidor Tor. Bonus si se 

64) actualiza conforme la red crece y cambia. Desafortunadamente, las formas
65) fáciles de hacer esto es enviar todos los datos a Google y hacer que te
66) dibuje el mapa. ¿Cuánto impacto tiene esto en la privacidad, y tenemos 
67) alguna otra opción buena?</li>
68) </ol>
69) 
70) <a id="Documentation"></a>
71) <h2><a class="anchor" href="#Documentation">Documentación</a></h2>
72) <ol>
73) <li>Hemos oído que los usuarios de Tor pueden ser víctimas de ataques
74) que rompen el anonimato desde javascript, java, activex, flash, etc, 
75) si no los desactivan. ¿Existen plugins (como NoScript para Firefox) que
76) hagan más fácil a los usuarios controlar este riesgo? ¿Cuál es el riesgo
77) exactamente?</li>
78) <li>¿Hay un conjunto completo de plugins que reemplacen toda la funcionalidad
79) de Privoxy para Firefox 1.5+? Hemos oído que Tor es mucho más rápido cuando
80) sacas a Privoxy del conjunto.</li>
81) <li>Por favor ayude a Matt Edman con la documentación y howtos de su 
82) controlador Tor,
83) <a href="http://vidalia-project.net/">Vidalia</a>.</li>
84) <li>Evalúe y documente

85) <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">nuestra

86) lista de programas</a> que pueden ser configurados para usar Tor.</li>
87) <li>Necesitamos mejor documentación para interceptar dinámicamente conexiones
88) y enviarlas a través de Tor. tsocks (Linux), dsocks (BSD),
89) y freecap (Windows) parecen buenos candidatos, y también lo sería usar mejor
90) nuestra nueva característica de TransPort.</li>

91) <li>Tenemos una lista enorme de <a 
92) href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programas 
93) potentialmente útiles que son interfaz con Tor</a>. 

94) ¿Cuáles son útiles en cada situación? Por favor ayudenos a probarlos y 

95) documentar sus resultados.</li>

96) <li>Ayudenos a traducir la página web y la documentación a otros idiomas.
97) Vea las <a href="<page translation>">guías de traducción</a> si quiere ayudar.

98) Necesitamos especialmente traducciones al árabe o al farsi, para los muchos usuarios de Tor en áreas con censura.
99) </li>

100) </ol>
101) 
102) <a id="Coding"></a>
103) <h2><a class="anchor" href="#Coding">Codificación y Diseño</a></h2>
104) <ol>

105) <li>Los repetidores Tor no funcionan bien en Windows XP. En

106) Windows, Tor usa la llamada al sistema estandar <tt>select()</tt>,

107) que usa espacio en la zona no paginada. Esto significa que un repetidor

108) Tor de tamaño medio vaciará la zona no paginada, <a

109) href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">causando

110) el caos y colgando el sistema</a>. Probablemente deberíamos estar usando E/S
111) solapada en su lugar. Una solución sería enseñarle a <a
112) href="http://www.monkey.org/~provos/libevent/">libevent</a> a usar
113) E/S solapada en lugar de select() en Windows, y luego adaptar Tor a
114) la nueva interfaz de libevent.</li>

115) <li>Como los repetidores Tor tienen que almacenar-y-reenviar cada célula
116) que manejan, los repetidores Tor de gran ancho de banda terminan usando 

117) docenas de megabytes de memoria sólo para buffers. Necesitamos mejores 
118) heurísticas para cuándo encojer/expandir los buffers. ¿Quizás esto debería
119) de modelarse siguiendo el diseño de buffers del kernel de Linux, en donde
120) tenemos muchos buffers pequeños enlazados entre sí, en lugar de buffers 
121) monolíticos?</li>
122) <li>Necesitamos un sitio central oficial que responda preguntas del tipo 

123) "¿Es esta dirección IP un repetidor Tor de salida?". Debería dar varias

124) interfaces, incluyendo una interfaz web y una interfaz de estilo DNSBL.
125) Puede dar las respuestas más actualizadas guardando un mirror local de la

126) información del directorio Tor. Lo más lioso es que ser un repetidor de salida

127) no es un valor lógico: así que la pregunta es en realidad "¿Es esta 

128) dirección IP un repetidor Tor de salida que puede salir a mi dirección:puerto IP?"

129) El interfaz DNSBL recibirá probablemente cientos de peticiones por minuto,
130) así que se necesitan algoritmos inteligentes. Puntos de bonus si hace testing
131) activo a cada nodo de salida para averigura de qué direcciones IP está 
132) realmente saliendo.

133) <a href="<svnsandbox>doc/contrib/torel-design.txt">Lea más aquí</a>.</li>
134) <li>Algunas veces los repetidores Tor se cuelgan, o a los ordenadores en los

135) que están se les cae la red, u otros accidentes pasan. Algunos operadores Tor
136) han expresado un interes en inscribirse en un servidio "de notificación"

137) que compruebe periódicamente si sus repetidores Tor están saludables y 

138) les envíe un correo de recuerdo si no lo están. ¿Alguien quiere escribir
139) unos cuantos scripts cgi, unas cuantas páginas web, y configurar algún tipo
140) de hack con wget y/o algo más complejo como <a 
141) href="http://nagios.org/">Nagios</a> para hacer la monitorización? 
142) La primera versión podría comprobar sólo el puerto de directorio, e.g.
143) mirar la página de stado de la red cacheada para la dirección IP y el
144) puerto correctos y luego pedir la página "/tor/server/authority".</li>
145) <li>Sería estupendo tener un LiveCD que incluya las últimas versiones
146) de Tor, Polipo o Privoxy, Firefox, Gaim+OTR, etc. Hay dos retos aquí:
147) primero documentar el sistema y las elecciones lo suficientemente bien
148) para que la gente de seguridad pueda formarse una opinión sobre si debería
149) ser seguro, y la segunda es averiguar cómo hacerlo fácilmente mantenible,
150) para que no se quede obsoleto rápidamente como AnonymOS. Puntos de Bonus
151) si la imagen de CD cabe en uno de esos CDs de tamaño pequeño.</li>
152) <li>Relacionado con la imagen de LiveCD, deberíamos trabajar en una 
153) imagen USB que sea intuitivamente segura y bien documentada para Tor
154) y las aplicaciones de soporte. Bastante de la parte difícil es decidir 
155) qué configuraciones son seguras, documentar esas decisiones, y hacer
156) algo que sea fácil de mantener en el futuro.</li>
157) <li>Nuestro interfaz gráfico preferido para Tor, llamado
158) <a href="http://vidalia-project.net/">Vidalia</a>, necesita todo tipo
159) de trabajo de desarrollo.</li>
160) <li>Necesitamos constuir realmente nuestro <a href="<page
161) documentation>#DesignDoc">diseño de resistencia al bloqueo</a>. Esto incluye
162) rellenar el diseño, modificar muchas partes distintas de Tor, adaptar
163) <a href="http://vidalia-project.net/">Vidalia</a> para que soporte las
164) nuevas características, y planificar la implantación.</li>
165) <li>Necesitamos un entorno de simulación flexible para estudiar los
166) ataques de confirmación de tráfico de punta a punta. Muchos investigadores
167) han creado rápidamente simuladores ad-hoc para dar soporte a sus intuiciones
168) o bien de que los ataques funcionan muy bien o de que alguna defensa funciona 
169) bien. ¿Podemos construir un simulador que esté documentado claramente y 
170) lo suficientemente abierto para que todo el mundo sepa que está dando
171) una respuesta razonable? Esto generará mucha investigación nueva.
172) Vea la entrada <a href="#Research">debajo</a> sobre ataques de confirmación
173) para detalles sobre el aspecto de investigación de esta tarea &mdash; 
174) quién sabe, cuando esté hecho quizás usted pueda escribir un artículo o
175) varios también.</li>
176) <li>Necesitamos un estudio que mida <a
177) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
178) contra <a href="http://www.privoxy.org/">Privoxy</a>. ¿Es Polipo en
179) realidad significativamente más rápido, una vez que se tiene en cuenta
180) la ralentización debida a Tor? ¿Son los resultados los mismos tanto en Linux
181) como en Windows? Relacionado, ¿maneja Polipo más sitios web correctamente que
182) Privoxy, o vice versa? ¿Hay problemas de estabilidad en alguna plataforma 
183) común, e.g. Windows?</li>
184) <li>Relacionado con lo dicho arriba, ¿querría ayudar a portar <a
185) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> para que
186) se ejecute de forma estable y eficiente en Windows?</li>
187) <li>Necesitamos un entorno de test distribuido. Tenemos test de unidad,
188) pero sería excelente tener un script que arranque una red Tor, la use
189) durante un rato, y verifique que al menos parted de ella funcionan.
190) </li>
191) <li>Ayude a Mike Perry en su biblioteca <a

192) href="https://www.torproject.org/svn/torflow/">TorFlow</a>
193) (<a href="https://www.torproject.org/svn/torflow/TODO">TODO</a>):

194) Es una biblioteca python que usa el <a

195) href="https://www.torproject.org/svn/torctl/doc/howto.txt">protocolo de control de 

196) Tor</a> para indicar a Tor que construya circuitos de formas variadas,
197) y luego mide el rendimiento e intenta detectar anomalías.</li>
198) <!--
199) <li>Right now the hidden service descriptors are being stored on just a
200) few directory servers. This is bad for privacy and bad for robustness. To
201) get more robustness, we're going to need to make hidden service
202) descriptors even less private because we're going to have to mirror them
203) onto many places. Ideally we'd like to separate the storage/lookup system
204) from the Tor directory servers entirely. The first problem is that we need
205) to design a new hidden service descriptor format to a) be ascii rather
206) than binary for convenience; b) keep the list of introduction points
207) encrypted unless you know the <tt>.onion</tt> address, so the directory
208) can't learn them; and c) allow the directories to verify the timestamp
209) and signature on a hidden service descriptor so they can't be tricked
210) into giving out fake ones. Second, any reliable distributed storage
211) system will do, as long as it allows authenticated updates, but as far
212) as we know no implemented DHT code supports authenticated updates.</li>
213) -->
214) <li>Tor 0.1.1.x y posteriores incluyen soporte para aceleradores criptográficos 
215) hardware via OpenSSL. Sin embargo, nunca nadie los ha probado. ¿Alguien quiere
216) conseguir una tarjeta y decirnos cómo va?</li>
217) <li>Perform a security analysis of Tor with <a
218) href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determine
219) if there are good fuzzing libraries out there for what we want. Win fame by
220) getting credit when we put out a new release because of you!</li>
221) <li>Tor usa TCP para el transporte y TLS para encriptación del enlace.
222) Esto es bonito y simple, pero significa que todas las celdas de un enlace se
223) retrasan cuando se pierde un solo paquete, y significa que sólo podemos
224) permitir flujos TCP. Tenemos una <a

225) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">lista

226) de razones por las que no hemos cambiado a transporte UDP</a>, pero sería excelente
227) ver que esa lista se hace maś corta. También tenemos una propuesta de <a
228) href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">especificación
229) para Tor y UDP</a> &mdash; por favor díganos qué problemas tiene.</li>
230) <li>No estamos tan lejos de tener soporte IPv6 para las direcciones
231) de destino (en los nodos de salida). Si le importa mucho IPv6, ése es
232) probablemente el primer sitio para empezar.</li>
233) <li>¿No le gusta ninguna de éstas? Mire el <a
234) href="<svnsandbox>doc/design-paper/roadmap-2007.pdf">plan de desarrollo Tor</a> 
235) para más ideas.</li>
236) <li>¿No ve su idea aquí? ¡Probablemente la necesitemos de todas formas! 
237) Contáctenos y averígüelo.</li>
238) </ol>
239) 
240) <a id="Research"></a>
241) <h2><a class="anchor" href="#Research">Investigación</a></h2>
242) <ol>
243) <li>El "ataque de fingerprint de sitios web": hacer una lista de unos
244) cuantos cientos de sitios web populares, descargar sus páginas, y hacer
245) una serie de "firmas" para cada sitio. Entonces observar el tráfico de
246) un cliente Tor. Conforme lo observa recibiendo datos, rápidamente se 
247) puede adivinar cuál de esos sitios está visitando (si los visita). 
248) Primero, cómo de efectivo es este ataque en el código Tor? Después 
249) empezar a explorar defensas: por ejemplo, podríamos cambiar el tamaño
250) de celda de Tor desde 512 bytes a 1024, podríamos usar técnicas de
251) relleno como <a
252) href="http://freehaven.net/anonbib/#timing-fc2004">descarte defensivo</a>,
253) o podríamos añadir retrasos al tráfico. ¿Cuánto impacto tienen éstos,
254) y cuánto impacto en la usabilidad (usando alguna métrica adecuada) 
255) tiene una defensa exitosa en cada caso?</li>
256) <li>El "ataque de confirmación de tráfico de punta a punta":
257) mirando el tráfico de Alicia y de Bob, podemos<a
258) href="http://freehaven.net/anonbib/#danezis:pet2004">comparar
259) las firmas de tráfico y convencernos de que estamos mirando el mismo 
260) flujo</a>. Por ahora Tor acepta esto como un hecho consumado y asume que
261) este ataque es trivial en todos los casos. Lo primero de todo, ¿es eso
262) realmente cierto? ¿Cuánto tráfico de qué tipo de distribución se necesita
263) para que el adversario tenga confianza en que ha ganado? ¿Hay escenarios
264) (e.g. no transmitir mucho) que enlentecen el ataque? ¿Algunos esquemas
265) de relleno de tráfico o control de tráfico funcionan mejor que otros?
266) </li>
267) <li>El "ataque de las zonas de enrutado": la mayoría de la literatura
268) piensa en el camino en la red entre Alice y su nodo de entrada (y entre
269) el nodo de salida y Bob) como un enlace simple en algun grafo. En la 
270) práctica, sin embargo, el camino atraviesa muchos sistemas autónomos 
271) (ASes), y <a
272) href="http://freehaven.net/anonbib/#feamster:wpes2004">es común
273) que el mismo AS aparezca tanto en el camino de entrada como en el de salida</a>.
274) Desafortunadamente, para predecir con precisión si un cuádruple Alice, entrada,
275) salida, Bob será peligrosos, necesitamos descargar una zona de enrutado de Internet
276) entera y hacer operaciones caras en ella. ¿Hay aproximaciones prácticas, como
277) evitar direcciones IP en la misma red /8?</li>
278) <li>Otras preguntas de investigación sobre la diversidad geográfica consideran
279) la compensación entre elegir un circuito eficiente y elegir un circuito aleatorio.
280) Mire el <a
281) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">
282) artículo de posición</a> de Stephen Rollyson sobre cómo descartar elecciones
283) particularmente lentas sin dañar el anonimato "demasiado". Esta línea de
284) razonamiento necesita más trabajo y más ideas, pero parece muy prometedora.
285) </li>

286) <li>Tor no funciona muy bien cuando los repetidores tienen ancho de banda

287) asimétrico (e.g. cable o DSL). Como Tor tiene conexiones TCP separadas 
288) para cada salto, si los bytes de entrada llegan bien y los bits de salida
289) se están descartando todos, los mecanismos de ralentización de TCP no 
290) transmiten realmente esta información de vuelta a los flujos de entrada.
291) ¿Quizás Tor debería detectar cuándo está descartando muchos paquetes de 
292) salida, y limitar la velocidad de los flujos de entrada para regular esto
293) él mismo? Puedo imaginar un esquema de subida y bajada de la velocidad
294) en el que elegimos un límite conservativo, lo incrementamos despacio hasta
295) que se pierdan paquetes, lo bajamos y repetimos. Necesitamos alguien que
296) sea bueno con las redes para simular esto y ayudar a diseñar soluciones;
297) y/o necesitamos entender la extensión de la degradación del rendimiento,
298) y usar esto como motivación para reconsiderar el transporte UDP.</li>
299) <li>Un tema relacionado es el control de congestión. ¿Es nuestro
300) diseño actual suficiente una vez que tengamos un gran uso? Quizá
301) deberíamos experimentar con ventanas de tamaño variable en lugar
302) de ventanas de tamaño fijo? Eso pareció ir bien en un <a
303) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">experimento
304) de rendimiento de ssh</a>. Necesitaremos medir y hacer cambios, y quizás
305) reestructurar si los resultados son buenos.</li>
306) <li>Para permitir a disidentes de paises remotos usar Tor sin ser
307) bloqueados en el cortafuegos del país, necesitamos una forma de conseguir
308) cientos de miles de relays, no sólo unos cuantos cientos. Podemos imaginar
309) un GUI del cliente Tor que tenga un botón de "Tor para la Libertad" arriba
310) que abra un puerto y reenvie unos cuantos KB/s de tráfico a la red Tor. 
311) (Unos cuantos KB/s no deberían ser mucha molestia, y hay pocos casos de abuso
312) ya que no son nodos de salida.) ¿Pero cómo distribuimos una lista de estos 
313) clientes voluntarios a los disidentes buenos de un modo automático que no deje
314) a los cortafuegos a nivel de país interceptarlos y enumerarlos? Probablemente
315) necesite funcionar en el nivel de confianza entre humanos. Vea nuestro
316) <a href="<page documentation>#DesignDoc">documento de diseño inicial de 
317) resistencia al bloqueo</a> y nuestra
318) <a

319) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">entrada

320) de la FAQ</a> sobre esto, y luego lea la <a
321) href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sección
322) de restencia a la censura de anonbib</a>.</li>
323) <li>Los circuitos Tor se construyen un salto cada vez, así que en teoría tenemos
324) la habilidad de hacer que algunos flujos salgan del segundo salto, algunos del
325) tercero, y así sucesivamente. Esto parece bueno porque rompe el conjunto de

326) flujos de salida que un repetidor dado puede ver. Pero si queremos que cada flujo

327) esté seguro, el camino "más corto" debería ser al menos de 3 saltos de acuerdo con
328) nuestra lógica actual, así que el resto serán aún más largos. Necesitamos examinar
329) este intercambio forzado entre rendimiento y seguridad.</li>

330) <li>No es tan difícil hacer DoS a repetidores Tor o autoridades de directorio.

331) ¿Son los puzzles a los clientes la respuesta correcta? ¿Qué otros enfoques prácticos
332) hay? Bonus si son compatibles hacia atrás con el protocolo Tor actual.</li>
333) </ol>
334) 

335) ¡<a href="<page contact>">Háganoslo saber</a> si ha hecho progreso en algo