I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

central frog

Browse Source
This commit is contained in:
magma
2011-04-13 14:30:01 +00:00
parent b8264666f8
commit 16f696690e
1 changed files with 26 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
www.i2p2/pages/how_threatmodel_fr.html
View File

@@ -502,37 +502,34 @@ en <a href="how_networkdatabase.html#threat">détail</a>sur sur la page de la ba
<h3 id="central">Central Resource Attacks</h3>
<h3 id="central">Attaques de ressources centrales</h3>
<p>
There are a few centralized or limited resources (some inside I2P, some not)
that could be attacked or used as a vector for attacks.
The absence of jrandom starting November 2007, followed by the loss of the i2p.net hosting service in January 2008,
highlighted numerous centralized resources in the development and operation of the I2P network,
most of which are now distributed.
Attacks on externally-reachable resources mainly affect the ability of new users to find us,
not the operation of the network itself.
Il y a peu de ressources centrales susceptibles d'attaques ou d'y contribuer en tant que vectrices. L'absence de
jrandom depuis novembre 2007, suivie de la perte du service d'hébergement de i2p.net en janvier 2008 ont mis en lumière
les nombreuses ressources centralisées utilisées dans le développement et le fonctionnement d'I2P. La plupart d'entre
elles sont maintenant décentralisées. Des attaques contre des ressources accessibles de l'extérieur affecteraient la
facilité avec laquelle les nouveaux utilisateurs peuvent nous rejoindre, mais pas le fonctionnement du réseau lui-même.
<ul>
<li>The <a href="/">website</a> is mirrored and uses DNS round-robin for external public access.
<li>Routers now support <a href="faq.html#reseed">multiple external reseed locations</a>,
however more reseed hosts may be needed, and the handling of unreliable or malicious
reseed hosts may need improvement.
<li>Routers now support multiple update file locations.
A malicious update host could feed a huge file, need to limit the size.
<li>Routers now support multiple default trusted update signers.
<li>Routers now better handle <a href="#ffdos">multiple unreliable floodfill peers</a>.
Malicious floodfills <a href="#ffdos">needs</a> <a href="#floodfill">more</a> study.
<li>The code is now stored in a <a href="monotone.html">distributed source control system</a>.
<li>Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host.
A malicious news host could feed a huge file, need to limit the size.
<li><a href="naming.html">Naming system services</a>, including addressbook subscription providers, add-host services,
and jump services, could be malicious. Substantial protections for subscriptions were implemented
in release 0.6.1.31, with additional enhancements in subsequent releases.
However, all naming services require some measure of trust, see
<a href="naming.html">the naming page</a> for details.
<li>We remain reliant on the DNS service for i2p2.de, losing this would cause substantial
disruption in our ability to attract new users,
and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did.
</ul>
<li>Le <a href="/">site web</a> dispose de miroirs et utilise le round-robin DNS pour l'accès public externe.
<li>Les routeurs supportent maintenant des <a href="faq_fr.html#reseed">sources de réamorçage multiples</a>, mais plus
d'hôtes de réamorçage pourraient devenir nécessaires, et la gestion de ceux d'entre eux qui seraient peu fiables ou
carrément vénéneux devrait faire l'objet d'améliorations.
<li>Les routeurs supportent aussi plusieurs lieux de mise à jour. Un hôte de mise à jour vérolé pourrait délivrer un
fichier énorme, il nous faut limiter la taille.
<li>Les routeurs supportent maintenant par défaut de multiples signataires de mise à jour.
<li>Ils ont aussi une meilleure gestion des <a href="#ffdos">multiples pairs diffuseurs non fiables</a>. Le problème
des diffuseurs hostiles doit faire l'<a href="#ffdos">objet</a> d'une étude <a href="#floodfill">supplémentaire</a>.
<li>Le code est maintenant stocké dans un <a href="monotone.html">système de contrôle de versions décentralisé</a>.
<li>Les routeurs se reposent sur un seul hôte pour les news, mais il y a une URL de secours codée en dur qui pointe sur
autre hôte. Un hôte corrompu pourrait fourguer un fichier monstrueux, il nous faut verrouiller ça.
<li>Les <a href="naming.html">services systèmes de nommage</a>, dont les fournisseurs d'abonnements du carnet
d'adresses, les services d'ajout d'hôtes et les services de saut pourraient être corrompus. Des protections
conséquentes pour les abonnements on été mises en place dans la version 0.6.1.31, avec d'autres améliorations dans les
versions suivantes. Cependant, tous les services de nommage ont besoin de quelque mesure de confiance. Voir les détails
dans la page sur le <a href="naming.html">nommage</a>.
<li>Nous restons dépendants de DNS pour le domaine i2p2.de, et sa défaillance pourrait causer une perte substantielle à
notre capacité d'attirer de nouveaux utilisateurs, et pourrait restreindre le réseau à court et moyen terme comme le
fit la perte d'i2p.net.</ul>
<h3 id="dev">Development attacks</h3>