Bittorrent Encryption

There’s been a bit of excitement recently about ISPs – namely Comcast – throttling or traffic-shaping bittorrent file-sharing traffic; in the case of Comcast, they’ve reportedly blocked all outgoing torrent traffic, which of course defeats the whole point of file sharing.

The usual answer to this problem is to use bittorrent’s native encryption support. I have a pretty good hunch that this isn’t totally foolproof from a traffic-analysis standpoint, and will still leave your ISP able to tell that you’re file-sharing, just not what you’re sharing.

To that end, I decided to try out my swiss-army-knife of encryption tools, an SSH tunnel. Not being a 3l33t f1l3-5h4r3r, I had to hunt down a bittorrent client; I chose utorrent, and downloaded it. I then set up utorrent to use an SSH tunnel to a remote machine elsewhere in the world, and tried to download the latest DSL image via torrent. It took a few minutes to get utorrent working, but without a whole lot of difficulty I managed to configure it so that all torrent traffic (with one or two possible exceptions I haven’t confirmed yet, see below) is transmitted through the SSH “tunnel”, regardless of whether a given peer’s client supports protocol-level encryption or not. As far as I can tell, it even accepts incoming connections correctly at the “remote” end.

It’s not a perfect solution, by any means, but it pretty well eliminates the ability of your ISP to tell you’re file-sharing. (Whoever owns the server you’re using at the remote end can, of course, tell – but there are many shell account and VPS providers out there, whereas many people have but one choice for a home ISP.)

For what it’s worth, the utorrent settings I used are, under “Connection:” “randomize port each time utorrent starts”, “Enable UPnP port mapping” (might be specific to my firewall, router, and modem), “Proxy Server type: Socks5”, “Proxy: 127.0.0.1”, “Port: (what I set the SSH tunnel to use), and “Use proxy server for peer-to-peer connections.” Under “Bittorrent”, I have disabled the DHT and Peer Exchange options, as I’m not convinced such traffic is encrypted, and haven’t had time to do testing just yet, and have put in the public IP address of the remote end of the SSH tunnel for “IP to report to tracker”; this last I think really only affects “private” torrents, but it seems to be a potential point for information disclosure. Of course, I’ve enabled outgoing protocol encryption, and allowed incoming “legacy” connections (which are unencrypted), as they’ll be encrypted between the server and my computer, which is all I’m particularly concerned about.

Assuming your internet connection is remotely like mine, and you’re able to get a working SSH tunnel, all your incoming and outgoing torrent traffic should now be encrypted, whether or not you and your peer(s) are using bittorrent’s built-in RC4 encryption.

(I’ve confirmed that all the torrent traffic is encrypted, but I haven’t yet been able to confirm that certain bits of client-end traffic – namely, utorrent’s DNS lookups – are performed properly through the Socks5 tunnel. This is a potential (minor) vulnerability, but nothing to get too terribly excited about; hostname lookups are for the most part protocol-agnostic, and only show who, not what.)

So, if you happen to be stuck with a service provider who won’t let you share Linux ISOs or whatever, rejoice, because you have now another option to regain access to the bits of the internet recently denied you. Enjoy. 🙂

Published in: Geekiness, General | on August 31st, 2007| 17 Comments »

Both comments and pings are currently closed.

17 Comments

  1. On 9/4/2007 at 7:35 pm Mike Said:

    Do you mind telling me what site you got your shell account from?
    I also noticed in your earlier post on SSH that you said it’s possible to create a tunnel without logging in or have an actual shell – now will this work with one of those free shell accounts that are easy to get? Or maybe I don’t fully understand how that works.

  2. On 9/4/2007 at 10:46 pm Nemo Said:

    I don’t have a shell account from a provider, per se – I have a virtual private server (or virtual dedicated server, depending on what term you prefer) from a company overseas; about 8 USD per month for something like 100GB of traffic, 64MB of memory, and a couple gigabytes of space, which is more than adequate for what I use it for.

    A better deal, perhaps, and one I use as a backup is a VPS from the folks at vps4less.de. 4 Euros per month (around $6 USD at the moment) for 1GB space, 64MB memory, and a whopping 2mbit unmetered transfer into and out of the heart of Germany.

    An SSH tunnel should work with any system account on a Unix or Linux machine that runs SSH, even if the shell is set to something like /sbin/nologin, or /bin/false, or whatever (assuming you configure your SSH client not to try and open a terminal after authenticating.) It ought to work fine with any of the free shell accounts out there, but doing anything that uses a lot of bandwidth – like filesharing, or leeching big stuff off RapidShare, or whatever – might be a TOS violation. That’s why I recommend getting a cheap VPS, or two; if you care that much about hiding your internet traffic, a couple bucks a month is a small price to pay (and there are lots of other neat things you can do with a VPS or VDS as well…)

  3. On 9/10/2007 at 4:15 am Neil Said:

    Does doing this hide your true IP from the other peers in the torrent?

    E.g. if I were to use blacknet.proxy.biz as my shell/proxy would setting up a SSH shell and socks5 tunnel hide me from the world?

  4. On 9/10/2007 at 12:33 pm Nemo Said:

    Yes, as long as you disable DHT and peer exchange, which I have not been able to confirm use the SSH tunnel, and set the correct IP/hostname to report.

    I don’t know what other bittorrent clients might work with this; my principal interest is basically academic, and having gotten utorrent working with the SSH tunnel, I’m not inclined to start playing around with others.

    Also, I’d guess that if you’re really concerned about hiding your IP from filesharing peers, even 10GB/mo (and $2/GB thereafter) is going to be fairly limiting; keep in mind that an SSH tunnel, like any proxy, sees each byte sent through it “twice” (or, at least, the machine it’s running on does; a 10GB limit really turns into 5GB, because everything gets counted as it goes in or out “in the clear” between the server and your peer, and also as it goes through the tunnel between you and the server); see my comments above about an unmetered VPS in Germany, for about the same price as proxy.blacknet.biz. 2Mbit is a speed, not a transfer amount, and is of course bidirectional. If you managed to saturate it 24/7 every day (highly unlikely), you’d move somewhat more than 600GB in a month. Realistically, especially on a VPS, there are other limits at work as well, but a couple GB per day is definitely possible.

    IMO, most shell providers are aimed at IRC users, and most proxy services at those who want to browse the web, send email, et cetera; many are probably going to be less than ideal for filesharing use, at least at the cheaper end.

  5. On 9/25/2007 at 10:47 am Thomas Said:

    This solution works like a charm. I’ve been using it and it’s just perfect. 100% Encrypted Bittorrent over SSH over VPN. Now the only annoying thing is that it slows down your download rate but this is just a minor issue.

    Now my question is, what tool can be used to monitor all this and make sure no connections are leaking out of the encrypted tunnels?

  6. On 9/25/2007 at 1:04 pm Nemo Said:

    Thanks for the comments, Thomas. What you use depends on what operating system you’re running, and what exactly you want to achieve.

    On a Windows machine, using a software firewall like ZoneAlarm to lock down access to the internet is probably easiest (because the SSH SOCKS proxy is on your machine, the firewall sees it as the “local zone”, not the “internet zone”.) If you’re running Linux or a *BSD, or don’t mind compiling software on a newer (OS X) Mac, there’s an iptables-based security program (much more than a firewall) called “APF” that can be enabled to do egress filtering, with which you can block everything but port 22, at least while you’re filesharing. There’s also a neat utility called “iftop”, which shows every connection open on your machine, in real-time.

    If you’re really, deeply into P2P file-sharing, an extreme, but OS-agnostic, option is to either configure your router/firewall to disallow all the usual bittorrent ports (or anything but ports 20, 21, and 22), or even pick up a second firewall just to limit the traffic to/from the machine you use for filesharing.

    And, of course, if you want to see if any of that is working as it should, a packet-sniffer (I use Ethereal; there are others) is your best friend.

  7. On 10/14/2007 at 5:39 am Matt Said:

    vps4less is incomparable in price, but looks like a shop that could close any day. How long have you been with them?

    Small world – I’m over in MacGroveland in St. Paul. Totally random Google, but hi.

  8. On 10/14/2007 at 1:29 pm Nemo Said:

    Hi, fellow Saint Paulite. I’ve been with VPS4Less since March or April of this year, on a monthly contract. From what I understand, they’ve been around for well over a year, though they haven’t had much if any of a web presence (at least in English) until recently. Their products as such aren’t really marketed to consumers, but other businesses; they advertise fairly frequently on forums like webhostingtalk.com. I don’t know what their financial situation is like, but they’re not the only German company providing VPSes at a sub-five Euro price point…

  9. On 11/11/2007 at 8:55 am omert Said:

    hey.. my ISP blocks all outbound traffic on voip ports. however i have a windows xp pc at a remote location. can you please help me? i want to tunnel my voip traffic to connect to freeworlddialup or other voip providers.

    my main problem is that my Internet provider blocks most of the outgoing/incoming ports. is there any solution? i even tried to ssh into free ssh account but putty returns connection refused which is similar to what i get while trying to connect to vnc. my internet provider is running ISA to lock down ports.

  10. On 11/11/2007 at 1:03 pm Nemo Said:

    If they’re not doing actual traffic analysis, you *might* be able to get it to work on port 80, which usually isn’t blocked. That said, using a proxy for VOIP traffic is less than ideal, because you’re adding (possibly considerable) extra latency to the connection. It’s also possible that your ISP is blocking or rate-limiting UDP, which is what you need for VOIP.

    Have you tried vbuzzer.com? They’re a VOIP provider based out of Canada, who operate on port 80 specifically to get around ISP blocks. Might be worth looking at.

  11. On 11/12/2007 at 10:04 am omert Said:

    Nemo: skype works fine but i want some sip based service to use. i have tried vbuzzer. the softphone connects but after a while i get some Visual C++ runtime error. skype also works on port 80 but they have their properitory protocol i think. i can’t forward my DID number to skype. Else skype works well for me. SkypeIn number is expensive compared to free service. Plus i can’t get sip calls.

    I don’t think so my ISP is actually doing traffic analysis because Microsoft ISA server doesn’t have that option. I wouldn’t mind a little bit degradation in voice quality. Its a worth a try anyway. something is better than nothing.

    Thanks.

  12. On 12/25/2007 at 8:48 pm Nick Said:

    How does one go about setting up a vps4less account? Do I use a domain I already own, or what? There are no good instructions on their page.

  13. On 12/25/2007 at 10:48 pm Nemo Said:

    Nick – just head over to their order page, and select the plan you want. It’ll prompt you for a hostname, domain name, two nameservers, and a root password. Of these, only the first and last are really important. If you have an existing domain, just use a hostname.thatdomain.tld; if you don’t have a domain, a good option to avoid attracting too many questions might be to use something like “vpn.local.lan”, or “vpn03.local.lan”, or whatever. All that really matters is the hostname – and of course you’ll want to note down the root password. 🙂

    After that, proceed through to payment, and they should send you the required login info – IP address, et cetera – within a few hours. Set up a non-root account to use for your SSH tunnel, configure your application(s) as required, and Robert is your father’s brother, as they say…

    Just to reiterate, I’m a (happy) customer of theirs, but I don’t get anything when you sign up with them, or have any other relationship with them, and if you run into problems with them, I’m not the person to ask for help. 🙂

  14. On 1/7/2008 at 3:42 pm Jim Said:

    I wonder if it’s torrents-over-ssh to which Comcast is now responding…

    On Friday 04 January 2008 around noon PST, Comcast started doing something funny on port 22.

    The company I work for has Comcast business-level service, and I always try to have an ssh connection open to my home machine from my work machine. On Friday, around noon, my ssh connection froze up when I was interacting with it. The ssh server on my home machine was listening on port 22. I notified our company’s help desk, and we ran a number of tests.

    I tried to ssh to a number of different machines to which I have access, in different locations, which have different providers to the internet, and each of them froze up. The 2 factors which all of these machines had in common were the following:

    – sshd was listening on port 22
    – their connection to the internet was not provided by Comcast

    One of the helpdesk guys, however, has his home machine connected through Comcast, and he runs his sshd on a high-numbered (non-22) port. He was able to ssh into his machine from work without anything freezing up. It was unclear whether he was able to keep a stable ssh connection because he was running through Comcast or because he was running on a non-22 port, but he suggested I try to run my home machine’s sshd on port 80 or on port 443.

    So I ssh’d into my home machine, as root, and very, very slowly, I used sed to change sshd’s port from 22 to 443. I then restarted sshd, re-logged in to my home machine, and things have been running fine since then.

    All of our tests invariably led us to the conclusion that starting last Friday (04 January 2008) Comcast made some change which mucked with port 22 traffic. It was unclear whether Comcast-to-Comcast traffic was affected, given that the help desk guy runs his sshd on a non-port 22, but it was definitely clear that Comcast-to-non-Comcast port 22 traffic was being affected. Traffic shaping to lose packets??

    It’s yet one more reason to continue one’s lack of respect for Comcast and their practices.

  15. On 12/17/2009 at 10:13 pm Dan Said:

    I noticed this on vps4less.de TOS:

    Illegal Use

    VPS4LESS servers may be used for lawful purposes only. Transmission, storage, or distribution of any information, data, or material in violation of any applicable law or regulation is prohibited. This includes, but is not limited to:

    * Copyrighted Material

    VPS4LESS keeps the right to charge violators with a 100 € fee.

    100 € fee! how often do you think that happens?

  16. On 12/17/2009 at 10:47 pm Nemo Said:

    Probably very rarely if ever, since I think they only accept payment through PayPal, and would have no effective means of collecting on such a fee from overseas customers.

    The transmission of copyrighted material is not always “unlawful” in every jurisdiction, and I think even where the laws are relatively strict, some common sense can do wonders to help avoid infringement notices relating to bittorrent use. I can pretty much guarantee that neither vps4less or any other server provider proactively monitor the content of traffic on their customer’s machines, so, you know… torrent smart, torrent safe. Or just use USENET, or one of the Megaupload/Rapidshare sites…

  17. On 8/31/2014 at 1:59 am Smitha685 Said:

    Magnificent site. Plenty of useful information here. I’m sending it to some friends ans additionally sharing in delicious. And certainly, thanks in your sweat! efgefgafeffgfdgc