A TCP/IP packet mainly has two parts. The header and data (mostly encrypted).

When using Tor, and a packet leaves my Tor browser, where is my initial header information stored?

If the destination address given to my next node is its predecessors address, how does the node after know where to transmit the packet afterwards? And how would the Exit relay know to which IP it is to finally route the traffic to?

Could you please recommend a tutorial or a simple explanation online from which I can gain a proper insight about how TCP/IP packet propagation really works in Tor.

3 Answers 3


Well,it`s complicated,I guess these two links can help :https://www.torproject.org/about/overview.html.en and https://en.wikipedia.org/wiki/HTTP_Secure

Note this :"Everything in the HTTPS message is encrypted, including the headers, and the request/response load. With the exception of the possible CCA cryptographic attack described in the limitations section below, the attacker can only know the fact that a connection is taking place between the two parties, already known to him, the domain name and IP addresses."So you see HTTP headers are encrypted too.

And this:"Since protocols can operate either with or without TLS (or SSL), it is necessary for the client to indicate to the server the setup of a TLS connection. There are two main ways of achieving this. One option is to use a different port number for TLS connections (for example, port 443 for HTTPS). The other is for the client to request that the server switches the connection to TLS using a protocol-specific mechanism (for example, STARTTLS for mail and news protocols).Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure."Look,that means servers(and tor nodes) do not need to know what contain in your HTTP headers,they just know your browser are trying to connect with them.

This:"Instead of taking a direct route from source to destination, data packets on the Tor network take a random pathway through several relays that cover your tracks so no observer at any single point can tell where the data came from or where it's going."If the requested website do not support HTTPS,then your data will be decrypted at Tor exit nodes,and these exit nodes will know all of you,include which IP address(or domain name) it is to finally route the traffic to ;otherwise I guess only the special data which only contains what server(IP address or domain name) the client(this should be your browser,in fact it becomes one of Tor exit nodes finally) tries to build a SSL/TLS connection are the only data which is decrypted at Tor exit nodes,other data(include HTTP headers) is still encrypted until it reaches the requested server finally. I hope my explaination can help you:)

  • Thank you for your response. Your answer has given rise to these questions in me. 1. If HTTPS encrypts everything inside the header, then how could the packet route at all? Are all packets routed in TOR network to one predefined destination? Is it like most header information is encrypted but the source and destination IP addresses while traveling through the TOR network? I mean, if everything is routed, how wound the middle server or the exit router know where to send the packet to after it receives the response?
    – Denis
    Commented Oct 30, 2014 at 6:08
  • “like most header information is encrypted but the source and destination IP addresses while traveling through the TOR network”well,you can understand how HTTPS works like this.SSL/TLS tell where data packages go when they help client and server make a handshake. Commented Oct 30, 2014 at 11:17

how does the node after know where to transmit the packet afterwards? And how would the Exit relay know to which IP it is to finally route the traffic to?

Simply put: Your client first selects the three nodes that it will use. Next, it encrypts your msg with the public key of the exit node. Then it encrypts that with the public key of the middle node, then with the public key of the entry node. It's like building up layers.

As your msg enters the Tor system, the entry node decrypts it with its private key and only then discovers where to send it to next (i.e., the IP address and port for the middle node). And so on, with each node in effect peeling off a layer. Hence, the name of "The onion router", like peeling an onion.

Hope that helps. Btw, I've voted you up to help you more quickly get to the point where you can participate fully on the group. I see a main aim of this group as being advocacy for Tor, besides answering technical questions. Welcome to the struggle for privacy and freedom on the internet.

  • Thank you @Chinup! you are a great person! you taught me the meaning of Tor! now I can go explain to people I recommended it to.its just amazing the way the meaning of Tor matches the way it works. Currently,the people I recommended it to are complaining me that common services are giving trouble including some stackexchange forums. These people dont get the idea one-IP is not one-person. I work in a university.I want to convince my head to run a tor exit relay one day. And I think with people like you, who explain things clearly, Tor will have a long way to go. I love Tor!!
    – Denis
    Commented Nov 5, 2014 at 13:08
  • 1
    Thank you very kindly, QwertyCoolGuy. My best wishes go to you and your efforts to promote Tor. Please post any success stories, especially about starting a new relay :)
    – Chinup
    Commented Nov 6, 2014 at 14:43

Simple answer: No.
Tor is not working on layer 2. Tor uses a socks proxy to receive data from applications. All TCP headers would be dropped and payload would be reassembled into "cells". Destination is included in socks header and Tor puts it (only destination, not source) in relay cells so that exit relay would know your destination.
Application headers (e.g. HTTP header) are left in the packet, may leak your information.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .