Tor communication from exit to origin

Question

hope this question has not been asked like this before - I've seen something similar but could not understand the process. So my question is regarding Tor communication:
origin -> destination and
destination -> origin.

From what I understand when I as a source (lets say IP ABCDE) send a package to Twitter (lets say IP 12345) via the Tor network, I connect to an entry point in the Tor network. When the package leaves the entry point to some other Tor server, the origin of the package (my IP ABCDE) is gone, either decrypted or deleted. The Tor nodes only know the target (Twitter) and route the package via node connection tables, where only the next and the previous step in the chain are known to one node. Even if that's not fully correct, from my understanding Twitter will receive a package with the content I sent, but from the IP of the Tor exit node (lets say IP 67890). At this point twitter has no knowledge of the origin.

Now here is the question - if Twitter (or to be more precise, the Twitter server that sends the package response) does not know the destination, how does the package end up back in my client browser? At some point in the Tor network, the real origin (my IP) has to be stored and if so, at which point is it stored? Because if that is true, when I get access to the entry point and can see all network traffic, it should be possible to identify the origin and target of a package. What part do I not (or not fully) understand, since I must be overlooking something....

I'd be glad about a fairly simple explanation with an example if possible as I'm quite new to the subject (pretty obvious I think).

Edit: I've read this thread, but it does not answer my particular question. Quote:

The webserver sends the packet to the exit node, because the exit node was the computer that connected to the webserver. The exit node uses a table (seems like the NAT table, but with more information) to decide where to send the response. So it will encrypt the packet again, and send it to the next node, which will do the same, until the packet reaches your computer, are decrypted locally, and sent to the application.

Here it's not specified where the original sender of the package (me) is stored and how I am identified within the Tor network. I get that the navigation from original Tor exit (now entry for Twitter) knows how to get back to the initial entry point where I sent my package to. But how does this node know that I am the original sender? And if the entry node has this information, isn't the Tor network easily compromised by hacking into the entry node (if it's "labeled" as such)?

Answer 1

What you're asking about involves knowing the details of the Tor protocol design. The Tor White Paper explains everything in detail. Look to section 4 (4.1-4.3) contain the design portions relating to circuits and streams.

The summary is that underneath the layer of TLS there are 512 byte cells that describe how Tor routers talk with each other. There are control cells and relay cells that are laid out as follows:

Control Cell

+---------------------------------------------------------+
| CircID | CMD |                 DATA                     |
+---------------------------------------------------------+

Relay Cell

+---------------------------------------------------------+
| CircID | Relay | StreamID | Digest | Len |     DATA     |
+---------------------------------------------------------+

This is how each piece of data knows what stream and relay it is associated with, as well as the circuit. Each Tor router will likely keep some type of "Tor policies" to ensure they keep track of these circuits, relays, and stream IDs. Much like ISAKMP/IPSec handles its traffic. Whatever Tor uses as a daemon on the router would handle this management.

Answer 2

• Your computer (ABCDE) opens a connection to the tor entry node (node1) and sends the (encrypted) request.

• node1 opens a connection to the second node (node2), and passes it its request.

• node2 opens a connection to the exit node (67890) and passes it the request.

• The exit node 67890 connects to 12345 (twitter) and sends it the final request.

Twitter doesn't know the origin other that it came from 67890. As well, 67890 only knows it came from node2 and went to 12345. node2 only knows it came from node1 and went to node2. node1 knows that it came from ABCDE and was passed to node1.

Note that none of them know that ABCDE wanted to communicate with 12345, they only know their own hops. In order to figure out the full details, the nodes would need to collude in order to deanonimize you (something the government agencies are probably doing, btw).

The response simply flows back the same channel in the opposite direction: 12345 → 67890 → node2 → node1 → ABCDE

There are a few more details, in that the actual nodes selected for a given communication are chosen by ABCDE, and the connection to each node goes encrypted so that the intermediate ones can't read the contents (which means only 67890 can view the final destination). But the way of determining is as simple as that. The nodes do know who they are communicating with (until that finishes), and so there's no problem in sending back the response.