tor-webwml.git

@@ -1,6 +1,6 @@

 ## translation metadata

-# Based-On-Revision: 8055

-# Last-Translator: isydor@no-log.org

+# Based-On-Revision: 8183

+# Last-Translator: eightone_18@yahoo.co.uk

 #include "head.wmi" TITLE="Contribuer"

@@ -9,16 +9,16 @@

 <!-- PUT CONTENT AFTER THIS TAG -->

 <h2>Quatre choses que vous pouvez faire :</h2>

 <ol>

-<li> Pensez � <a href="<page docs/tor-doc-server>">h�berger un serveur</a> pour aider la croissance du r�seau Tor.</li>

+<li> Pensez � <a href="<page docs/tor-doc-server>">h�berger un serveur</a> pour aider � la croissance du r�seau Tor.</li>

 <li> Jetez un oeil � <a href="<page gui/index>">la comp�tition d'interfaces graphiques pour Tor</a>, et contribuez � am�liorer l'interface et l'ergonomie de Tor. Un t-shirt est offert pour chaque proposition !</li>

 <li> Informez vos ami-e-s ! Faites-leur h�berger des serveurs. Faites-leur utiliser les services cach�s. Encouragez-les � informer leurs propres ami-e-s.</li>

-<li> Nous recherchons des fonds et des m�c�nes. Si vous adh�rez aux objectifs de Tor,<a href="<page donate>"> prenez s'il vous pla�t un moment pour faire un don et aider les prochains d�veloppements de Tor</a>. Et si vous connaissez des entreprises, des ONGs, ou d'autres organisations qui souhaitent utiliser des communications s�curis�es, parlez-leur de nous.</li>

+<li> Nous recherchons des fonds et des m�c�nes. Si vous adh�rez aux objectifs de Tor, prenez s'il-vous-pla�t un moment <a href="<page donate>">pour faire un don et aider aux d�veloppements futurs de Tor</a>. De m�me, si vous connaissez des entreprises, des ONGs, ou d'autres organisations qui souhaitent utiliser des communications s�curis�es, parlez-leur de nous.</li>

 </ol>

 <a id="Bugs"></a>

 <h2><a class="anchor" href="#Bugs">Bugs critiques</a></h2>

 <ol>

-<li>Les serveurs Tor ne sont actuellement pas stables sous WindowsXP, car nous essayons d'utiliser des centaines de sockets alors que le noyau de Windows ne semble pas capable de faire �a. <a href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems"> S'il vous pla�t, aidez-nous � r�soudre ce probl�me !</a>La meilleure solution consiste certainement � apprendre � libevent � utiliser des E/S chevauchantes plut�t que select() sous Windows, puis � adapter Tor pour cette nouvelle interface de libevent.</li>

+<li>Les serveurs Tor ne sont actuellement pas stables sous Windows XP, car nous essayons d'utiliser des centaines de sockets alors que le noyau de Windows ne semble pas capable de le faire. <a href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems"> Aidez-nous � r�soudre ce probl�me !</a>La meilleure solution consiste certainement � apprendre � libevent � utiliser des E/S chevauchantes plut�t que select() sous Windows, puis � adapter Tor pour cette nouvelle interface de libevent.</li>

 </ol>

 <!--

@@ -36,19 +36,19 @@ href="http://freehaven.net/~edmanm/torcp/download.html"> installeur pour Windows

 <a id="Usability"></a>

 <h2><a class="anchor" href="#Usability">Support d'applications</a></h2>

 <ol>

-<li>Nous avons besoin d'un moyen d'intercepter les requ�tes DNS de sorte qu'elles ne laissent pas filtrer d'informations � un observateur local pendant que nous tentons d'�tre anonymes. (Ce qui arrive lorsque l'application fait sa r�solution DNS avant de passer par le proxy SOCKS.)

