tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 12030

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-server>">ejecutar
13) un servidor</a> para ayudar a crecer a la red Tor.</li>
14) <li>¡Dígaselo a sus amigos! Consiga que ejecuten servidores. 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 servidores 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 servidor 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 href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programas potentialmente útiles que son interfaz con Tor</a>. 

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

93) documentar sus resultados.</li>

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

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

98) </ol>
99) 
100) <a id="Coding"></a>
101) <h2><a class="anchor" href="#Coding">Codificación y Diseño</a></h2>
102) <ol>
103) <li>Los servidores Tor no funcionan bien en Windows XP. En
104) Windows, Tor usa la llamada al sistema estandar <tt>select()</tt>,
105) que usa espacio en la zona no paginada. Esto significa que un servidor
106) Tor de tamaño medio vaciará la zona no paginada, <a

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

108) el caos y colgando el sistema</a>. Probablemente deberíamos estar usando E/S
109) solapada en su lugar. Una solución sería enseñarle a <a
110) href="http://www.monkey.org/~provos/libevent/">libevent</a> a usar
111) E/S solapada en lugar de select() en Windows, y luego adaptar Tor a
112) la nueva interfaz de libevent.</li>
113) <li>Como los servidores Tor tienen que almacenar-y-reenviar cada célula
114) que manejan, los servidores Tor de gran ancho de banda terminan usando 
115) docenas de megabytes de memoria sólo para buffers. Necesitamos mejores 
116) heurísticas para cuándo encojer/expandir los buffers. ¿Quizás esto debería
117) de modelarse siguiendo el diseño de buffers del kernel de Linux, en donde
118) tenemos muchos buffers pequeños enlazados entre sí, en lugar de buffers 
119) monolíticos?</li>
120) <li>Necesitamos un sitio central oficial que responda preguntas del tipo 
121) "¿Es esta dirección IP un servidor Tor de salida?". Debería dar varias
122) interfaces, incluyendo una interfaz web y una interfaz de estilo DNSBL.
123) Puede dar las respuestas más actualizadas guardando un mirror local de la
124) información del directorio Tor. Lo más lioso es que ser un servidor de salida
125) no es un valor lógico: así que la pregunta es en realidad "¿Es esta 
126) dirección IP un servidor Tor de salida que puede salir a mi dirección:puerto IP?"
127) El interfaz DNSBL recibirá probablemente cientos de peticiones por minuto,
128) así que se necesitan algoritmos inteligentes. Puntos de bonus si hace testing
129) activo a cada nodo de salida para averigura de qué direcciones IP está 
130) realmente saliendo.
131) <a href="<svnsandbox>doc/contrib/torbl-design.txt">Lea más aquí</a>.</li>
132) <li>Algunas veces los servidores Tor se cuelgan, o a los ordenadores en los
133) que están se les cae la red, u otros accidentes pasan. Algunos operadores Tor
134) han expresado un interes en inscribirse en un servidio "de notificación"
135) que compruebe periódicamente si sus servidores Tor están saludables y 
136) les envíe un correo de recuerdo si no lo están. ¿Alguien quiere escribir
137) unos cuantos scripts cgi, unas cuantas páginas web, y configurar algún tipo
138) de hack con wget y/o algo más complejo como <a 
139) href="http://nagios.org/">Nagios</a> para hacer la monitorización? 
140) La primera versión podría comprobar sólo el puerto de directorio, e.g.
141) mirar la página de stado de la red cacheada para la dirección IP y el
142) puerto correctos y luego pedir la página "/tor/server/authority".</li>
143) <li>Sería estupendo tener un LiveCD que incluya las últimas versiones
144) de Tor, Polipo o Privoxy, Firefox, Gaim+OTR, etc. Hay dos retos aquí:
145) primero documentar el sistema y las elecciones lo suficientemente bien
146) para que la gente de seguridad pueda formarse una opinión sobre si debería
147) ser seguro, y la segunda es averiguar cómo hacerlo fácilmente mantenible,
148) para que no se quede obsoleto rápidamente como AnonymOS. Puntos de Bonus
149) si la imagen de CD cabe en uno de esos CDs de tamaño pequeño.</li>
150) <li>Relacionado con la imagen de LiveCD, deberíamos trabajar en una 
151) imagen USB que sea intuitivamente segura y bien documentada para Tor
152) y las aplicaciones de soporte. Bastante de la parte difícil es decidir 
153) qué configuraciones son seguras, documentar esas decisiones, y hacer
154) algo que sea fácil de mantener en el futuro.</li>
155) <li>Nuestro interfaz gráfico preferido para Tor, llamado
156) <a href="http://vidalia-project.net/">Vidalia</a>, necesita todo tipo
157) de trabajo de desarrollo.</li>
158) <li>Necesitamos constuir realmente nuestro <a href="<page
159) documentation>#DesignDoc">diseño de resistencia al bloqueo</a>. Esto incluye
160) rellenar el diseño, modificar muchas partes distintas de Tor, adaptar
161) <a href="http://vidalia-project.net/">Vidalia</a> para que soporte las
162) nuevas características, y planificar la implantación.</li>
163) <li>Necesitamos un entorno de simulación flexible para estudiar los
164) ataques de confirmación de tráfico de punta a punta. Muchos investigadores
165) han creado rápidamente simuladores ad-hoc para dar soporte a sus intuiciones
166) o bien de que los ataques funcionan muy bien o de que alguna defensa funciona 
167) bien. ¿Podemos construir un simulador que esté documentado claramente y 
168) lo suficientemente abierto para que todo el mundo sepa que está dando
169) una respuesta razonable? Esto generará mucha investigación nueva.
170) Vea la entrada <a href="#Research">debajo</a> sobre ataques de confirmación
171) para detalles sobre el aspecto de investigación de esta tarea &mdash; 
172) quién sabe, cuando esté hecho quizás usted pueda escribir un artículo o
173) varios también.</li>
174) <li>Necesitamos un estudio que mida <a
175) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
176) contra <a href="http://www.privoxy.org/">Privoxy</a>. ¿Es Polipo en
177) realidad significativamente más rápido, una vez que se tiene en cuenta
178) la ralentización debida a Tor? ¿Son los resultados los mismos tanto en Linux
179) como en Windows? Relacionado, ¿maneja Polipo más sitios web correctamente que
180) Privoxy, o vice versa? ¿Hay problemas de estabilidad en alguna plataforma 
181) común, e.g. Windows?</li>
182) <li>Relacionado con lo dicho arriba, ¿querría ayudar a portar <a
183) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> para que
184) se ejecute de forma estable y eficiente en Windows?</li>
185) <li>Necesitamos un entorno de test distribuido. Tenemos test de unidad,
186) pero sería excelente tener un script que arranque una red Tor, la use
187) durante un rato, y verifique que al menos parted de ella funcionan.
188) </li>
189) <li>Ayude a Mike Perry en su biblioteca <a

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

