245
modifications
« Tor, conception, fonctionnement et limites » : différence entre les versions
Aller à la navigation
Aller à la recherche
Tor, conception, fonctionnement et limites (voir la source)
Version du 22 juin 2017 à 02:53
, 22 juin 2017aucun résumé des modifications
Aucun résumé des modifications |
|||
| Ligne 29 : | Ligne 29 : | ||
Par sécurité, Tor renouvelle le circuit toutes les 10 minutes pour brouiller les pistes et limiter les information qu’un attaquant controllant un noeud pourrait récupérer. Cependant, Le noeud d’entrée, qu’il soit bridge ou gardien, est fixe et ne change que tous les 2 à 3 mois pour un noeud gardien. Ce temps est appellé la “période de rotation”. Le Tor Project est même en train de réfléchir pour faire passer la période de rotation à 1 an. Alors, pourquoi ça ? C’est vrai que ça peut sembler contre-intuitif comme ça. Mais il y a des bonnes raisons : | Par sécurité, Tor renouvelle le circuit toutes les 10 minutes pour brouiller les pistes et limiter les information qu’un attaquant controllant un noeud pourrait récupérer. Cependant, Le noeud d’entrée, qu’il soit bridge ou gardien, est fixe et ne change que tous les 2 à 3 mois pour un noeud gardien. Ce temps est appellé la “période de rotation”. Le Tor Project est même en train de réfléchir pour faire passer la période de rotation à 1 an. Alors, pourquoi ça ? C’est vrai que ça peut sembler contre-intuitif comme ça. Mais il y a des bonnes raisons : | ||
1 : | 1 : Supposons qu’un attaquant fasse tourner plusieurs relais en vue d’analyser le traffic pour desanonymiser les utilisateurs de Tor et ce qu’ils font sur internet. Si jamais votre connexion Tor entre et sort par des relais contrôlés par cet attaquant, c’est l’un des pires scénarios qui puisse arriver car il peut faire des corrélations et vous griller (Voir chapitre “vulnérabilités”). Le fait d’avoir un noeud d’entrée (bridge ou gardien) qui soit fixe, et un noeud de sortie mobile, bien que ne changeant pas le risque que ce scénario se produise pour un circuit donné, diminue le risque cumulatif au fur et à mesure que vous changez de circuit. | ||
2 : Supposons qu’un attaquant veuille faire passer les connexions à travers des relais qu’il contrôle. On pourrait immaginer que cet attaquant va faire une attaque DoS (Denial of Service) sur des relais qu’il ne contrôle pas, par exemple en les saturant de requêtes pour les planter. Si le noeud d’entrée n’était pas fixe, l’attaquant pourrait alors augmenter les probabilités que ses machines soient choisies pour concentrer le traffic Tor et l’analyser. Le fait que les noeuds d’entrée soient fixes permet d’éviter ce scénario. | 2 : Supposons qu’un attaquant veuille faire passer les connexions à travers des relais qu’il contrôle. On pourrait immaginer que cet attaquant va faire une attaque DoS (Denial of Service) sur des relais qu’il ne contrôle pas, par exemple en les saturant de requêtes pour les planter. Si le noeud d’entrée n’était pas fixe, l’attaquant pourrait alors augmenter les probabilités que ses machines soient choisies pour concentrer le traffic Tor et l’analyser. Le fait que les noeuds d’entrée soient fixes permet d’éviter ce scénario. | ||
| Ligne 169 : | Ligne 169 : | ||
Un service caché est un site en .onion. C'est ce que l'on appelle communément le deep web. L'intérêt d'un service caché réside principalement dans le fait qu'il n'est pas localisable. En effet, c'est l'adresse IP, attribuée par le fournisseur d'accès à internet, qui permet de localiser un site internet. L'accès à un service caché ne fait pas intervenir son IP. De plus, les entités qui ont accès à l'IP (comme le FAI) n'ont pas accès au contenu qui n'est accessible que via le réseau Tor. | Un service caché est un site en .onion. C'est ce que l'on appelle communément le deep web. L'intérêt d'un service caché réside principalement dans le fait qu'il n'est pas localisable. En effet, c'est l'adresse IP, attribuée par le fournisseur d'accès à internet, qui permet de localiser un site internet. L'accès à un service caché ne fait pas intervenir son IP. De plus, les entités qui ont accès à l'IP (comme le FAI) n'ont pas accès au contenu qui n'est accessible que via le réseau Tor. | ||
Prenons à titre d'exemple le moteur de recherche Grams, inspiré de google (http://grams7enufi7jmdl.onion). Supposons qu'un utilisateur veuille se connecter à ce service caché. Voici comment se déroule l'établissement de la | Prenons à titre d'exemple le moteur de recherche Grams, inspiré de google (http://grams7enufi7jmdl.onion). Supposons qu'un utilisateur veuille se connecter à ce service caché. Voici comment se déroule l'établissement de la connection. | ||
=====Etape 1 :===== | =====Etape 1 :===== | ||
[[Image:Step1.png|thumb|Etape 1]] | [[Image:Step1.png|thumb|Etape 1]] | ||
Le service caché va établir quelques circuits et demander aux relais de sortie de servir de point d'introduction (https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt) (Je n'en ai représenté que deux dans l'exemple). Concrètement, le service caché commence par récupèrer les IP de ces points d'introduction, en l'occurence 198.50.159.155 et 41.231.53.101 (exemples réels d'IP de noeuds de sortie). | Le service caché va établir quelques circuits et demander aux relais de sortie de servir de point d'introduction (<ref name="Tor-RV-Spec">[https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt Tor Rendezvous Specification]</ref>) (Je n'en ai représenté que deux dans l'exemple). Concrètement, le service caché commence par récupèrer les IP de ces points d'introduction, en l'occurence 198.50.159.155 et 41.231.53.101 (exemples réels d'IP de noeuds de sortie). | ||
=====Etape 2 :===== | =====Etape 2 :===== | ||
[[Image:Step2.png|thumb|Etape 2]] | [[Image:Step2.png|thumb|Etape 2]] | ||
Le service caché va ensuite demander aux points d'introduction de maintenir la connection. Pendant ce temps, il va établir un circuit TOR vers un Hidden Service Directory (HSDir) et y uploader un descripteur de service caché. En effet, les services cachés ont besoin de signaler leur existence afin d'être contacté. Ce descripteur se compose de : | Le service caché va ensuite demander aux points d'introduction de maintenir la connection. Pendant ce temps, il va établir un circuit TOR vers un Hidden Service Directory (HSDir) et y uploader un descripteur de service caché<ref name="Tor-RV-Spec"/>. En effet, les services cachés ont besoin de signaler leur existence afin d'être contacté. Ce descripteur se compose de : | ||
* Les IP des points d'introduction | * Les IP des points d'introduction<ref name="Tor-RV-Spec"/> | ||
* La clé publique du service caché | * La clé publique du service caché<ref name="Tor-RV-Spec"/> | ||
* La signature des deux éléments précédents, faite avec la clé privée correspondante. | * La signature des deux éléments précédents, faite avec la clé privée correspondante.<ref name="Tor-RV-Spec"/> | ||
Un HSDir est un relai Tor comme un autre, mais qui va assurer une fonction supplémentaire. Il va recevoir des informations sur les services cachés afin de permettre aux utilisateurs de Tor de les contacter. Un relai acquiert le statut de HSDir via le consensus, au même titre que les noeuds de sortie ou les noeuds gardiens | Un HSDir est un relai Tor comme un autre, mais qui va assurer une fonction supplémentaire. Il va recevoir des informations sur les services cachés afin de permettre aux utilisateurs de Tor de les contacter. Un relai acquiert le statut de HSDir via le consensus, au même titre que les noeuds de sortie ou les noeuds gardiens | ||
<ref name="Tor-RV-Spec"/>. | |||
=====Etape 3 :===== | =====Etape 3 :===== | ||
| Ligne 194 : | Ligne 195 : | ||
[[Image:Step4.png|thumb|Etape 4]] | [[Image:Step4.png|thumb|Etape 4]] | ||
Votre machine va maintenant établir un circuit aléatoire. Le noeud de sortie choisi sera le point de rendez-vous. Après avoir établi la connexion, votre machine va communiquer au point de rendez-vous un secret qui servira à authentifier le service caché. | Votre machine va maintenant établir un circuit aléatoire. Le noeud de sortie choisi sera le point de rendez-vous. Après avoir établi la connexion, votre machine va communiquer au point de rendez-vous un secret (sous la forme d'un cookie) qui servira à authentifier le service caché<ref name="Tor-RV-Spec"/>. | ||
=====Etape 5 :===== | =====Etape 5 :===== | ||
| Ligne 201 : | Ligne 202 : | ||
Votre machine va garder la connexion au point de rendez-vous en attente. Elle va ensuite établir un circuit aléatoire vers un des points d'introduction, dont les IP ont été téléchargées depuis le HSDir. Le point d'introduction va ensuite relayer les données jusqu'au service caché. | Votre machine va garder la connexion au point de rendez-vous en attente. Elle va ensuite établir un circuit aléatoire vers un des points d'introduction, dont les IP ont été téléchargées depuis le HSDir. Le point d'introduction va ensuite relayer les données jusqu'au service caché. | ||
Concrètement, le client Tor va envoyer au service caché l'IP du point de rendez-vous, la première partie de l'échange de Diffie-Hellman qui servira à négocier une clé symétrique entre le client et le service caché, et le secret qui a été dit au point de rendez-vous. Ces informations sont chiffrées avec la clé publique du service caché (téléchargée depuis le HSDir), et ensuite protégée dans le traditionnel oignon de chiffrement de Tor. Les 3 relais côté client épluchent chacun une couche de l'oignon, et les 3 relais côté service caché en reconstituent chacun une. | Concrètement, le client Tor va envoyer au service caché l'IP du point de rendez-vous, la première partie de l'échange de Diffie-Hellman qui servira à négocier une clé symétrique entre le client et le service caché, et le secret qui a été dit au point de rendez-vous<ref name="Tor-RV-Spec"/>. Ces informations sont chiffrées avec la clé publique du service caché (téléchargée depuis le HSDir), et ensuite protégée dans le traditionnel oignon de chiffrement de Tor. Les 3 relais côté client épluchent chacun une couche de l'oignon, et les 3 relais côté service caché en reconstituent chacun une. | ||
=====Etape 6 :===== | =====Etape 6 :===== | ||
| Ligne 211 : | Ligne 212 : | ||
[[Image:Step7.png|thumb|Etape 7]] | [[Image:Step7.png|thumb|Etape 7]] | ||
Dernière étape : le client et le service caché s'occupent de la deuxième partie de l'échange de Diffie-Hellman. Ceci aboutit à la création d'une clé symétrique AES qui permettra au client et au service caché de communiquer en chiffré de façon symétrique. | Dernière étape : le client et le service caché s'occupent de la deuxième partie de l'échange de Diffie-Hellman<ref name="Tor-RV-Spec"/>. Ceci aboutit à la création d'une clé symétrique AES qui permettra au client et au service caché de communiquer en chiffré de façon symétrique. | ||
=====résultat final :===== | =====résultat final :===== | ||