+<li>Nous avons besoin de m�thodes efficaces d'interception des requ�tes DNS, de sorte qu'elles ne laissent pas filtrer d'informations � un observateur local pendant que nous tentons d'�tre anonymes. (Ce qui arrive lorsque l'application fait sa r�solution DNS avant de passer par le proxy SOCKS.)

 <!-- 

 Une possibilit� est d'utiliser le support int�gr� � Tor pour ces r�solutions DNS; mais il est n�cessaire de faire l'appel en utilisant notre nouvelle extension � socks, et aucune application ne le fait encore. Une meilleure solution consiste en l'utilisation de l'interface de contr�le de Tor, qui intercepte la r�solution DNS, la transmet � Tor, qui r�pond avec une adresse IP bidon. Lorsque l'application fait une connexion via Tor � cette adresse IP bidon, Tor la renvoie directement � la requ�te initiale.

 -->

 <ul>

 <li>Nous avons besoin <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">d'appliquer nos patchs � tsocks</a> et d'en maintenir un nouveau fork. Nous l'h�bergerons si vous le souhaitez.</li>

 </li>

-<li>Nous devrions patcher le programme "dsocks" d�velopp� par Dug Song pour utiliser les commandes <i>mapaddress</i> de Tor depuis l'interface de contr�le, de mani�re � ne pas perdre un aller-retour complet dans Tor � faire la r�solution avant la connexion.</li>

+<li>Nous devrions patcher le programme "dsocks" d�velopp� par Dug Song pour utiliser les commandes <i>mapaddress</i> de Tor depuis l'interface de contr�le, de mani�re � ne pas faire inutilement un aller-retour complet dans Tor pour faire la r�solution avant la connexion.</li>

 <li>Notre script <i>torify</i> doit d�tecter lequel de tsocks ou dsocks est install� pour l'appeler correctement. Cela n�cessite certainement d'unifier leurs interfaces, et peut amener � faire un mix des deux voire � en �liminer un des deux.</li>

 </ul>

-<li>Les gens qui h�bergent des serveurs nous signalent qu'ils aimeraient avoir des taux variables selon les moments de la journ�e. Plut�t que de coder �a dans Tor, nous aimerions utiliser un petit script qui communique avec <a href="<page gui/index>">l'interface de contr�le de Tor</a>, et ferait un setconf pour changer la largeur de la bande passante. Potentiellement ce serait un script lanc� par cron, ou se lancerait � certains heures (ce qui est certainement plus portable). Est-ce que quelqu'un pourrait faire �a pour nous, nous l'ajouterons � <a href="<cvssandbox>tor/contrib/">tor/contrib/</a>? C'est une bonne entr�e pour la <a href="<page gui/index>"> comp�tition pour l'interface graphique de Tor</a>.</li>

-<li>Tor peut <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit"> quitter le r�seau Tor depuis un noeud de sorte donn�</a>, mais ce serait pratique de n'avoir qu'� sp�cifier un pays, et que le serveur de sortie soit choisi automatiquement. Le meilleur plan est de r�cup�rer le r�pertoire de Blossom, et d'utiliser un client local qui r�cup�re ce r�pertoire de mani�re s�re (via Tor et en v�rifiant sa signature), lise les noms des machines <tt>.country.blossom</tt> et fasse ce qu'il faut ensuite.</li>

-<li>En parlant de localisation g�ographique, quelqu'un devrait faire une carte de la Terre avec un point pour chaque serveur Tor. Il y a des points de bonus si elle se met � jour dynamiquement � mesure que le r�seau Tor �volue et grandit. Malheureusement, les moyens ais�s de faire cela passent par l'envoi de toutes les donn�es � Google pour qu'il trace cette carte pour vous. Dans quelle mesure est-ce que �a jouerait sur la confidentialit�, et par ailleurs avons-nous d'autres choix valables ?</li>

+<li>Les gens qui h�bergent des serveurs nous signalent qu'ils aimeraient pouvoir ajuster la bande passante allou�e en fonction des moments de la journ�e. Plut�t que de coder ceci dans Tor, nous aimerions utiliser un petit script qui communique avec <a href="<page gui/index>">l'interface de contr�le de Tor</a>, et ferait un setconf pour changer la valeur de la bande passante. �ventuellement, ce pourrait �tre un script lanc� par cron, ou qui se lancerait � certaines heures (ce qui est certainement plus portable). Quelqu'un pourrait-il �crire cela pour nous, nous l'ajouterons � <a href="<svnsandbox>tor/contrib/">tor/contrib/</a>? C'est une bonne entr�e pour la <a href="<page gui/index>"> comp�tition pour l'interface graphique de Tor</a>.</li>

+<li>Tor peut <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit"> quitter le r�seau Tor par un noeud de sorte choisi par l'utilisateur</a>, mais il serait pratique de n'avoir qu'� sp�cifier un pays, et que le serveur de sortie soit choisi automatiquement. Le meilleur moyen est probablement de r�cup�rer le r�pertoire de Blossom, et d'utiliser en local un client qui r�cup�re ce r�pertoire de mani�re s�re (via Tor et en v�rifiant sa signature), lise les noms des machines <tt>.country.blossom</tt> et se charge ensuite de choisir le serveur.</li>

+<li>En parlant de g�olocalisation, quelqu'un devrait faire une carte de la Terre indiquant chaque serveur Tor par un point. La cerise sur le g�teau serait la mise � jour dynamique de la carte � mesure que le r�seau Tor �volue et grandit. Malheureusement, les moyens ais�s de faire cela passent par l'envoi de toutes les donn�es � Google pour qu'il trace cette carte pour vous. Dans quelle mesure cela jouerait-il sur la confidentialit�, et par ailleurs, existe-t-il des solutions de remplacement valables ?</li>

 </ol>

 <!--

@@ -63,10 +63,9 @@ pour plus de d

 <a id="Documentation"></a>

 <h2><a class="anchor" href="#Documentation">Documentation</a></h2>

 <ol>

-<li>Nous avons des retours d'utilisateurs de Tor qui sont victimes d'attaques contre leur anonymat � l'aide de javascript, java, activex, flash, etc, s'ils ne les d�sactivent pas. Est-ce qu'il existe des greffons (comme NoScript pour Firefox) qui rendent la gestion de ce risque plus facile pour les utilisateurs ? Et quel est ce risque exactement ?

-</li>

-<li>

-S'il vous pla�t, aidez Matt Edman a documenter et faire des how-tos pour son <a href="http://vidalia-project.net/">Contr�leur pour Tor</a>.

+<li>Nous avons des retours d'utilisateurs de Tor qui sont victimes d'attaques contre leur anonymat � cause de javascript, java, activex, flash, etc, s'ils ne pensent pas � les d�sactiver. Existe-t-il des greffons (comme le plugin NoScript pour Firefox) qui rendent la gestion de ce risque plus facile pour les utilisateurs ? Et quel est ce risque exactement ?</li>

+<li>Existerait-il un ensemble de plugins qui remplacerait la totalit� des fonctions de Privoxy lorsqu'il est utilis� avec Firefox 1.5+ ? Il semblerait que Tor soit bien plus performant si l'on enl�ve Privoxy du circuit.</li></li>

+<li>Aidez Matt Edman � documenter et � �crire des tutoriaux pour son <a href="http://vidalia-project.net/">Contr�leur pour Tor</a>.

 </li>

 <!-- 

@@ -76,10 +75,10 @@ S'il vous pla

 <li>Est-ce que quelqu'un pourrait aider Matt Edman pour la documentation et le howto de son <a href="http://freehaven.net/~edmanm/torcp/">Contr�leur pour Tor sous Windows</a>?</li>

 -->

-<li>�valuez et documentez <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">les programmes de la liste que nous avons dress�e et qui contient</a> ceux qui peuvent �tre configur�s pour utiliser Tor.</li>

-<li>Nous avons besoin d'une meilleure documentation traitant de l'interception dynamique de connexions et leur envoi � travers Tor. tsocks (Linux), dsocks (BSD),et freecap (Windows) semblent �tre de bons candidats.</li>

-<li>Nous avons une liste gigantesque de <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">programmes potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles et dans quelles situations ? Aidez-nous s'il vous pla�t � les tester et � documenter les r�sultats.</li>

-<li>Aidez-nous � traduire le site et la documentation dans d'autres langues. Allez voir <a href="<page translation>">r�gles de traduction</a> si vous voulez le faire. Nous avons besoin de personnes pour maintenir les versions existantes en Italien, Fran�ais et Su�dois - regardez la page <a href="<page translation-status>">d'�tat des traductions</a>.</li>

+<li>�valuez et documentez la liste des <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">programmes pouvant �tre utilis�s avec Tor</a>.</li>

+<li>Nous avons besoin d'une meilleure documentation traitant de l'interception dynamique de connexions et de leur envoi � travers Tor. tsocks (Linux), dsocks (BSD),et freecap (Windows) semblent �tre de bons candidats.</li>

+<li>Nous avons toute une liste de <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">programmes potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles et dans quelles situations ? Contribuez � les tester et � documenter les r�sultats.</li>

+<li>Aidez-nous � traduire le site et la documentation dans d'autres langues. Allez voir les <a href="<page translation>">conseils de traduction</a> si vous souhaitez le faire. Nous avons besoin de personnes pour maintenir � jour les versions existantes en italien, fran�ais et su�dois - regardez la page <a href="<page translation-status>">d'�tat des traductions</a>.</li>

 </ol>

 <a id="Coding"></a>

@@ -92,16 +91,18 @@ S'il vous pla

 href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">plusieurs correctifs</a> qui doivent �tre appliqu�s. Est-ce qu'une personne pourrait nous aider � les faire ajouter en amont, et sinon pourrait commencer une nouvelle branche tsocks ? Nous l'aiderons.</li>

 -->

-<li>Actuellement les descripteurs de services cach�s sont stock�s uniquement sur quelques serveurs de r�pertoires. C'est mauvais pour la protection des donn�es priv�es et pour la robustesse. Pour am�liorer la robustesse, nous allons devoir affaiblir encore la protection des donn�es sur les descripteurs de services cach�s en multipliant les miroirs des serveurs de rep�rtoires. Id�alement nous aimerions s�parer enti�rement le syst�me de stockage/recherche des serveurs de r�pertoires Tor. Le premier probl�me est que nous devons concevoir un nouveau format de description des services cach�s a) qui soit ascii plut�t que binaire pour en simplifier l'utilisation; b) qui garde chiffr�e la liste des points d'entr�e � moins que l'on connaisse l'adresse <tt>.onion</tt>, de sorte que le r�pertoire ne puisse les lister; et c) qui autorise les r�pertoires � v�rifier la date et la signature d'un descripteur de service cach� de sorte que ces r�pertoires ne puissent �tre bidouill�s pour en do

- nner des faux. Deuxi�mement, tout syst�me de stockage distribu� s�r conviendra, du moment qu'il permette des mises-�-jour authentifi�es. Mais pour autant qu'on le sache, aucune impl�mentation de DHT ne supporte de mises-�-jour authentif�es.</li>

+<li>Pour l'instant, les descripteurs de services cach�s sont stock�s sur un petit nombre de serveurs de r�pertoires seulement. Ceci est mauvais au niveau confidentialit� des donn�es priv�es et au niveau de la robustesse. Pour am�liorer la robustesse, nous allons affaiblir encore la protection des donn�es sur les descripteurs de services cach�s, car nous allons devoir multiplier les miroirs des serveurs de rep�rtoires. Id�alement, nous aimerions que le syst�me de stockage/recherche soit enti�rement s�par� des serveurs de r�pertoires Tor. Le premier probl�me est que nous devons concevoir un nouveau format de description des services cach�s 

+<ol type ="a">

+<li>qui soit ascii plut�t que binaire pour en simplifier l'utilisation; <li>qui garde chiffr�e la liste des points d'entr�e � moins que l'on ne connaisse l'adresse <tt>.onion</tt>, de sorte que le r�pertoire ne puisse les lister; et <li>qui autorise les r�pertoires � v�rifier la date et la signature d'un descripteur de service cach� de sorte que ces r�pertoires ne puissent �tre bidouill�s pour en do

