La nouvelle branche stable de Tor 0.4.4.5 est maintenant disponible, connaissez ses changements les plus importants

Récemment la sortie de la nouvelle version stable de Tor 0.4.4.5 a été présentée, utilisé pour organiser le travail du réseau anonyme Tor. Tor 0.4.4.5 elle est considérée comme la première version stable de la branche 0.4.4, qui a évolué au cours des cinq derniers mois.

La branche 0.4.4 sera conservée dans le cadre du cycle d'entretien régulier; la publication des mises à jour sera interrompue après 9 mois (en juin 2021) ou 3 mois après la sortie de la branche 0.4.5.x.

De plus, un long cycle de support (LTS) est également prévu pour la branche 0.3.5, dont les mises à jour seront publiées jusqu'au 1er février 2022. Le support des 0.4.0.x, 0.2.9.x et 0.4.2 branches 0.4.1.x a été abandonnée. Le support de la branche 20.x sera interrompu le 0.4.3 mai et 15 le 2021 février XNUMX.

Pour ceux qui ne connaissent toujours pas le projet Tor (Le routeur à l'oignon). Il s'agit d'un projet dont l'objectif principal est le développement d'un réseau de communication distribué, à faible latence et superposé sur Internet dans lequel l'acheminement des messages échangés entre utilisateurs ne révèle pas leur identité, c'est-à-dire son adresse IP (anonymat au niveau du réseau) et qu'en plus, il préserve l'intégrité et la confidentialité des informations qui le traversent.

Le système est conçu avec la flexibilité nécessaire pour pouvoir mettre en œuvre des améliorations, être déployé dans le monde réel et résister à différents types d'attaques. Cependant, il présente des points faibles et ne peut être considéré comme un système infaillible.

Principales nouveautés de Tor 0.4.4.5

Cette nouvelle version de Tor est livré avec pas mal de changements et de correctifs, parmi eux, nous soulignons les plus importants tels que algorithme de sélection de nœud sentinelle amélioré, dans lequel le problème de l'équilibrage de charge, ainsi que l'amélioration de la productivité et de la sécurité.

Un autre changement majeur, est que la capacité d'équilibrer la charge des services d'oignon a été mise en œuvre. Puisqu'un service basé sur la troisième version du protocole peut désormais servir de backend pour OnionBalance, qui est configuré à l'aide de l'option HiddenServiceOnionBalanceInstance.

Il est également souligné que la liste des serveurs d'annuaire de rechange a été mise à jour, qui n'a pas été mise à jour depuis l'année dernière, et 105 des 148 serveurs restent opérationnels (la nouvelle liste comprend 144 entrées générées en juillet).

Dans les relais, il est permis de travailler avec des cellules EXTEND2 qui sont disponibles uniquement sur l'adresse IPv6, et l'extension de la chaîne sur IPv6 est également autorisée si le client et le relais prennent en charge IPv6.

Si, en étendant les chaînes de nœuds, une cellule est accessible simultanément via IPv4 et IPv6, alors l'adresse IPv4 ou IPv6 est choisie au hasard. La connexion IPv6 existante peut étendre la chaîne. L'utilisation d'adresses IPv4 et IPv6 internes est interdite.

Également augmenté la quantité de code qui peut être désactivée lors du démarrage de Tor sans prise en charge de relais.

En outre, aussi la gestion correcte des paramètres pour la défense DoS du service oignon est mentionnée. Eh bien, auparavant, les paramètres de consensus pour les défenses DoS du service écrasaient les paramètres définis par l'opérateur de service via HiddenServiceEnableIntroDoSDefense.

Une autre correction de bogue importante est le bogue qui sous-estimait le trafic total du service oignon du réseau Tor, ignorant tout trafic provenant des clients.

En plus que les canaux utilisant des versions obsolètes de la poignée de main Tor ne peuvent plus contourner les contrôles canonicité des adresses. (Il ne s'agit que d'un problème mineur, car ces canaux n'ont aucun moyen de configurer les clés ed25519 et doivent donc toujours être rejetés pour les circuits qui spécifient des identités ed25519.)

Des autres changements qui se démarquent:

  • Les autorités recommandent désormais des versions de protocole compatibles avec Tor 0.3.5 et versions ultérieures.
  • Réinitialisez la prise en charge des événements de port de contrôle GUARD NEW / UP / DOWN.
  • Ajoutez le support IPv6 à tor_addr_is_valid ().
  • Ajoutez des tests pour les changements ci-dessus et tor_addr_is_null ().
  • Autorisez les clients et les relais à envoyer des cellules EXTEND2 à double pile IPv6 uniquement.
  • Autorisez Tor à construire sur des plates-formes sur lesquelles il ne sait pas comment signaler quel appel système a causé le crash du bac à sable Linux seccomp2.
  • Autorisez l'appel système unlinkat (), que certaines implémentations de Libc utilisent pour implémenter unlink ().
  • Ajout de 3 nouveaux SocksPort ExtendedErrors (F2, F3, F7) signalant un nouveau type d'échecs de connexion de service.

Enfin, si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.