Securing a BitTorrent Sync EC2 Instance

Dropbox is a jewel of the Y-Combinator industrial complex: a successful company that provides software as a service to ordinary people. They even allegedly turned down an acquisition offer from Steve Jobs. Their success is no small feat, but sadly it appears that they had to make a deal with the devil to achieve so much.

From my perspective, the company has been acting suspiciously for a while. Appointing George W. Bush’s Secretary of State to their Board was a big red flag. It inspired a whole Drop Dropbox movement. I’ve been uneasy about Dropbox, but when they announced they’d be integrating in with my operating system’s kernel, I decided to move away from them.

I’ve been trying to move away from online services that allow easy mass surveillance. For example, I started in 2012, when I moved off of Gmail. It’s not been easy, I think in part because services that are popular are typically ad-supported – viewing your data is how they sell ads to you – this implies a lack of end-to-end encryption, and security in general. I’ve been tolerating Dropbox because it’s so damm convenient, but the kernel extension was the last straw, so I asked for alternatives.

The solution that appealed to me the most was BitTorrent Sync. It’s closed source (boo) but on its face, offers a good compromise between security and convenience. I decided to give it a try, and in the process I ran into confusing documentation and tutorials that would make me less secure than using Dropbox. It really sucks that in order to securely do something as commonplace as syncing files, you have to be pretty tech savvy. While I’m continuing to evaluate it for a sync solution (I’m not yet ready to commit to BitTorrent Sync), I’m hoping this post will be a resource for anyone who wants to use BitTorrent Sync securely.

(But I’m hopeful that next month we’ll see Apple show us some awesome end-to-end encryption features for iCloud Drive, too.)

I am not a security expert, so I’ve marked the aspects of this post that I’m not 100% sure of with [?] so that I can be honest about what I know. If you can verify – or correct – something I’m unsure of, please let me know or send a correction. My hope is that this post can evolve to be somewhat authoritative instructions on how to securely sync files across devices, aimed at people who are computer savvy but maybe not familiar with server administration and security (like me).

# Overview

Okay, so BitTorrent Sync is a service that runs on computers and synchronizes files across them using BitTorrent. Cool. All of the posts I read on setting up BitTorrent Sync on a server used features available only with a purchased license at at $40/year, with a 30-day trial. This actually introduces security problems when used with all the setup instructions I’ve found; one of my two recommendations in this post is to not use these features on your server. I’ll get to that later.

BitTorrent Sync is a really impressive service that provides a tonne of awesome features. I’m probably not going to use most of them, but crucially, it provides secure syncing of files across computers and smartphones.

The BitTorrent protocol is inherently decentralized, so naturally syncing with BitTorrent is decentralized too. If you have two computers online, and add a file to one, then it’ll get transferred to the other over a secure, encrypted connection [?]. But consider the following scenario:

  1. Computer A is on, B is off.
  2. Add a file to A.
  3. Turn A off.
  4. Turn B on.
  5. The file isn’t sync’d to B, because A isn’t online to send it.

The solution to this is to have a computer that’s running BitTorrent Sync that’s always on. Unless you have a home server or colocated machine, you’re going to have to use a virtual server. That’s where Amazon Web Services comes in.

AWS is super-popular, but managing it is so infamously unfriendly that there’s a AWS in Plain English site to help. We’re going to use EC2, their virtual server service. The best blog post I found to help this is here, and it’s an excellent reference on how to set up BitTorrent Sync on a new EC2 instance (basically a virtual server). You get a year of free service from AWS, and after that it’s about $10/month (when billed hourly – you can save money by billing monthly or yearly).

The post has some great suggestions, like using a random, pre-configured port for BitTorrent Sync, and allowing incoming connections only on that one port and port 80 for administration. However, there are a few aspects to the post I think can be improved upon:

  1. The post recommends opening port 80 to the entire internet, exposing the BitTorrent Sync dashboard (and consequently, access to your files [?]) to anyone who provides the username and password, which are stored on the server in plaintext.

    Further complicating this problem is the fact that to administer BitTorrent Sync, you send your username and password to the server over port 80 unencrypted, so anyone monitoring your traffic can see the auth details in plaintext [?]. Yikes.

  2. The server syncs your files in plaintext, so an attacker who gains access to the server, or an NSA employee issuing a subpoena to Amazon for your instance’s filesystem [?], now has all your files.

These problems can be pretty easily mitigated. First, though, I need to explain a bit more about how BitTorrent Sync works.

# BitTorrent Sync

What has confused me the most about BitTorrent Sync is that I approached it as a Dropbox replacement, but that’s not its primary use case. Instead, it’s about syncing individual folders with different people, not necessarily across one person’s different devices. To have everything “just work”, you need a license to share identities across devices. If you want a Dropbox-style sync solution with one folder, then you don’t need a license – just add the sync folders manually on all your devices.

