Le blog de Genma
Vous êtes ici : Accueil » Informatique & Internet » Tor » Etude de la sécurité du Tor Browser Launcher

Etude de la sécurité du Tor Browser Launcher

D 3 décembre 2014     H 09:00     A Genma     C 0 messages   Logo Tipee

TAGS : Tor Planet Libre Traduction

Ce texte est une traduction du texte Tor Browser Launcher Security Design, du projet torbrowser-launcher.

Ce texte me semblait important à partager pour apprendre et mieux comprendre des notions de sécurité en informatique. Je ne peux pas tout expliquer en détail mais j’ai essayé de mettre quelques Notes explicatives liée à la traduction pour essayer de vulgariser et d’expliquer (de ce que j’ai pu comprendre) un peu plus en détail.

Voir également mes articles Le TorBrowser Bundle est un bundle et Tor Browser dans lequel je parle du Tor Launcher.

Début de traduction

Ce document est améliorable. Pour le moment, c’est un copier-coller d’un message poster sur le bug tracker de debian.

La sécurité de TLS/x.509

Le torbrowser-launcher ne repose pas sur l’infrastructure du Certificate Authority (CA). Le seul TLS qu’il fait et de faire une requête HTTPS vers check.torproject.org et (si vous n’avez pas choisi un miroir) le site www.torproject.org. Quand il se connecte à ces noms de domaines, il utilise un certificat en dur. Ainsi plus aucune TLS PKI ne se fait/ne s’applique ensuite.

(Et je ai pris des mesures supplémentaires afin de s’assurer que le .pem inclus avec torbrowser-lanceur est valable. J’ai téléchargé le CERT de différentes connexions internet / FAI et les ai comparés, et quand j’en ai eu un que je pensais correcte, j’ai échangé avec les développeurs de Tor pour vérifier c’était le bon et non un corrompu/malicieux).

Downgrade attacks - Les attaques par régression

Les attaques par régression ne devraient pas être possibles, à moins qu’elles ne soient liées à des commit des développeurs de Tor eux-mêmes. Si un attaquant récupère une ancienne demande valide au serveur https://check.torproject.org/RecommendedTBBVersions, le résultat indiquerait que la version actuelle est plus ancienne que la version actuellement installée, et le torbrowser-launcher n’effectuerait pas l’installation de cette version. (Par installer, j’entends extraire le contenu du zip dans le dossier home de l’utilisateur).

Note explicative liée à la traduction : le but d’une attaque par régression est de faire retour à une version antérieure contenant des bugs/failles de sécurité. Là, l’idée est que l’on remplace la version déjà installée du tor-browser (qui est dézippé dans le dossier /home/login/torbrowser-launcher/ par une version plus ancienne)

Toutefois, il y a le scénario où l’utilisateur a défini un miroir tierce comme site de téléchargement au lieu du site par défaut. Le site miroir peut très bien fournir un zip et un fichier de signature qui ont les noms de la dernière version, mais qui correspondent en réalité à une version de fichier d’une version antérieure. Ce type d’attaque est limitée du fait que tous les miroirs utilisent l’HTTPS — et si aucun des certificats de miroir n’est "connu", dans ce cas, c’est sur l’infrastructure du Certificate Authority (CA) que cela reposera. C’est là un cas limite, et qui ne fonctionne que contre les utilisateurs qui utilisent un site miroir , et qui nécessitent accès aux clefs de signature du CA.

Note explicative liée à la traduction : sur la vérification et la signature voir mon article Comment vérifier l’intégrité du TorBrowser quand on le télécharge ?

Installation du Tor Browser au niveau du système (system-wide)

Vous ne pouvez pas installer le Tor-Browser au sein du système (et non pour un utilisateur uniquement). Le logiciel est fourni en tant que bundle par le Tor Project. Il y un certains nombres de lignes de codes qui préviennent du fait que le logiciel modifiera des fichiers en dehors de son propre répertoire dans lequel il se trouve. Chaque fichier a pour propriétaire (note de traduction au sens permission unix) l’utilisateur courant, et cela a été pensé pour que le logiciel puisse être lancé depuis une clef USB. Il y a longtemps, j’ai travaillé pour que le Tor-Browser bundle soit bundle indépendant et puisse être installé au niveau du système (note de traduction : et donc utilisable par tous les utilisateurs) et suit arrivé à la conclusion que ce n’était pas faisable si les développeurs de Tor ne délivrait pas une version "non bundle". Si vous pouviez installer le Tor-Browser au sein du système en lui-même, il n’y aurait pas de raison à l’existence du torbrowser-launcher — il y aurait un paquet Debian (note de traduction : qui serait donc géré en tant que tel, apportant les mises à jour du Tor-browser comme n’importe quel autre logiciel).

De quels clef secrète/accès les attaquants ont-ils besoins ?

Oui, les attaquants qui 1) ont accès aux clefs de confiances fournies avec le torbrowser-launcher et 2) ont la possibilité de modifier des fichiers sur https://www.torproject.org/ ou ont accès aux clefs TLS sont en mesure de faire exécuter du code de leur choix en tant que l’utilisateur courant quand ce dernier lance le Tor Browser. Cela est valable (ou pas) pour les développeurs Tor dont les clefs son inclues (Note de traduction : dans le Tor Browser).

Mais comme le dit Holger, c’est une fonctionnalité , pas un bug (this is a feature, not a bug)C’est là le but du torbrowser-launcher, afin que les utilisateurs puissent installer automatiquement les mises à jour du Tor-Browser Bundle qui sont signés par développeurs Tor.

Fin de traduction