Tor exit nodes: the last relay and what it can read

The Tor Project’s page on relay types gives a typical circuit as a chain: the Tor user, a guard relay, a middle relay, an exit relay, and the destination, for example a website. It describes the exit relay as “the final relay in a Tor circuit”, the one that sends traffic out to its destination. The services a Tor client connects to, which the page lists as a website, a chat service or an email provider, see the IP address of the exit relay instead of the real address of the Tor user. Elastic and Malware Patrol, two security vendors, say the same in their own words, and we used them mainly for that definition.

Guard and middle relays are grouped together on that page as non-exit relays. All relays are listed in the public Tor relay directory, so services can block them, and the page names services that either misunderstand how Tor works or want to censor it, with online banking and streaming as examples. It adds that guard and middle relays usually do not receive abuse complaints. What makes a relay an exit is its exit policy. The Tor Project’s setup page for operators says to change ExitRelay from 0 to 1 in the configuration file and restart, and that an exit which wants to be useful must at least allow destination ports 80 and 443, the ports used for web traffic.

The same setup page says one more thing that sets exits apart: unlike other types of relays, exit relays also do DNS resolution for Tor clients, so the exit is also where a site’s name is looked up on the client’s behalf. For that reason the page tells operators not to use Google, OpenDNS, Quad9 or Cloudflare as a primary or fallback resolver, to avoid centralization, and recommends a local caching resolver that validates DNSSEC.

The exit is not fixed. The Tor Project’s page on guard relays says the first relay in a circuit usually stays the same for two to three months, while the rest of the circuit changes with every new website. Its page on CAPTCHAs says the “New Circuit for this Site” button in Tor Browser gets a different exit relay, and therefore a different IP address. For what that button does not change, see our page on whether Tor Browser is safe.

The sources word this differently, so here are the three wordings in turn. The Tor Project’s FAQ, which we read as an archived copy from 2019, asks whether exit nodes can eavesdrop and answers yes: the operator “can read the bytes” going in and out. It adds that Tor anonymizes the origin of the traffic and encrypts everything inside the network, but does not encrypt all traffic across the whole Internet, and it advises end-to-end encryption such as SSL for sensitive connections. Its corollary is that someone worried about interception who is not using end-to-end encryption should not think Tor is the problem.

The EFF’s Surveillance Self-Defense guide to using Tor puts it more softly. It says it is technically possible that exit nodes may be monitored, that this still “doesn’t reveal your traffic”, and that it is more of a concern for whoever runs the exit node. Malware Patrol, a security vendor, says the exit sees the content of the request unless it is encrypted with HTTPS, but not the origin IP address of the user. The three wordings differ in emphasis: the FAQ says what the operator can read, the EFF says what the monitoring does not reveal, and the vendor ties readability to HTTPS. The pages we read do not reconcile them. Two of the three tie what an exit can read to encryption, the FAQ through its advice on end-to-end encryption and the vendor through HTTPS; the EFF’s sentence does not mention encryption, so we do not claim it says the same.

Tor Browser has a setting for this. Its support page on secure connections says HTTPS-Only Mode ensures connections to websites are always encrypted whenever possible, and that it helps prevent eavesdropping, tampering and man-in-the-middle attacks on unencrypted HTTP connections. If a site has no HTTPS version, the browser shows a “Secure Connection Not Available” page. Choosing “Continue to HTTP Site” accepts the risk and turns the mode off temporarily for that site, while “Go Back” avoids any unencrypted connection. The EFF’s guide says the browser uses HTTPS-only mode and NoScript by default.

One more case comes from the EFF, in a post from March 2012. If an adversary controls both the relay you enter the network through and the relay you leave it through, the post says, it can correlate the size and timing of your traffic and so identify you. That adversary would have the origin and the destination, but with HTTPS it “will not be able to read” the content. The EFF names agencies with particularly vast resources as the kind of adversary it means, and suggests running a relay to help.

Here is what the pages we read do not say. Whether an exit on its own, with no control over the entry, can tell which site an HTTPS connection is going to is not spelled out in them. We have not filled that gap from memory.

The clearest case on record is a Tor Project advisory dated 14 August 2020. It says that in May 2020 the project found a group of exit relays that left almost all exit traffic alone and intercepted connections to a small number of cryptocurrency exchange websites. If a user visited the HTTP version of one of these sites, the relays prevented the site from redirecting the user to the HTTPS version. A user who did not notice that the lock icon was missing, and then sent or received sensitive information, could have had it intercepted. The project removed those relays in May 2020. In June 2020 it found another group doing a similar thing and removed that one too.

The advisory gives two sizes. The first group was offering approximately 23% of the total exit capacity, and the replacement group about 19%. It says the project does not know whether any users were successfully attacked. It also says that, from the size of the relays and the fact that the attacker tried again, it is reasonable to assume the attacker thought the attack was a good use of resources. The advisory does not say who was behind it.

The lesson the advisory draws is about HTTP. HTTP requests are unencrypted and unauthenticated, it says, and so still prone to attack. HTTPS-Everywhere, which Tor Browser included at the time, mitigated that only partly because it does not list every website, and users who visit the HTTP version of a site “will always be at higher risk”. The project asked website administrators to enable HTTPS and add a redirect rule for HTTPS-Everywhere, and asked web services interested in avoiding exit nodes entirely to deploy onion sites. For users, it was exploring a way to disable plain HTTP in Tor Browser. The secure-connections page we read now describes HTTPS-Only Mode, as covered above; it does not say whether the mode grew out of that work.

The advisory also explains why this is hard to catch. It names two problems. Given an unknown relay, it is hard to know whether it is malicious, and attacks that touch only a few sites or users are harder to spot than those that touch many. Given a group of unknown relays, it is hard to know whether they are related, a pattern known as a Sybil attack, because many volunteer operators use the same cheap hosting providers, and ten new relays could be ten new volunteers or one big one. The project says it had created a Network Health team in 2019, and that in April 2020 it laid off a third of the organization and moved that team’s staff to other work.

The project’s FAQ describes the standing remedy. When an exit is misconfigured or malicious it is given the BadExit flag, which tells Tor to avoid exiting through that relay, so that in effect it becomes a non-exit. The same FAQ says exit relays must not filter the traffic that passes through them, and that those found filtering get the flag once detected. The advisory adds that contributors watch the network and report malicious relays to be rejected by the Directory Authorities, and that the project was still under capacity for monitoring.

The Tor Project’s support page on CAPTCHAs says sites ask Tor users to solve them, or show warnings about unusual activity, because many people share the same Tor exit relays and not because Tor itself is unsafe. Thousands of users may be on the same relay IP address at the same time. Sites often read that as many automated requests or logins from one address, or as traffic that resembles bots, crawlers or malware, and answer with CAPTCHAs, temporary blocks or warnings about suspicious or infected traffic. The page says to try “New Circuit for this Site”, to wait because these warnings are often temporary, or to use services that are friendlier to Tor users, and gives DuckDuckGo as an example. It says the warnings do not mean Tor Browser is spyware or that the device is infected.

The page also says that, to its knowledge, most large websites are not specifically trying to block Tor, and that their automated abuse detection simply cannot tell Tor traffic apart from suspicious traffic. The FAQ gives the Google case in more detail and offers two explanations. One is that Google reads the high volume from a single address, the exit relay that happened to be picked, as someone trying to crawl its site, and slows that address down for a short time. The other is that Google tries to detect spyware that sends distinctive queries, notes the addresses they come from without realizing they are exits, and warns connections from those addresses. The FAQ calls the problem known and intermittent.

Sites can also check for exits directly. In a post dated 9 March 2020, the Tor Project describes its Tor Exit List service, which maintains lists of the IP addresses used by exit relays. There are three interfaces: raw measurement results archived by CollecTor, a text file of all exit addresses to download, and a DNS service for real-time lookups. If a client address is an exit relay, the new DNS service returns an A record of 127.0.0.2. The post says service providers may find it useful to know when users come from Tor because they may want to offer an onion service, and that the project also uses the information to maintain a healthy network. It also says that an address seen as an exit relay in its active measurements is listed regardless of the exit policy.

A reply in the comment thread under that post says it is not a goal of Tor to provide access to websites that do not want it, and that part of the reason for the service is to help websites that want to block Tor do so with minimal damage to the network. That is a comment and not the post, and we cite it as such.

The view from the site side, which is what most of the vendor pages in the search results cover, is a trade-off rather than a rule. Malware Patrol says many security teams block inbound or outbound traffic involving known exit nodes, especially where they do not serve anonymous users, but that this may produce false positives if your service intentionally serves Tor users, and that blocking is not always the right choice for organizations that support privacy, activism or global accessibility. It also notes that exit addresses change frequently, so any blocklist needs automatic updates. That is one vendor’s advice, not the Tor Project’s.

Not every relay is exposed to this. Bridges are not in the public directory, and the relay types page says that makes them unlikely to be blocked by popular services and unlikely to attract abuse complaints. Our page on Tor bridges and censorship covers what they are for.

The Tor Project’s relay types page says exit relays have the greatest legal exposure and liability of all the relays. If a user downloads copyrighted material through your exit, it says, the operator may receive a DMCA notice, and any abuse complaints go to the operator through the hosting provider, depending on the WHOIS records. Most complaints, it adds, can be handled through template letters. Because of the exposure, the page says not to run an exit relay from home, and that ideal operators are tied to an institution such as a relay association, a university, a library, a hackerspace or a privacy organization, which can offer more bandwidth and is better placed to handle complaints.

A separate support page gives examples of the complaints. Someone connects to Hotmail and sends a ransom note to a company, and the FBI sends the operator a polite email; the operator explains that it is a Tor relay and, the page says, the FBI replies “oh well” and leaves the operator alone. Someone posts spam to Usenet and writes an angry mail to the operator’s ISP. Someone makes a nuisance on an IRC network, on port 6667. Someone downloads a film and the ISP gets a DMCA takedown notice. The page says that with an exit policy allowing exits, such as the default one, it is probably safe to say you will eventually hear from somebody, and that a relay’s IP can be blocked by some sites regardless of its exit policy.

The setup page for exit operators is practical. It recommends servers dedicated to the purpose and says not to mix your own traffic with the exit’s. Set a reverse DNS record that makes it obvious this is a Tor exit, with something like “tor-exit” in the name, and serve an exit notice page so that anyone who browses to the address learns what it is. The page describes doing that with the DirPort setting and notes that DirPort has been deprecated since Tor 0.4.6.5. It says defining the exit policy is one of the most important parts: fewer ports mean fewer abuse emails and also a less useful exit, and a new exit should start with a reduced policy and open it up later.

The EFF’s legal FAQ for relay operators is addressed to the United States and says it is not legal advice. It says the EFF believes running a relay, including an exit, is legal under US law, but that it is practically impossible to stop an exit being used for illegal activity, and that police have mistakenly attributed an exit’s traffic to its operator. It gives two examples: Seattle police raiding a privacy activist’s home in 2016, and a Russian relay operator who was wrongfully arrested and later cleared. It also says the EFF is not aware of an individual being sued, prosecuted or convicted for running a relay. On home use it agrees with the Tor Project: it calls it risky, suggests a commercial facility that supports Tor with a separate IP address, and says to tell the ISP and be open about running the exit.

On whether an operator should look at the traffic, the FAQ asks whether an operator should snoop on the plaintext traffic that exits through the relay, and answers no. It says operators in the United States can possibly create civil and even criminal liability under state or federal wiretap laws if they monitor, log or disclose users’ communications, that operators elsewhere may face similar laws, and that an operator should not examine communications without first talking to a lawyer.

The two sources are not equally confident about copyright. A Tor Project blog post of 1 July 2010 says the project and the EFF’s lawyers believe Tor nodes qualify as transmission providers under DMCA 512(a), not 512(c), which exempts them from notice and takedown, and then adds that your ISP may see things differently. The EFF’s legal FAQ, which is marked “Last Reviewed: March 2023”, says that 17 U.S.C. 512(a) provides a safe harbor for material that is simply transmitted without modification, as a Tor relay does, and that relays should be protected from copyright liability because an operator can raise an immunity defense under Section 512, and also says no court has yet addressed these issues in the context of Tor itself. For anyone uneasy with that, it suggests a reduced exit policy. The 2010 post also says that suit had not yet been brought against any Tor operator. We report both with their dates and do not settle between them.

The Tor Project’s onion services kit makes the case in terms of the exits themselves. Traffic to an onion service does not leave the Tor network, it says, so those circuits free up exit bandwidth for others. It calls exit relays a limited resource that is in general overloaded and a bottleneck for browsing. A service available as an onion service uses a different set of circuits, avoiding exit relays completely, and the kit concludes that onion services and their users are immune to attacks related to bad exit relays. The kit gives a share of the relay count for exits; we have not used it because we did not read a current count.

That is why the 2020 advisory asked websites to deploy onion sites, and why the exit list post mentions onion services as something sites can offer to visitors who come through Tor. The EFF’s guide adds that a .onion address is hidden, unique and provides end-to-end encryption, and that only what you do inside Tor Browser is anonymized.

For someone who wants to help the network without the exit’s exposure, the EFF says a bridge or a middle relay may be a better fit, because those relays do not directly forward traffic to the Internet and so cannot easily be mistaken for the origin of unlawful content. The Tor Project’s relay types page says the same of bridges where complaints are concerned. If you are weighing the tool itself, our pages on opsec in plain words and on Tails OS cover the habits and the system around it.

Some things are missing from the pages we read, so we have not written them. They give no current count of exit relays; the Tor Project’s metrics pages are dynamic and we did not read them. On the FBI, they mention it only in the support page’s example of a polite email about a ransom note.