Tor Onion Services (Tor Project)

« Le Dark Web n’existe pas! »

Premier point de cette conférence, le Dark Web n’existe pas ou du moins les systèmes d’anonymisation de site assurant confidentialité et chiffrement ne sont pas du Dark Web. Il s’agit d’une appellation péjorative des détracteurs de l’anonymat sur Internet. Les onions sont des services internet TCP utilisant l’infrastructure de Tor pour garantir la confidentialité et la sécurité des échanges. Ces services utilisent actuellement un point de rendez-vous (un nœud Tor assurant cette responsabilité) et sont authentifiés par la connexion (grâce à l’empreinte de clef utilisée comme adresse) et chiffré en bout-à-bout. La fonctionnalité de Nat Punching permet de faire fonctionner le service Onion (Hidden Service) derrière un NAT. Aujourd’hui 5% du trafic de Tor est en direction des HS avec environ 30 000 sites en .onion évalués.

Les Hidden Services sont apparus en 2004, le premier site de fuites concernant les dangers du Dlanzapin est sorti en 2006, puis Wikileaks en HS (2007), l’initiative GlobaLeaks (2011) puis SecureDrop (2013). Les HS commencent aussi à héberger des sites sans contrainte légale avec Aphex Twin qui met à disposition son CD sur le réseau Tor (2014), un hidden service pour la gestion des blockchains apparaît (2014) et la très célèbre apparition de Facebook (2015) qui dispose d’un HS avec déjà plus de 100 000 utilisateurs et un certificat de type Extended Validation. La RFC7686 a confirmé l’importance des Hidden Services avec l’officialisation des domaines en .onion.

Plusieurs services sont apparus pour aider à mettre en place des HS ou accompagner les utilisateurs à travers Tor. Onionshare propose un bundle rapide à mettre en place. Ricochet.im et Pond (de Imperial Violet) proposent des solutions XMPP-like pour Tor. Riseup, Debian, Duckduckgo, The Pirate Bay, GnuPG proposent tous des HS pour l’accès d’utilisateur Tor.

Le conférencier a rappelé les problématiques des recherches sur les Hidden Services: essayez d’attaquer vous-même de préférence, collecter seulement les données pertinentes/existantes, n’utilisez pas votre nœud pour collecter les nœuds .onion. Il s’agit là de recommandations éthiques.

Aujourd’hui, les HS ont plusieurs problèmes de sécurité: La signature des clefs est trop courte et risque d’être exposé à une collision, il est possible d’espionner un HS particulier, il est possible de faire la collecte de HS. Et de manière général, les nœuds HS sont vulnérables aux attaques par Sybille et à l’attaque Guard Discovery.

Un HS se connecte aux réseaux Tor et transmet au serveur HSDir ses points d’introduction et sa clef publique. Un client requête le serveur HSDir pour connaître la clef publique du HS et son point d’entrée à partir de son empreinte et envoie un paquet chiffré par la clef du HS avec son point de rendez-vous et un secret partagé unique. Le HS se connecte au nœud de rendez-vous et vérifie le secret unique. Le serveur HSDir est aujourd’hui distribué sous forme de Hash Table. 6 relays possèdent l’adresse du HS basé sur le DescID=H(.onion|H(time-period|descriptor-cookie|replica)). Le .onion et la variable temporelle sont les seuls éléments non statiques ce qui permet à un HS de changer de DescID toutes les 24h.
La Proposal 250 propose de rajouter une variable aléatoire pour le DescID tel que H(.onion|H(time-period|random-value|descriptor-cookie|replica)) afin de ne pas pouvoir prévoir quand un nœud sera relay pour un HS donné. Cette valeur aléatoire serait distribuée par un des neuf serveurs Directory Hard codé dans Tor.

Les adresses vont passer de 16 à 52 caractères avec le passage de SHA-1 à SHA-256. De même les algorithmes vont changer pour ed25519.

De nouveau type de HS vont apparaître:
– RSOS: Rendez Vous Single Onion Services (Proposal 260) réduit le circuit Tor entre le point de Rendez Vous et le HS qui ne nécessite pas d’anonymat.
– SOS: Single Onion Services (Proposal 252) supprime le Rendez Vous et connecte le circuit Tor du client directement au HS sans sortir du réseau.
– OnionBalance (TSoP): Actuellement en beta test par Facebook, permettra de réaliser du load balancing derrière une clef unique.

Facebooktwitterlinkedin
Pierre d'Huy
Pierre d'Huy est un ingénieur spécialisé dans la sécurité des Systèmes d'Information. Il donne occasionnellement des conférences en école (ESE, ESGI Secure Day...) ou devant des publics non-techniques (Les matinées du droits Lamy, l'AFCDP). Amateur de cryptographie et de cartographie, il propose des articles sur de nombreux sujets qui le passionnent.

Leave a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *