245
modifications
Ligne 134 : | Ligne 134 : | ||
Voici ce que fait votre machine quand vous voulez accéder à www.psychoactif.org via Tor : | Voici ce que fait votre machine quand vous voulez accéder à www.psychoactif.org via Tor : | ||
1 : Télécharger le consensus | *1 : Télécharger le consensus | ||
2 : Sélectionner aléatoirement un noeud gardien, un noeud intermédiaire et un noeud de sortie à partir du consensus | *2 : Sélectionner aléatoirement un noeud gardien, un noeud intermédiaire et un noeud de sortie à partir du consensus | ||
Une fois que c’est fait, c’est là que ça se complique un peu, parce qu’il va falloir négocier des clés de chiffrement avec chacun des relais de façon anonyme, au moins pour le 2èm et le 3èm. Votre machine va donc : | Une fois que c’est fait, c’est là que ça se complique un peu, parce qu’il va falloir négocier des clés de chiffrement avec chacun des relais de façon anonyme, au moins pour le 2èm et le 3èm. Votre machine va donc : | ||
3 : Récupérer les 3 clés publiques des 3 relais depuis un serveur de clés. Ces clés vont servir pour l’authentification | *3 : Récupérer les 3 clés publiques des 3 relais depuis un serveur de clés. Ces clés vont servir pour l’authentification | ||
Négociation avec le noeud gardien | Négociation avec le noeud gardien | ||
4 : Entamer un handshake avec le noeud gardien. Au cours de cette poignée de main, le noeud gardien va s’autentifier en signant la poignée de main avec sa clé privée (l’algorithme utilisé par Tor est RSA 1024 bits. Tor est actuellement en train de migrer vers une courbe elliptique Curve25519 plus sécurisée)<ref>https://gitweb.torproject.org/torspec.git/plain/tor-spec.txt</ref>. Le client (votre machine) va vérifier la signature à l’aide de la clé publique récupérée en 3. | *4 : Entamer un handshake avec le noeud gardien. Au cours de cette poignée de main, le noeud gardien va s’autentifier en signant la poignée de main avec sa clé privée (l’algorithme utilisé par Tor est RSA 1024 bits. Tor est actuellement en train de migrer vers une courbe elliptique Curve25519 plus sécurisée)<ref>https://gitweb.torproject.org/torspec.git/plain/tor-spec.txt</ref>. Le client (votre machine) va vérifier la signature à l’aide de la clé publique récupérée en 3. | ||
5 : Négocier une clé de chiffrement symétrique (AES 128), qu’on appelle une clé de session (Clé1), avec le premier noeud suivant le protocole d’échange de Diffie-Hellman. Le protocole de Diffie Hellman permet de négocier une clé symétrique sans avoir à se l’échanger directement. | *5 : Négocier une clé de chiffrement symétrique (AES 128), qu’on appelle une clé de session (Clé1), avec le premier noeud suivant le protocole d’échange de Diffie-Hellman. Le protocole de Diffie Hellman permet de négocier une clé symétrique sans avoir à se l’échanger directement. | ||
Négociation avec le noeud intermédiaire. Un peu plus difficile car il ne faut pas que le noeud intermédiaire connaisse le client. | Négociation avec le noeud intermédiaire. Un peu plus difficile car il ne faut pas que le noeud intermédiaire connaisse le client. | ||
6 : Handshake avec le noeud intermédiaire (NI) à travers le noeud gardien (NG). Le client envoie une demande de connexion au NG chiffré avec Clé1 en lui demandant de la transmettre au NI. Le NG déchiffre avec la clé de session et découvre qu’il doit transmettre au NI. Le NI répond au NG en signant avec sa clé privée (toujours RSA 1024 ou Curve25519). Le NG chiffre avec la clé de session Clé1 et transmet ensuite au client. Le client déchiffre la réponse avec Clé1 et vérifie la signature. | *6 : Handshake avec le noeud intermédiaire (NI) à travers le noeud gardien (NG). Le client envoie une demande de connexion au NG chiffré avec Clé1 en lui demandant de la transmettre au NI. Le NG déchiffre avec la clé de session et découvre qu’il doit transmettre au NI. Le NI répond au NG en signant avec sa clé privée (toujours RSA 1024 ou Curve25519). Le NG chiffre avec la clé de session Clé1 et transmet ensuite au client. Le client déchiffre la réponse avec Clé1 et vérifie la signature. | ||
7 : Négociation de Diffie-Hellman pour une deuxième clé de session symétrique (Clé2), toujours en passant par le NG. | *7 : Négociation de Diffie-Hellman pour une deuxième clé de session symétrique (Clé2), toujours en passant par le NG. | ||
Négociation avec le noeud de sortie (NS). Encore plus difficile parce que le NS ne doit connaitre ni le client, ni le NG, et le NG ne doit pas connaitre le NS non plus. | Négociation avec le noeud de sortie (NS). Encore plus difficile parce que le NS ne doit connaitre ni le client, ni le NG, et le NG ne doit pas connaitre le NS non plus. | ||
8 : Handshake avec le NS à travers les 2 noeuds précédents. Le client envoie une demande de connexion chiffrée 2 fois avec Clé1 et Clé2 et l’envoie au NG. Le NG déchiffre la première couche avec clé 1, mais ne peut toujours pas lire le contenu puisqu’il est chiffré aussi avec Clé2 et qu’il n’a pas cette clé. Il envoie donc le contenu chiffré avec Clé2 au NI. Le NI déchiffre avec Clé2 et transmet au NS. Le NS signe et renvoie au NI. Le NI chiffre avec Clé2 et envoie au NG. Le NG chiffre avec Clé1 et renvoie au client. Le client déchiffre avec Clé1 et Clé2 et vérifie la signature avec la clé publique du NS. | *8 : Handshake avec le NS à travers les 2 noeuds précédents. Le client envoie une demande de connexion chiffrée 2 fois avec Clé1 et Clé2 et l’envoie au NG. Le NG déchiffre la première couche avec clé 1, mais ne peut toujours pas lire le contenu puisqu’il est chiffré aussi avec Clé2 et qu’il n’a pas cette clé. Il envoie donc le contenu chiffré avec Clé2 au NI. Le NI déchiffre avec Clé2 et transmet au NS. Le NS signe et renvoie au NI. Le NI chiffre avec Clé2 et envoie au NG. Le NG chiffre avec Clé1 et renvoie au client. Le client déchiffre avec Clé1 et Clé2 et vérifie la signature avec la clé publique du NS. | ||
9 : Négociation de Diffie Hellman avec le NS. | *9 : Négociation de Diffie Hellman avec le NS. | ||
==== Echange des données ==== | ==== Echange des données ==== |
modifications