192) Es una biblioteca python que usa el <a

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

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

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

224) de razones por las que no hemos cambiado a transporte UDP</a>, pero sería excelente
225) ver que esa lista se hace maś corta. También tenemos una propuesta de <a
226) href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">especificación
227) para Tor y UDP</a> &mdash; por favor díganos qué problemas tiene.</li>
228) <li>No estamos tan lejos de tener soporte IPv6 para las direcciones
229) de destino (en los nodos de salida). Si le importa mucho IPv6, ése es
230) probablemente el primer sitio para empezar.</li>
231) <li>¿No le gusta ninguna de éstas? Mire el <a
232) href="<svnsandbox>doc/design-paper/roadmap-2007.pdf">plan de desarrollo Tor</a> 
233) para más ideas.</li>
234) <li>¿No ve su idea aquí? ¡Probablemente la necesitemos de todas formas! 
235) Contáctenos y averígüelo.</li>
236) </ol>
237) 
238) <a id="Research"></a>
239) <h2><a class="anchor" href="#Research">Investigación</a></h2>
240) <ol>
241) <li>El "ataque de fingerprint de sitios web": hacer una lista de unos
242) cuantos cientos de sitios web populares, descargar sus páginas, y hacer
243) una serie de "firmas" para cada sitio. Entonces observar el tráfico de
244) un cliente Tor. Conforme lo observa recibiendo datos, rápidamente se 
245) puede adivinar cuál de esos sitios está visitando (si los visita). 
246) Primero, cómo de efectivo es este ataque en el código Tor? Después 
247) empezar a explorar defensas: por ejemplo, podríamos cambiar el tamaño
248) de celda de Tor desde 512 bytes a 1024, podríamos usar técnicas de
249) relleno como <a
250) href="http://freehaven.net/anonbib/#timing-fc2004">descarte defensivo</a>,
251) o podríamos añadir retrasos al tráfico. ¿Cuánto impacto tienen éstos,
252) y cuánto impacto en la usabilidad (usando alguna métrica adecuada) 
253) tiene una defensa exitosa en cada caso?</li>
254) <li>El "ataque de confirmación de tráfico de punta a punta":
255) mirando el tráfico de Alicia y de Bob, podemos<a
256) href="http://freehaven.net/anonbib/#danezis:pet2004">comparar
257) las firmas de tráfico y convencernos de que estamos mirando el mismo 
258) flujo</a>. Por ahora Tor acepta esto como un hecho consumado y asume que
259) este ataque es trivial en todos los casos. Lo primero de todo, ¿es eso
260) realmente cierto? ¿Cuánto tráfico de qué tipo de distribución se necesita
261) para que el adversario tenga confianza en que ha ganado? ¿Hay escenarios
262) (e.g. no transmitir mucho) que enlentecen el ataque? ¿Algunos esquemas
263) de relleno de tráfico o control de tráfico funcionan mejor que otros?
264) </li>
265) <li>El "ataque de las zonas de enrutado": la mayoría de la literatura
266) piensa en el camino en la red entre Alice y su nodo de entrada (y entre
267) el nodo de salida y Bob) como un enlace simple en algun grafo. En la 
268) práctica, sin embargo, el camino atraviesa muchos sistemas autónomos 
269) (ASes), y <a
270) href="http://freehaven.net/anonbib/#feamster:wpes2004">es común
271) que el mismo AS aparezca tanto en el camino de entrada como en el de salida</a>.
272) Desafortunadamente, para predecir con precisión si un cuádruple Alice, entrada,
273) salida, Bob será peligrosos, necesitamos descargar una zona de enrutado de Internet
274) entera y hacer operaciones caras en ella. ¿Hay aproximaciones prácticas, como
275) evitar direcciones IP en la misma red /8?</li>
276) <li>Otras preguntas de investigación sobre la diversidad geográfica consideran
277) la compensación entre elegir un circuito eficiente y elegir un circuito aleatorio.
278) Mire el <a
279) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">
280) artículo de posición</a> de Stephen Rollyson sobre cómo descartar elecciones
281) particularmente lentas sin dañar el anonimato "demasiado". Esta línea de
282) razonamiento necesita más trabajo y más ideas, pero parece muy prometedora.
283) </li>
284) <li>Tor no funciona muy bien cuando los servidores tienen ancho de banda
285) asimétrico (e.g. cable o DSL). Como Tor tiene conexiones TCP separadas 
286) para cada salto, si los bytes de entrada llegan bien y los bits de salida
287) se están descartando todos, los mecanismos de ralentización de TCP no 
288) transmiten realmente esta información de vuelta a los flujos de entrada.
289) ¿Quizás Tor debería detectar cuándo está descartando muchos paquetes de 
290) salida, y limitar la velocidad de los flujos de entrada para regular esto
291) él mismo? Puedo imaginar un esquema de subida y bajada de la velocidad
292) en el que elegimos un límite conservativo, lo incrementamos despacio hasta
293) que se pierdan paquetes, lo bajamos y repetimos. Necesitamos alguien que
294) sea bueno con las redes para simular esto y ayudar a diseñar soluciones;
295) y/o necesitamos entender la extensión de la degradación del rendimiento,
296) y usar esto como motivación para reconsiderar el transporte UDP.</li>
297) <li>Un tema relacionado es el control de congestión. ¿Es nuestro
298) diseño actual suficiente una vez que tengamos un gran uso? Quizá
299) deberíamos experimentar con ventanas de tamaño variable en lugar
300) de ventanas de tamaño fijo? Eso pareció ir bien en un <a
301) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">experimento
302) de rendimiento de ssh</a>. Necesitaremos medir y hacer cambios, y quizás
303) reestructurar si los resultados son buenos.</li>
304) <li>Para permitir a disidentes de paises remotos usar Tor sin ser
305) bloqueados en el cortafuegos del país, necesitamos una forma de conseguir
306) cientos de miles de relays, no sólo unos cuantos cientos. Podemos imaginar
307) un GUI del cliente Tor que tenga un botón de "Tor para la Libertad" arriba
308) que abra un puerto y reenvie unos cuantos KB/s de tráfico a la red Tor. 
309) (Unos cuantos KB/s no deberían ser mucha molestia, y hay pocos casos de abuso
310) ya que no son nodos de salida.) ¿Pero cómo distribuimos una lista de estos 
311) clientes voluntarios a los disidentes buenos de un modo automático que no deje
312) a los cortafuegos a nivel de país interceptarlos y enumerarlos? Probablemente
313) necesite funcionar en el nivel de confianza entre humanos. Vea nuestro
314) <a href="<page documentation>#DesignDoc">documento de diseño inicial de 
315) resistencia al bloqueo</a> y nuestra
316) <a

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