TOR - Comment les paquets font le chemin inverse ?

Comment les paquets reçus par le noeud de sortie sont-ils routés vers le poste source, via le circuit Tor ?

Prerequis :
– Connaitre le principe de routage et le principe de Tor (routage en oignon)
– Savoir ce qu’est un paquet (avoir des notions de réseau, TCP/IP).

Le chemin aller sur Tor (connexion à un serveur web depuis le TorBrowser) est bien documenté, avec des schémas sur le routage en oignon. Mais qu’en est-il du chemin de retour ? Comment les paquets reçus par le noeud de sortie sont-ils routés vers le poste source, via le circuit Tor ? C’est cette question que je me suis posé et la réponse n’est pas facile à trouver. J’ai discuté avec pas mal de monde et la réponse exacte n’est pas claire. Je livre ici une version/interprétation plausible

Sur How are packets received by a Tor exit node routed back through the Tor circuit ?, la réponse donnait apportait des éclaircissements et j’’ai donc librement traduit les réponses, en complétant le texte avec mes propres explications, pour en faire le texte qui suit.

Le chemin aller

Après sélection des différents "noeuds-relais" dans le réseau, le client effectue un échange de clés de sessions (Diffie-Hellman). Il y a une première clé de chiffrement pour le nœud d’entrée, une second clé pour le nœud du milieu et une dernière pour le nœud de sortie. Chaque noeud envoit donc une clé de session. Le premier noeud envoie sa clé au client. Le deuxième noeud envoie sa clé au 1er noeud qui la chiffre avec la clé négocié avec le client et l’envoie au client. Idem pour le troisième noeud (qui envoit de sa clé au 2nd noeud...)

Le client chiffre le paquet avec les 3 clés de session, l’envoie au 1er noeud qui pèle la première couche, qui l’envoie au deuxième noeud qui pèle la deuxième couche de chiffrement, et ainsi de suite jusqu’au noeud de sortie.

Le chemin de retour

Tor fonctionne comme une chaîne de proxys, où chaque proxy ne connait que le prochain saut et le saut précédent. Une fois que le serveur web a traité la réponse (demande d’affichage d’une page par exemple), il renvoie le paquet de réponse au noeud de sortie (étant donné que le noeud de sortie est vue comme l’ordinateur s’étant connecté au serveur web). Le nœud de sortie utilise une table (un équivalent d’une table NAT, mais avec plus d’informations) qui lui permet de décider d’où renvoyer la réponse. Le noeud de sortie chiffre de nouveau le paquet et l’envoie au noeud suivant, le noeud intermédiaire, qui fera alors la même chose, jusqu’à ce que le paquet atteigne votre ordinateur, où le paquet et alors déchiffré au niveau local et envoyé à l’application (le Tor Browser). Formulé autrement, lorsque les données sont envoyées à vous, la chaîne est inversée le noeud de sortie devient le premier noeud et votre ordinateur devient alors le noeud de sortie.

Point à valider - vérifier
Pour le chemin inverse, le dernier noeud chiffre avec sa clé de session, le passe au noeud d’avant qui chiffre aussi avec sa clé de session, jusqu’à remonter au client qui déchiffre les couches avec les clés qu’il a reçu lors de la construction du circuit.

Il est important de comprendre que le chiffrement se fait par trois fois : chaque noeud du chemin de retour chiffre avec la clef de session symétrique qu’il a en commun avec le client Tor. Le paquet qui arrive au niveau du client au retour est donc chiffré 3 fois. (3 fois ou une seule fois avec seulement la clef du noeud de sortie, la question demeure et je cherche "encore" la réponse exacte)

Dit autrement, à l’aller, on pèle les couches de l’oignon. Au retour, on reconstruit un oignon en ajoutant des couches. C’est ce que l’on voit bien sur ce type de schéma : on a bien trois couche de chiffrement au niveau de l’aller et du retour côté client.

(Trois couches ou une seule, selon que l’on rechiffre trois ou une fois, ce n’est pas clair).

Etude du flux de paquets

Les nœuds intermédiaires n’attendent pas que toutes les données soient disponibles avant de les envoyer à la prochaine étape, sinon télécharger des fichiers de plusieurs Mo serait une corvée. Au lieu de cela, ils ont un espace de mémoire tampon limité, et chaque fois que la mémoire tampon se remplit (ou un délai d’attente se produit), ils chiffrent et envoient au noeud suivant.

L’application croit que le serveur distant est le client Tor, elle a seulement besoin de savoir faire le transfert de paquet jusqu’au premier noeud. Le serveur Web de destination pense quant à lui que le noeud de sortie est le client. Tous les nœuds intermédiaires vont reconnaître leurs paquets, comme s’il y avait une connexion point-à-point entre eux.

Rappelez-vous que Tor ne fait pas qu’office de proxy HTTP, il fonctionne également à un niveau inférieur et fait office de proxy pour les connexions TCP, ce qui signifie que le nœud ne peut pas savoir quand il a « toutes les données ».

De plus le protocole HTTP 1.1 permet de faire plusieurs demandes par connexion, et lorsque l’on utilise une connexion HTTPS, la poignée de main TLS impliquent déjà plusieurs allers-retours. De même, il y a des protocoles qui sont conçus pour de multiples commandes et réponses (par exemple, SMTP ou IMAP), et puis il y a des protocoles où les deux parties peuvent envoyer des données à tout moment à l’autre (par exemple, SSH ou IRC)...