Running PageKite over Tor (or SOCKS5)
Tor is a network of virtual tunnels that allows people and groups to improve their privacy and security on the Internet. By using a technique called onion routing, Tor provides strong guarantees of anonymity.
PageKite has from the very beginning been compatible with the Tor network. Combining Tor and PageKite can be useful in a few different scenarios:
- Simulating a Slow Network
- Hiding a Server's Location
- Protecting Publisher Anonymity
- Problems (and solutions)
Each of these will be discussed in more detail below, but first we'll describe how to use pagekite.py, Tor and the PageKite service together - that's the easy part!
Connecting over Tor (or SOCKS5)
Once you have Tor installed on the machine hosting your website and PageKite configured to expose your web server to the world, you can instruct pagekite.py to route all traffic over Tor by using the --torify argument, like so:
# Fly a single kite using Tor:
$ pagekite.py --torify=localhost:9050 yourkite.pagekite.me
# Fly all kites using Tor:
$ pagekite.py --torify=localhost:9050
This assumes Tor is running on localhost, on its default port of 9050.
If you want to make this setting permanent, edit your pagekite configuration file and add something like this:
# Route all connections over Tor
torify=localhost:9050
The configuration file is generally located in $HOME/.pagekite.rc, pagekite.cfg or /etc/pagekite.d/20_frontends.rc, depending on your operating system and how you have installed the software.
If you do not care about anonymity or want to use some other SOCKS5 proxy, the --socksify argument can be used instead of --torify.
Please see below for some common problems and proposed solutions when connecting over Tor.
Simulating a Slow Network
Kites (websites) flying over the Tor network, will be quite a bit slower than other kites. This is caused by the fact that the traffic between pagekite.py and the front-end relay servers (your kite's public IP) is encrypted and relayed between at least three random hosts on the Internet before reaching its destination. This often adds up to 1-1.5 seconds of latency.
Adding latency and making a website slower can actually be very useful if you want to get a feel for how a new site will perform for users on a heavily saturated network, using a satellite connection or using poor 2G mobile service. For some sites, particularly mobile websites, these conditions may be surprisingly common.
When using Tor to simulate a slow network, you generally will not be concerned with anonymity and will be better off replace the --torify argument in the examples above with --socksify. This skips the steps taken solely to protect anonymity and will make your kite somewhat more reliable by avoiding DNS caching problems.
Hiding a Server's Location
Using the --torify option will very effectively hide your web server's IP address and thwart basic attempts to discover its location. The PageKite service (or whatever front-end you choose to use) will have no idea where you are connecting from and will not be able to reveal your location even under duress. Your local ISP and others on your local network should also be unable to identify your server as the website's host.
However, nothing is perfect!
First of all, keep in mind that if a site is publishing material which violates our Terms of Service, we reserve the right to deactivate the account.
Secondly - even if your web server's IP address is hidden, it may still leak clues about its whereabouts. Things like the time zone a server is in, or the content of the web site itself may provide clues. Also, due to the fact that an "attacker" can create traffic at any time simply by visiting the website, if someone suspects you may be publishing a particular website and they have the ability to eavesdrop on your local network traffic, they may be able to confirm their suspicions by correlating visits to the site with network traffic patterns. Running a Tor relay, multiple sites or simply sharing a busy network connection may mitigate this risk but cannot eliminate it completely.
Thirdly - if your web server is accessible to the local network, people on your network may be able to connect to it directly and thus confirm the anonymous site is indeed running on your machine. You may be able to avoid this by only listening for connections on localhost (or 127.0.0.1). Obviously if people have access to the machine itself, this becomes trivial.
Protecting Publisher Anonymity
Generally speaking, the most common reason one would want to hide the location of a web server is to protect the anonymity of the publisher. It turns out that true anonymity is a very hard problem. The folks at the Tor project can probably provide better guidance than we can.
Remember that even if your server is hidden, the PageKite service will have a record of who created your account and who pays the bills. We can be compelled to reveal these details through subpeona, or someone might even attempt to steal them by breaking into our servers and customer database.
If these scenarios concern you, you may mitigate your risk by taking steps to protect your anonymity when you sign up for the service, and only using our free offerings.
But please keep in mind that we will disable accounts which we find are in violation of our Terms of Service. Although we support anonymity and believe it is a fundamental human right, we also reserve the right to refuse service to criminals.
Problems (and solutions)
Installing all this stuff is lots of work!
It really isn't. :-) On Debian or Ubuntu, it may in fact just be two commands:
$ apt-get install tor
...
$ curl -s https://pagekite.net/pk/ |sudo bash
...
... and you're good to go! For other operating systems we admit it may take a little bit more work, but you won't regret it - both tools are very useful.
"Temporarily Unavailable" errors
When connecting over Tor, pagekite.py will avoid making any DNS lookups which might leak and reveal to your network administrator or ISP that you are publishing a website over Tor.
This means pagekite.py cannot tell which front-end server it connected to last, and can lead to DNS caching problems if you do not always connect to the same front-end. In practical terms, this means pagekite.py will connect to one front-end, but your web-browser will connect to another one and see an error message instead of your website. This problem is only temporary, as the out-dated DNS records should expire within a few minutes, but it can be both confusing and rather annoying.
These DNS problems can be avoided by manually specifying a particular front-end using the following command or by using --socksify instead of --torify (if you don't care about anonymity). If the front-end never changes, the DNS will always be correct.
# Always use the service front-end located in California
$ pagekite.py --frontend=173.230.155.164:443 ...
For a list of available IP front-end IP addresses, you can use one the following commands:
$ host frontends.b5p.us
...
$ nslookup frontends.b5p.us
...
$ dig frontends.b5p.us
...
On the other hand, hard-coded IP addresses will be unstable in the long-term as we reserve the right to relocate our servers at any time. In practice this shouldn't happen more than once or twice a year, but keep in mind that it is a possibility.
The Beanstalks Project ehf.
Comments