Killing Tor2Web once and for all - detecting and denying Tor2Web-users

I don't like Tor2Web. There I said it. I don't like Tor2Web because it simply destroys the purpose of having an onion. I believe users that use my onion are anonymous to a certain degree, but if a user is using Tor2Web all this anonymity is gone. I can't offer the anonymity that my onion is supposed to offer.

So let's kill Tor2Web once and for all. However, this was harder than I even could have imagine because some instances of Tor2Web are transparent so it's very hard to detect them.

I will share with you my journey on how I worked to detect Tor2Web-users and why I picked up this battle in the first place.


What's the problem with Tor2Web?

The problem is that it's not anonymous. Of course Tor2Web states this several times and a user clearly can't miss it. The problem is that users don't care and an onion is not meant to be used via a clear net proxy, but with Tor.

A user is talking to a clear net website instead of the onion so in theory the proxy can read all the information you're sending and getting from the onion. Also, you are far from anonymous because the Tor2Web-gateway sees your IP.

Another problem is that if the Tor2Web-gateway would be sniffing and modifying traffic, the authority dirs have absolute no power to close the Tor2Web-gateway down.

According to some rumors there have been instances were Tor2Web-gateways actually rewrite Bitcoin-addresses in hope that users send money to the address. I don't know if this is true but it's highly possible.

So to conclude; Tor2Web-gateways reads data that is supposed to be end-to-end and anonymous.

Also, Facebook totally agrees with me:


But why is it hard to detect Tor2Web? Here's why:

  • We can't ban via IP; it has 127.0.0.1
  • Tor2Web can modify traffic. Rely on Js is stupid
  • Tor2Web can be totally transparent

Detecting Tor2Web-users the easy way

The good thing about most of the public Tor2Web-gateways is that they are easy to detect.

First I created a script that checks if the user is on our domains. These domains are base64-encoded because otherwise it could be possible for the Tor2Web-gateway to rewrite them(adding .to, .link or .cab).

Here's the script and how it looks in action:

But there's two major problems with this method:

  1. The user must have Javascript activated.
  2. The Tor2Web-gateway can still remove/change the script.

However, this method works in most cases. But I want to go even further.


Detecting Tor2Web-users the harder way

Okay, let's say a user does not have Javascript. How can we then detect that the user is using Tor2Web? Well, we could check the users HTTP-header. Let's see if we see something that stands out.

onion.link has the header HTTP_X_TOR2WEB so that's fantastic news! We can detect this Tor2Web-gateway on our server side!

onion.to also uses the HTTP_X_TOR2WEB header!

onion.cab does not use this header and the headers are pretty much totally transparent. Damn...

Alright, so now this is rather a mission to detect transparent Tor2Web-gateways because it's fun. Why stop here? Let's see how far we can go.


Digging down the rabbit hole

The first thing I wanted to know was how Tor2Web(and onion.cab) actually rewrites onion-URL's. Does it uses regexp? Does it look for HTML-tags?

So I sat up the Cure53 HTTP-leak document on my onion and tried to visit it over onion.cab. To my surprise there were actually 55 tags that were not rewritten. You can see the complete list here. Note that onion.to and onion.link both rewrote all the links correctly.

So that's pretty interesting. We can use some HTML-tags that onion.cab will not be handling correctly. So we could use any of these tags to force the user to make a request, and if the request was not successful we will know that the user does not use a direct Tor-connection(and therefore uses Tor2Web).

On onion.to/link I found that adding a backslash after the scheme actually does not get rewritten as you can see here:

But this is just one of many many "bypasses" I've found. The bypasses are not important, but rather how you use them and I won't go into detail about that here.

Exploiting the bugs to protecting logins

So we've found ways that we can construct URL's so Tor2Web won't rewrite them. So let's use this trick by simply forcing the user to POST data to an onion instead of via Tor2Web. With this trick, we will "save" the user so its credentials never goes through the Tor2Web-gateway.


Summary and final words

In this article I have shown you how we can use Javascript to detect if a user is not using our domains and also how to detect Tor2Web via HTTP-headers. I've also shown you how you can [mis]use the bugs that Tor2Web has to protect POST-forms such as logins.

I highly recommend that you all stay away from Tor2Web as a user. You deserve privacy. As for you webmasters out there I highly recommend that you also have some sort of protection or notification that tells your users that they should not use Tor2Web.

Last but not least I created a small PHP-script that can detect Tor2Web-users based on headers, UA and via Js: