If I use a Tor router to browse the regular internet, my traffic must leave the Tor network through an exit node. Apparently the exit node can see the data originally sent.
In Tor, the user (you) chooses a random path through several nodes for its data. The first node in the path knows your IP address, but not what you send or where. The last node ("exit node") knows the target server address and sees the data (unless SSL is used, of course), but not your IP address. Every node in the path knows only the addresses of the previous and the next nodes in the path.
If a government is intent on unraveling the privacy of Tor, then its best chance is to setup and operate a lot of nodes (which, of course, will not say "provided by your friendly government"). If your computer randomly chooses a path which begins by a government-controlled node and ends with another government-controlled node, then both nodes can correlate their data pretty easily and reveal both your IP and the target server (and sent data, if no SSL). Correlation is simple because while encryption hides the contents of data, it does not hide the length. If node A sees a 4138-byte request entering the Tor network from your IP, and node B sees a 4138-byte request within the next second exiting the Tor network and destined to server www.example.com, then node A and node B, by collating their data, will infer that your IP was involved with a communication to www.example.com.
It can easily be proven that if the hostile party does not eavesdrop on or hijack both the entry and exit nodes, then your privacy is maintained. But if they do, then privacy evaporates like a morning mist under the midday Sun.
How Tor works is described in one of the blog posts on this very website:
http://security.blogoverflow.com/2012/04/tor-exploiting-the-weakest-link/
I know this was already answered, but a lot of important details were left out.
How onion routing works
Onion routing is an anonymity technique where a path is chosen randomly through a cluster of servers, such that each connection goes a different route. The specific relays for the guard, middle, and exit are chosen randomly by the Tor client. The path from guard to exit is called the circuit, and the Tor client remembers this. The guard is chosen once and remains the same for a long time (as explained below), while the middle and exit change at periodic intervals (either once every ten minutes, or when a new connection is established). The unpredictable path and large number of relays to choose from improves anonymity significantly.
(source: torproject.org)
When you send data over Tor, the data is encrypted with three keys. Each layer specifies the subsequent relay to be used (as chosen by your client at random):
Now the traffic has been successfully sent to its destination, but it has to get back. Tor relays keep which relay is communicating with it in memory, so when it gets a response from that relay, it knows where to send it. This way, the middle relay knows the guard asked it to send data to the exit, and it remembers this so when that same exit gives it data back, it can forward it to the guard:
This is the original concept behind onion routing. All this happens in a second or two.
Who can see what?
I actually wrote this answer because no one linked to the obligatory EFF diagram on Tor. This depicts each point of interest and what a given adversary can observe:
From the perspective of the relays, three things are true:
The anonymity stems from the fact that no one entity can know who you are and what you are doing.
Traffic analysis attacks against Tor
In order to be deanonymized using Tor, assuming no attacks against you directly (software exploits, backdoored hardware, OPSEC failures), an entity that knows who you are, and an entity that knows what you are doing must collude. In the diagram, that adversary is labeled as the NSA. The black dotted line shows data sharing, which means that the precise timing information can be used to correlate you. This is called a traffic analysis attack, and is a risk when your adversary monitors both ends of the connection. Tor has only a limited ability to protect against that, but thankfully it is often enough, since there is so much traffic to blend in with. Consider the following timeline of events:
203.0.113.42 send 512 encrypted bytes (253 unencrypted) of data at t+0.example.com receive a 253 byte request for /foo.html at t+4.example.com send a 90146 byte reply at t+5.203.0.113.42 receive a 90424 encrypted byte reply (90146 unencrypted) at t+9.ISP1 is any ISP between you and the guard, and ISP2 is any ISP between the exit and the destination. If all this can be monitored, and ISP1 and ISP2 collude, then with sufficient computation, one can conclude that IP address 203.0.113.42 accessed example.com/foo.html. Tor makes this harder in a few ways. First, persistent guards reduce the chance that an adversary will be able to observe steps 1 and 4 by adding a large number of malicious guards to the network. Second, Tor sends traffic in cells of 512 bytes each (or at least used to be. It's 514 bytes now), so step one would involve sending 512 bytes, yet step 2 would still show 253 bytes received. Third, the number of hops Tor goes through increases jitter in latency. Because of this, each subsequent timestamp will differ by a small but random time. This makes it hard to distinguish other connections which transfer a similar amount of data at a similar time from your connection.
There have been many academic attacks against Tor which rely on traffic analysis, but they always assume a small world where latencies are all fixed and deterministic. These are the attacks that tend to be reported on in the media, despite not applying to the actual Tor network in a world where every network is full of noise.
Traffic analysis attacks against a proxy
This kind of attack is difficult to pull off against Tor because an adversary may not have access to both ISP1 and ISP2. Even if they do, the infrastructure of one of them may not be sufficient to record high-resolution timestamps (for example, due to reduced granularity NetFlow records), and their internal clocks may differ slightly. With a proxy, however, this attack is far easier to pull off. This is an issue even if you completely trust the proxy provider. Consider this alternative timeline of events, where ISP1 represents the ISP of the proxy service itself:
203.0.113.42 send 253 bytes of data at t+0.example.com for /foo.html at t+1.example.com send a 90146 byte reply at t+2.203.0.113.42 receive a 90146 byte reply at t+3.With this information all in the hands of ISP1, it becomes quite easy to conclude that 203.0.113.42 requested example.com/foo.html. There is no padding, and virtually no jitter (since the delay is only as long as it takes the proxy service to forward the request internally). Because of this, this single ISP knows both who you are and what you are doing, and all it has to do is connect the fact that they come from the same person. Simple. This is the main technical downside to proxies, even when their often sketchy nature and history of poor honesty is ignored.
I would like to point you to this answer here on that describes in simple terms how Tor works.
The exit node has no idea where the data originates from, this is the entire point of Tor. The key to Tor is the multiple layers of encryption the data goes through as it travels through the Tor network.
Using a proxy on the other hand, involves a direct connection between your machine and the proxy server. Compromising a proxy can pretty quickly reveal who is connected to it.
adding to the other answers
Adding to other answers as well:
if a government agency or a hacker wanted to figure out who I was, wouldn't they just have to subpoena the exit node owner or hack it?
A government agency would probably find you, no kidding. In the end the traffic going out of the node can betray you. End service prodivers (Gmail, Facebook) cooperate with them and will give out accounts information based on the IP address. Simple.
Implying that if you don't follow best practices when using ToR, it may be useless. Also implying that if I have your gmail account details, I know who you are, and if the same source IP does something I suspect illegal, I have but a few people to investigate (those sharing the exit node's IP).