The first time you start their app, you create an identity. Under the hood, BitTorrent Sync creates an X.509 certificate that’s used to identify you and authenticate with computers you want to sync with, if you use the licensed features. Nice. To link a new device to your identity, you use a key in text or QR code format.

Your identity can sync folders across devices. Any machine with your identity has access to all your files, unencrypted. This is a security problem if you share your identity with your sync server…

The blog post I linked to suggests adding your identity to your new EC2 instance. I’m not sure this is wise, because an attacker who gains access to the instance now has your files. My solution to this problem is to not use my identity, but instead use encrypted folders.

# Encrypted folders

An encrypted folder is the perfect solution to this problem, and in fact, the docs recommend using encrypted folders for syncing with virtual private servers (which are similar to EC2 instances). So let’s do it!

An encrypted folder is just like a regular folder that BitTorrent Sync synchronizes across devices, except that it adds encryption to the file contents it syncs. But encrypted folders separates the encryption keys for syncing the files and the keys for decrypting the files once they’re sync’d. Your identity automatically has access to the decryption key.

So my solution was not adding my identity to the EC2 instance. Instead, I gave it the “Encrypted Key” to sync with (under the share menu for the folder). This lets the EC2 instance securely sync the files without having access to the decrypted version of the files. Nice.

If an attacker (or Amazon) gains access to the instance, they don’t have access to my BitTorrent Sync identity and they don’t have access to my files in plaintext form. Awesome.

Encrypted folders does a tonne to help security on my instance, but it’s not my only concern with the setup instructions I found. Remember, administering the server over HTTP without encryption means an attack could sniff out my username and password from my traffic [?], so what’s to be done?

# SSH Tunnelling

The blog post suggests opening port 80 to the entire internet, so anyone can access the BitTorrent Sync dashboard (provided they have your password, which they can sniff). I’d recommend limiting HTTP traffic over port 80 to just the instance itself, so that no one from the outside world can access it at all.

But you’re in the outside world, right? So how do you access the dashboard? You use something called SSH tunnelling.

When you first create your EC2 instance, you’re given a certificate to log into the machine over SSH. What I’m suggesting is to use SSH tunnelling with that certificate to redirect all traffic to your personal computer over the SSH tunnel to the instance, where it’ll be accessing itself locally. Basically, I want to go to localhost:9000 on my laptop and have SSH redirect traffic over an encrypted tunnel to the instance, where it’ll try to access itself (the instance) on port 80.

First, configure your security group in EC2 to restrict port 80 access to 127.0.0.1/0 (instead of 0.0.0.0/0, which means “anyone”).

Security Policy

Then open a terminal and use the following command:

ssh -i path/to/your/certificate.pem -N -L  9000:ec2-XX-XXX-XXX-XXX.compute-1.amazonaws.com:80 [email protected]

This command redirects traffic from port 9000 locally over the SSH tunnel to port 80 on ec2-XX-XXX-XXX-XXX.compute-1.amazonaws.com on the other side of the tunnel. Modify path/to/your/certificate.pem to point to your actual EC2 certificate that was created when you launched the instance, and change ec2-XX-XXX-XXX-XXX.compute-1.amazonaws.com to be the public DNS of the instance.

Dashboard accessed through SSH tunnelling

Run the command and go to localhost:9000 on your computer. With BitTorrent Sync is running on the EC2 instance, you’ll be prompted for your username and password to access the dashboard. Since all the traffic is routed over the SSH tunnel, no one can sniff out the plaintext credentials.

After you have your initial, encrypted sync folder set up, you could configure BitTorent Sync to not provide a web UI. It will continue to sync your encrypted folder, but not provide any configuration capabilities to the outside world. Since I’m still messing around with it, I haven’t done this yet.

# Wrap Up

It sucks that all this setup is necessary to use BitTorrent Sync on an EC2 instance, and it sucks that it costs money. Dropbox is easier and more convenient, and has a free plan that’s pretty enticing for most users. If you’ve read this far, you probably take security seriously and don’t want the NSA snooping on your sync’d files. To me, it’s worth it.

While I was critical of BitTorrent Sync’s documentation, it is a step in the right direction, and I hope they continue to make setup easier. As for AWS, there are other solutions like DigitalOcean that might be easier. Cloud server administration is a lot simpiler than it used to be, and combined with cool services like BitTorrent Sync, I hope we can all take a step towards and end-to-end encrypted future.


Thanks to Jeremy Beker, Aaron Vegh, Orta Therox, and of course my wife for their help proofreading this post.


Posted on May 30, 2016