HowTo: rtorrent & SSL certificates
Posted by HokieTux on July 13, 2008 in Hacks
Since Comcast decided to shove their heads up their fourth point-of-contact and muck with all torrent traffic (apparently not realizing that there are many legitimate uses for the protocol despite what the MPAA/RIAA would have everyone believe), using HTTPS announces with trackers has become a necessity if you are stuck with Comcast as an ISP. Unfortunately, getting this running with many clients isn’t always as easy as it should be. This post will focus on getting SSL certs working with rtorrent.
I’ve now run into problems with SSL certificates and rtorrent twice, and it has been a little different both times due to changing versions of rtorrent and the libraries it depends on. The first time I hit a problem, the error message was:
Peer certificate cannot be authenticated with known CA certificates
The second time, the error was:
problem with the SSL CA cert (path? access rights?)
Regardless, the fix was mostly the same. First, you need to get the SSL certificate from your tracker. You can use this bit of code to do the job:
# openssl s_client -connect <your tracker.com>:443 </dev/null 2>/dev/null | sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' >> /etc/ssl/certs/ca-certificates.crt
You will need to put that all on one line in your terminal. Also, remember to replace <your tracker.com> with the base URL of your tracker. Also, if you run into an error where ca-certificates.crt doesn’t already exist, just use one ‘>’ near the end of that code line instead of ‘>>’ (the difference being that ‘>>’ appends to an already existing file, and ‘>’ will create the file).
Now, you need to rehash your certificates. Run:
# c_rehash
from your /etc/ssl/certs directory. You should be all set now. Verify that everything is working properly using curl:
$ curl -I --capath /etc/ssl/certs https://your_tracker.com
The next time you fire up rtorrent, you shouldn’t have any problems. If you do, then try starting rtorrent like this:
$ rtorrent -o http_capath=/etc/ssl/certs
If you still have problems, post a comment here and I will try to help you out. If you use Arch, you can also post there. Here are a couple of threads you might find useful:
- rtorrent error & ca certificate
- rtorrent certificates problem (this is actually a thread I started the first time I had the problem)
Thanks to the fellow Arch users out there (especially those in that first thread) that helped me figure this out, and happy torrenting! Cheers!
14 Comments on HowTo: rtorrent & SSL certificates
They upgraded our upstream to 1mbit this month. I was astonished, everything was working smooth and the bits flowed upwards with ease. But it was a trick! I hit the download-pie-in-the-sky a few weeks later and back came the throttling. A different kind of throttling, aimed towards the notion P2P is working again and Comcast had a change of heart. Think again!
I noticed Comcast probably blacklists trackers before throttling is enabled. A popular new tracker recently started and I’m having no problems whatsoever seeding on it (but only what I’ve downloaded). The “big deal” to me is, it appears rtorrent is no longer the appropriate BitTorrent client to use on Comcast. At best I would get full speed for a little while, half speed for a while, then nothing. I’ve switched to Azureus and my upload has been full speed for the last 24 hours on this new tracker. For a few hours I was even competing with a seedbox out there. But, I hate Azureus. I still love rtorrent. It’s too bad rtorrent is designed for high-throughput connections, and probably always will be thanks to it’s single-minded developer.
I too wanted to announce in rtorrent with SSL. The problem is, only one of the trackers I use supports HTTPS. It’s common for admins to use separate configurations for the announce URL, so viewing the tracker pages in HTTPS does not necessarily allow you to announce over SSL. The solution to me, is to configure curl to use a proxy on localhost, tunneling through SSH to a remote proxy. But the problem is, the only way to achieve that is to rent a seedbox in the first place! Who would trust a proxy with all their passkeys?
Tips on how to optimize rtorrent for 6mbit/1mbit Comcast would be very appreciated. I think it has something to do with the way the data is paged from the files. rtorrent wants to spit out data quickly, but as a Comcast subscriber I’m more concerned with availability.
Thanks for the well thought-out comment and suggestion!
I’ve not tried another client since switching to rtorrent, so I probably wouldn’t have realized the difference between them. Thanks for noticing it and mentioning it!
I agree that relying on trackers to implement secure announces is not the best solution – achieving full encryption via an SSH tunnel, like you described, is most certainly preferable. Short of having your own proxy stashed away somewhere (and on a solid ISP), I’m not sure there is a solution other than renting a seedbox, sadly. I, too, have never rented a secure proxy for the exact reason you describe – how do you know you can trust them?
Regardless, optimizing rtorrent for our somewhat less-than-desirable connection is a great idea. I’ll look into it and post what I can find =)
Cheers!
I’ve done some research. In the process I learned forgotten facts about the BitTorrent specification. My conclusion: encrypting and/or proxying tracker connections alone will not help much.
After closing Azureus, I modified and compiled one of my C templates. Its function is to listen, accept, and display data received from the same TCP port Azureus was using. The result was an alarming number of incoming connections blurting “BitTorrent protocol” immediately. I believe these are old, plain-text, or plain-text preferred clients.
If one does encrypt tracker connections, they will soon meet with thousands of these unavoidable red flags. Requiring encryption simply terminates these connections. The relentlessness of these requests, combined with the nature of TCP/IP (one application per port), permits the reasonable classification of all connections to that same port (until all connections are closed) as throttle bait.
That’s not to say encrypting your tracker connections isn’t a good idea. It, along with proxying, are two essential elements in a solution I believe will work. What we need is to verify each peer before allowing rtorrent to interact with them. No inbound connections. Outbound connections are better because they originate from different port numbers.
This can be accomplished by creating specialized proxy software for BitTorrent. The proxy, on a different connection, overwrites ones announce requests with the IP and port number of its own. The incoming connection attempts, along with the peer lists received from the tracker, would be validated before fed back to rtorrent on the next announce. Because we’re announcing to the proxy, we can specify a short announce interval without hammering the tracker. If we want faster addition of validated peers, we could use XMLRPC.
I don’t think I can rest until I at least give this a try. I have access to a handful of DSL and Cable connections I could use to test with. If anyone would like to collaborate on writing the proxy, I think that would be great! It’s just a handful of arrays, buffers and socket handling. If it works, it would justify the purchase of an networked appliance.
This is a really interesting idea, and one I would love to get involved with.
I’m leaving for three weeks next weekend (August 2nd or 3rd), but prior to that, and after I get back (sometime around the 20th of August), I would certainly be willing to help out with the coding. In fact, we can host the code-base on this server (hokietux.net) using bzr or subversion.
Contact me at hokietux@gmail.com =)
You can also do it this way:
- Find out who issued the cert for your your “tracker.com”
- Download the ca-cert to a file (the steps above) or through the issuers home page
Now you can run:
# rtorrent -o http_cacert=/path/to/a/file/with/the/ca-cert
or add the following to ~/.rtorrent.rc
http_cacert =
Re: Michael
Ah! Cool! Thanks for the tip =)
Hi,
How do you cope with subdomains. ie I have the CA cert for the domain example.com but the torrents are on torrent.example.com. This seems to break the SSL model. Is there anything that can be done on the client side or do you have to wait til the admins of the server fix it.
doopa,
Honestly, I’m not sure how to handle that. If someone else has a solution, please post it.
im trying to get rTorrent running with SSl certificate on Mac OSX, and it keeps coming up with “Unsupported Protocol error”. Ive done everything possible to no avail. When running the command “curl -I –capath /etc/ssl/certs https://your_tracker.com” i get the error “curl: (1) Protocol https not supported or disabled in libcurl”
Where do i go from here??/?
Any help gladly appreciated
Nagen
Nagen -
OSX handles SSL certificates very, very differently than Linux does. I’ve never tried to work with SSL certs on an OSX system, to be honest.
Have you searched around in the Apple forums? There may be a topic about manually handing SSL certs?
Let me know if you find anything…
Cheers,
Ben
@Ben
OSX handles certificates very differently but we dont wanna use keychain for this.
Make sure you have MacPorts installed.
What i found was an error with Curl and SSL and their dependencies which is fixed by using
sudo port deactivate curl
sudo port install curl +ssl
then using cacert in the rtorrent.rc file eg: http_cacert=./cert/cert.pem
capath didnt seem to work.
all fixed
nagen
Nagen -
Oh wow, awesome!
Thanks for posting your fix! =)
Cheers,
Ben
Thx for the nice tip!
Works flawlessly!
@ Nagen,
I followed the
sudo port deactivate curl
sudo port install curl +ssl
steps, but dont understand what you mean by
then using cacert in the rtorrent.rc file eg:
http_cacert=./cert/cert.pem
is that some file I have to edit? sorry I’m new to rTorrent (switching from KTorrent) on OS X
Subscribe
Follow comments by subscribing to the HowTo: rtorrent & SSL certificates Comments RSS feed.