+ nner des faux.</li></ol> Deuxi�mement, tout syst�me de stockage distribu� s�r conviendra, du moment qu'il permette des mises � jour authentifi�es. Mais pour autant qu'on le sache, aucune impl�mentation de DHT ne supporte de mises � jour authentif�es.</li>

-<li>Les serveurs de sortie Tor ont besoin de faire de nombreuses r�solutions DNS en parall�le. Mais gethostbyname() est mal con�u --- il se bloque en attendant d'avoir termin� la r�solution d'une requ�te --- ainsi il exige d'avoir son propre thread ou processus. Et Tor est forc� � avoir plusieurs threads d�di�s aux r�solutions DNS. Il y a bien quelques biblioth�ques DNS asynchrones par-ci par-l�, mais historiquement elles sont bugu�es et abandonn�es. Y en a-t-il qui soient stables, rapides, propres et libres (Rappelez-vous que Tor utilise OpenSSL, et que OpenSSL n'est (probablement) pas compatible avec la GPL, et donc que toute biblioth�que GPL est exclue.) Si c'est le cas (o� si nous pouvons faire en sorte que �a le soit), nous devrions les int�grer � Tor. Voir <a

-href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">le message de Agl</a> � propos d'une approche potentielle. Voir aussi

+<li>Les serveurs de sortie Tor ont besoin de faire de nombreuses r�solutions DNS en parall�le. Mais gethostbyname() est mal con�u --- il se bloque en attendant d'avoir termin� la r�solution d'une requ�te --- et donc, il exige d'avoir son propre thread ou processus. Et Tor est oblig� d'avoir plusieurs threads d�di�s aux r�solutions DNS. Il y a bien quelques biblioth�ques DNS asynchrones par-ci par-l�, mais historiquement elles sont bugu�es et abandonn�es. Y en a-t-il qui soient stables, rapides, propres et libres (Rappelez-vous que Tor utilise OpenSSL, et que OpenSSL n'est (probablement) pas compatible avec la GPL, et donc que toute biblioth�que GPL est exclue.) S'il en existe (ou si nous pouvons faire en sorte qu'il en existe), nous devrions les int�grer � Tor. Voir <a

+href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">le message de Agl</a> sur une approche possible. Voir aussi

 <a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> et

 <a href="http://www.monkey.org/~provos/libdnsres/">libdnsres</a>.

 </li>

-<li>Tor 0.1.1.x inclut le support d'acc�l�rateurs mat�riels de chiffrage via OpenSSL. Personne ne l'a jamais test�, cependant. Est-ce qu'une personne voudrait bien nous envoyer une carte pour nous dire ce qu'il en est ?</li>

-<li>Comme les serveurs Tor doivent stocker et renvoyer chaque unit� d'information trait�e, les serveurs Tor � haut d�bit finissent par utiliser des dizaines de Mo de m�moire rien que pour la m�moire tampon. Nous avons besoin de meilleures descriptions de son fonctionnement pour pr�voir ses variations de taille. Peut-�tre que �a peut se mod�liser � partir de la conception de la m�moire tampon du noyau Linux, dans lequel il y a de nombreuses petites m�moires li�es les unes aux autres, plut�t qu'avec des grosses m�moires monolithiques ?</li>

+<li>Tor 0.1.1.x inclut le support d'acc�l�rateurs mat�riels de chiffrage via OpenSSL. Cependant, personne ne l'a jamais test�. Est-ce que quelqu'un voudrait se procurer une carte et nous dire ce qu'il en est ?</li>

+<li>�tant donn� que les serveurs Tor doivent stocker et renvoyer chaque unit� d'information trait�e (cellule), les serveurs Tor � haut d�bit finissent par utiliser des dizaines de Mo de m�moire uniquement pour la m�moire tampon. Nous avons besoin de meilleures descriptions de fonctionnement pour pr�voir les variations de taille des tampons. Ceci pourrait peut-�tre ceci �tre mod�lis� � partir de la conception de la m�moire tampon du noyau Linux, dans lequel il y a de nombreuses petites m�moires li�es les unes aux autres, plut�t qu'avec des grosses m�moires monolithiques ?</li>

 <!--

 <li>D'ailleurs comment fonctionne ulimits sous win32 ? Nous avons des soucis, en particulier avec les anciennes versions de windows qui d�passent le nombre maximum de descripteurs de fichiers, la taille des m�moires de connexion, etc. (Nous devrions g�rer WSAENOBUFS comme n�cessaire, regarder l'entr�e du registre MaxConnections,

@@ -111,36 +112,36 @@ href="http://bugs.noreply.org/flyspray/index.php?do=details&id=98">le bug

 <li>Correctifs aux scripts autoconf de Tor. Premi�rement nous aimerions que notre autoconfigure.in sache faire de la cross-compilation, c'est � dire que nous sachions compiler Tor pour des plateformes obscures comme le Linksys WRTG54. Deuxi�mement, nous aimerions que l'option with-ssl-dir d�sactive la recherche des biblioth�ques ssl.</li>

 -->

-<li>Impl�menter les requ�tes de DNS inverses dans Tor (d�j� sp�cifi� dans la section 5.4 de <a href="<cvssandbox>tor/doc/tor-spec.txt">tor-spec.txt</a>).</li>

+<li>Impl�menter les requ�tes de DNS inverses dans Tor (d�j� sp�cifi� dans la section 5.4 de <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</li>

 <li>Faire une analyse de suret� de Tor avec <a

-href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. D�terminer s'il existe d�j� de bonnes biblioth�ques de fuzz pour ce que nous voulons faire. Deviens c�l�bre en �tant cit�-e pour la sortie d'une nouvelle version gr�ce � toi !</li>

-<li>Dans quelle mesure est-ce difficile de modifier bin ou un proxy DNS pour rediriger les requ�tes � Tor via notre <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">extension de socks : tor-resolve</a>? Que pensez-vous de l'id�e de convertir les requ�tes UDP DNS en requ�tes TCP et de les envoyer � travers Tor ?</li>

-<li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est simple et efficace, mais cela implique que toutes les unit�s d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie que nous ne pouvons raisonnablement supporter que des flux TCP. Nous avons dress� une <a

-href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP"> liste de raisons pour lesquelles nous n'avons pas bifurqu� vers le transport par UDP</a>, mais ce serait bien de voir cette liste diminuer de taille. Nous avons aussi propos� <a href="<cvssandbox>tor/doc/tor-spec-udp.txt">une sp�cification pour Tor et UDP</a> &mdash; critiquez-l� s'il vous pla�t.</li>

-<li>Nous ne sommes plus tr�s loin d'avoir le support pour IPV6 entre les serveurs de sorties et les adresses finales. Si vous tenez beaucoup � IPV6, commencez par aider sur ce sujet.</li>

+href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. D�terminer s'il existe d�j� de bonnes biblioth�ques de fuzz pour ce que nous voulons faire. La c�l�brit� pour celui-lle gr�ce � qui une nouvelle version pourra voir le jour !</li>

+<li>Dans quelle mesure est-ce difficile de modifier bind ou un proxy DNS pour rediriger les requ�tes � Tor via notre <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">extension de socks : tor-resolve</a>? Sous BSD, docks en est d�j� capable. Que pensez-vous de l'id�e de convertir les requ�tes UDP DNS en requ�tes TCP et de les envoyer � travers Tor ?</li>

+<li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est simple et efficace, mais cela implique que toutes les unit�s (cellules) d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie que seuls des flux TCP peuvent �tre raisonnablement support�s. Nous avons dress� une <a

+href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP"> liste de raisons pour lesquelles nous n'avons pas bifurqu� vers le transport par UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous avons aussi propos� <a href="<svnsandbox>tor/doc/tor-spec-udp.txt">une sp�cification pour Tor et UDP</a> &mdash; lisez-la et faites-nous part de vos remarques et critiques, s'il-vous-pla�t.</li>

+<li>Nous ne sommes plus tr�s loin d'avoir le support pour IPV6 entre les serveurs de sorties et les adresses finales. Si IPV6 vous tient � c�ur, partir de l� est sans doute un premier pas.</li>

 </ol>

 <a id="Research"></a>

 <h2><a class="anchor" href="#Research">Recherche</a></h2>

 <ol>

-<li>"L'attaque par empreinte de sites": Faire une liste de quelques centaines de sites populaires, en t�l�charger les pages, et faire des "signatures" pour chaque site. Ensuite, observer le trafic d'un client Tor. L'analyse de ses r�ceptions de donn�es donne rapidement une id�e des sites qu'il visite. Premi�rement, quelle est l'efficacit� de cette attaque sur le code actuellement utilis� dans Tor ? Ensuite essayer les d�fenses possibles : par exemple changer la taille des cellules de Tor de 512 octets � 1024, utiliser des techniques de remplissage comme <a

-href="http://freehaven.net/anonbib/#timing-fc2004">le l�cher d�fensif</a>, ou ajouter des d�lais de trafic. Quel impact ces strat�gies ont en d�fense et aussi sur la perte d'utilisabilit� (� quantifier) de Tor en prenant les cas o� la d�fense est efficace ?

+<li>"L'attaque par empreinte de sites": faire une liste de quelques centaines de sites populaires, en t�l�charger les pages, et faire des "signatures" pour chaque site. Ensuite, observer le trafic d'un client Tor. L'analyse de ses r�ceptions de donn�es donne rapidement une id�e des sites qu'il visite. Premi�rement, quelle est l'efficacit� de cette attaque sur le code actuellement utilis� dans Tor ? Ensuite, tester les d�fenses possibles : par exemple, changer la taille des cellules de Tor de 512 octets � 1024, utiliser des techniques de remplissage comme <a

+href="http://freehaven.net/anonbib/#timing-fc2004">le l�cher d�fensif</a>, ou ajouter des d�lais de trafic. Quel impact ces strat�gies de d�fense ont-elles, et, dans les cas o� elles sont efficaces en d�fense, quel impact ont-elles en terme de perte d'utilisabilit� de Tor (� quantifier) ?

 </li>

-<li>"L'attaque par comparaison des trafics aux extr�mit�s": Par l'observation des trafics de Alice et Bob, il est possible de <a

-href="http://freehaven.net/anonbib/#danezis:pet2004">comparer les signatures des trafics et d'en d�duire qu'il s'agit du m�me flux</a>. Jusqu'ici Tor accepte cela comme intrins�que et donc in�vitable. Tout d'abord, est-ce vrai ? Quelle quantit� de trafic - et avec quelle distribution - est n�cessaire avant que l'adversaire soit certain d'avoir gagn� ? Est-ce qu'il existe des sc�narios (par exemple avoir un trafic faible) pour ralentir cette attaque ? Est-ce que certains types de bourrage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>

-<li>"L'attaque par zones de routage" : Le plus souvent dans la litt�rature il est consid�r� que le chemin r�seau entre Alice et son noeud d'entr�e (et entre le noeud de sortie et Bob) est un lien unique dans un graphe. En pratique, cependant, le chemin passe par de nombreux syst�mes autonomes (Autonomous Systems : ASes), et <a

+<li>"L'attaque par corr�lation des trafics aux extr�mit�s": par l'observation des trafics de Alice et Bob, il est possible de <a

+href="http://freehaven.net/anonbib/#danezis:pet2004">comparer les signatures des trafics et d'en d�duire qu'il s'agit du m�me flux</a>. Jusqu'ici, Tor consid�re ce type d'attaque comme intrins�que et donc in�vitable. Tout d'abord, est-ce r�ellement vrai ? Quelle quantit� de trafic - et avec quelle distribution - est-elle n�cessaire pour que l'adversaire soit certain d'avoir gagn� ? Est-ce qu'il existe des sc�narios (par exemple avoir un trafic faible) pour ralentir cette attaque ? Est-ce que certains types de remplissage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>

+<li>"L'attaque par zones de routage" : la litt�rature sp�cialis�e consid�re le plus souvent que le chemin r�seau entre Alice et son noeud d'entr�e (et entre le noeud de sortie et Bob) comme un lien unique dans un graphe. En pratique, cependant, le chemin passe par de nombreux syst�mes autonomes (Autonomous Systems : ASes), et <a

 href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas inhabituel de retrouver le m�me AS sur les chemins d'entr�e et de sortie</a>.

-Malheureusement, pour pr�voir pr�cis�ment si le chemin "Alice, entr�e, sortie, Bob" sera dangereux, nous devrions t�l�charger une zone de routage internet compl�te et faire dessus des calculs lourds. Est-ce qu'il existe des approximations utilisables, comme d'ignorer les adresses IP d'un r�seau /8 ?</li>

-<li>Tor ne fonctionne pas tr�s bien lorsque les serveurs ont des bandes passantes assym�triques (par exemple c�ble ou DSL). Comme Tor a des connexions TCP s�par�es entre chaque saut, si les octets arrivent correctement mais que les octets sortants sont bloqu�s sur place, les m�canismes de refoulement de TCP ne retransmettent pas vraiment cette information aux flux entrants.

-Sans doute Tor devrait d�tecter lorsqu'il perd beaucoup de paquets sortants, et limiter la vitesse du flux entrant pour r�guler cela lui-m�me ?

-Je peux concevoir un sch�ma de type augmentation-descente dans lequel on choisit un d�bit "s�r", que l'on augmente jusqu'� perdre des paquets, puis redescend, puis r�augmente. Nous avons besoin de quelq'un-e de fort-e en r�seau pour simuler ce fonctionnement et aider � concevoir des solutions. De mani�re g�n�rale l'�valuation des pertes de performances d'un tel syst�me pourrait peut-�tre - dans le cas o� elles sont grandes - servir de motivation pour reconsid�rer la question du transport UDP.

-<li>Un sujet li� est le contr�le de congestion : Est-ce que notre syst�me actuel est suffisant pour un usage intensif ? Peut-�tre que nous devrions exp�rimenter des fen�tres de taille variable plut�t que de taille fixe ? �a a sembl� assez efficace pour cette <a

+Malheureusement, pour pr�voir pr�cis�ment si le chemin "Alice, entr�e, sortie, Bob" sera dangereux, nous devrions t�l�charger une zone de routage internet compl�te et faire dessus des calculs lourds. Est-ce qu'il existe des approximations utilisables, comme par exemple d'ignorer les adresses IP d'un r�seau /8 ?</li>

+<li>Tor ne fonctionne pas tr�s bien lorsque les serveurs ont des bandes passantes asym�triques (par exemple c�ble ou DSL). Comme Tor a des connexions TCP s�par�es entre chaque saut, si les octets arrivent correctement mais que les octets sortants sont bloqu�s sur place, les m�canismes de refoulement de TCP ne retransmettent pas vraiment cette information aux flux entrants.

+Peut-�tre Tor devrait-il d�tecter s'il perd beaucoup de paquets sortants, et limiter la vitesse du flux entrant pour r�guler cela lui-m�me ?

+Je peux concevoir un sch�ma de type augmentation-descente dans lequel on choisit un d�bit "s�r", que l'on augmente jusqu'� perdre des paquets, puis qui redescend, puis qui r�augmente. Nous avons besoin de quelq'un-e de fort-e en r�seau pour simuler ce fonctionnement et aider � concevoir des solutions. De mani�re g�n�rale, l'�valuation des pertes de performances d'un tel syst�me pourrait peut-�tre - dans le cas o� elles sont grandes - servir de motivation pour reconsid�rer la question du transport UDP.

+<li>Un sujet li� est le contr�le de congestion : notre syst�me actuel est-il suffisant pour un usage intensif ? Peut-�tre devrions-nous exp�rimenter des fen�tres de taille variable plut�t qu'� taille fixe ? C'est apparu assez efficace pour cette <a

 href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">exp�rience sur ssh</a>. Nous aurons � faire des mesures et des r�glages, et peut-�tre une r�vision de Tor si les r�sulats sont bons.</li>

-<li>Pour permettre � des dissident-e-s de se connecter sans �tre bloqu�-e-s par les pare-feu de leur pays, nous avons besoin de dizaines de milliers de relais et pas seulement de quelques centaines. Nous pourrions imaginer un client Tor graphique qui aurait un bouton "aidez la Chine" pour activer l'ouverture d'un port et le relai de quelques KB/s de trafic pour le r�seau Tor. (Quelques KB/s ne devraient pas �tre trop p�nibles et il y a peu de risque d'abus puisqu'il ne s'agirait pas de noeuds de sortie.) Mais comment distribuer la liste de ces clients aux bons dissidents de mani�re automatique tout en ne permettant pas aux pare-feux au niveau national de l'intercepter et de lister ces clients ? Probablement, il faut r�gler �a au niveau humain.

+<li>Pour permettre � des dissident-e-s de se connecter sans �tre bloqu�-e-s par les pare-feu de leur pays, nous avons besoin de dizaines de milliers de relais et pas seulement de quelques centaines. Nous pourrions imaginer un client Tor graphique qui aurait un bouton "aidez la Chine" pour activer l'ouverture d'un port et le relai de quelques KB/s de trafic pour le r�seau Tor. (Quelques KB/s ne devraient pas �tre trop p�nibles et il y a peu de risque d'abus puisqu'il ne s'agirait pas de noeuds de sortie.) Mais comment distribuer la liste de ces clients volontaires aux bons dissidents de mani�re automatique, tout en ne permettant pas aux pare-feux au niveau national de l'intercepter et de lister ces clients ? Probablement, il faut faire intervenir la confiance, au niveau humain.

 Voir notre <a

 href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China">entr�e dans la FAQ</a> � ce sujet, puis lire <a href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">la section sur la r�sistance � la censure de anonbib</a>.</li>

-<li>Les circuits Tor sont construits saut par saut, donc en th�orie nous pouvons faire sortir des flux lors du second saut, du troisi�me, etc. �a para�t bien car �a casse l'ensemble des flux sortants qu'un serveur peut voir. Mais si nous voulons que chaque flux soit s�r, le chemin "le plus court" devrait comporter au moins 3 sauts selon notre logique, et les sorties suivantes seront toutes plus lointaines. Nous devons �valuer ce rapport performance/s�ret�.</li>

-<li>Il n'est pas difficile de provoquer un DoS sur les serveur et les serveurs de r�pertoires Tor. Est-ce que les puzzles de clients sont la bonne r�ponse ? Qu'est-ce qu'il existe comme autres approches r�alisables ? Il y a un bonus si elles sont r�tro-compatibles avec le protocol actuel de Tor.</li>

+<li>Les circuits Tor sont construits saut par saut, donc en th�orie nous pouvons faire sortir des flux au second saut, au troisi�me, etc. Cela para�t bien car cassant l'ensemble des flux sortants qu'un serveur peut voir. Mais si nous voulons que chaque flux soit s�r, le chemin "le plus court" devrait comporter au moins 3 sauts dans notre logique actuelle, et les sorties suivantes seraient encore plus lointaines. Nous devons �valuer ce rapport performance/s�ret�.</li>

+<li>Il n'est pas difficile de provoquer un DoS sur les serveurs et les serveurs de r�pertoires Tor. Est-ce que les puzzles de clients sont la bonne r�ponse ? Existe-t-il d'autres approches r�alisables ? Il y a un bonus si elles sont r�tro-compatibles avec le protocol actuel de Tor.</li>

 </ol>

 <a href="<page contact>">Contactez-nous</a> si vous avez avanc� sur ces points !