Thanks to lenk, we now have a secure (HTTPS) tracker in addition to our normal (HTTP) tracker.
The new secure tracker will circumvent ISP packet analysis which can lead to BitTorrent transfer throttling. For example, in our tests Comcast throttling was completely negated by using the HTTPS tracker!
In order to use the HTTPS tracker, your client must accept a self-signed certificate. Keep in mind that not every client supports the HTTPS protocol, so please make sure that yours does before you switch over. Also note that you will have to re-download all of your torrents after switching to the HTTPS tracker since the secure tracker uses a different URL.
To switch to the secure tracker, simply change the "Download type" in your profile to "Secure".
More information can be found in our FAQ.
Feb 8, 2009: Added a more detailed explanation and instructions:
Show/HideWhat is this about?
First some generic info:
A bittorrent tracker maintains lists of the clients currently participating in the torrent. If you add a torrent to your client, the first thing it does is connecting to the tracker to let it know you're there and at which port you're listening so the tracker can add you to the peers list. Of course, it also retrieves a list of peers. Without it, it would not know of any seeders/leechers (peers) on the torrent, and thus would be unable to download it. Your client connects regularly to the tracker to submit download/upload statistics, to retrieve an updated peers list and of course to let the tracker know you're still there.
To clear one thing up: the HTTPS tracker uses the same peers list as the HTTP tracker. Actually, both are really one and the same tracker. The only difference is that you connect to it securely through https, and not securely through http.
Show/HideWho is it for?
Users whose ISP caps or throttle the bitTorrent protocol, and users who don't like their ISP to be able to see even the client to tracker communication.
Users that are not capped and do not care about their ISP noticing they're using bittorrent have no reason to switch to HTTPS, but since it doesn't have any disadvantages you're free to pick either.
There are multiple ways for ISPs to detect and cap bitTorrent traffic:
• Capping ports 6881-6999, the default bittorrent ports.
This method is fast, but very ineffective since most clients nowadays pick a random port number when first launched to counter this method.
You can counter it by changing your port number to anything other than the above.
• Inspecting packets, and recognizing bitTorrent packets
This is a resource intensive method that requires your ISP to monitor all your traffic. Once bitTorrent traffic is recognized it can take action by either throttling traffic over the port(s) you're using, by blocking x% of the packets, or by sending false disconnect messages to drop your transfer every second.
You can counter it by turning on protocol encryption in your client, and only allowing encrypted clients to connect.
• Counting the number of connections going out from a certain port
I do not know if this method is used at all, but it is theoretically possible. Limiting the maximum allowed connections in your client to 10 or maybe a bit more would effectively counter it.
• Intercepting client to tracker and tracker to client communication
This is a very elegant method, and extremely effective. To us users however, it's awfully annoying. Your ISP only has to monitor traffic on port 80 (http), and fetch a tracker announce. The tracker sends all peers and the ports they're listening on to your client, while your client sends the port its listening to on the tracker. By intercepting tracker communication your ISP instantly knows everything about your transfer and can either decide to cap/cut your traffic to the other clients, or to cap the port(s) you're using.
This is the method Sandvine uses, a bandwidth management system used in certain areas by Comcast, UPC and other ISPs.
You can not counter it by using protocol encryption, lazy bitfields or any other client method, after all, the ISP doesn't even have to look at that - by intercepting the tracker communication it already knows enough. It's also hard to detect by bittorrent emulators created to test for this kind of thing - after all, it won't cap anything if there's no tracker communication. So yes, it's quite sly, and the worst thing is, it's virtually effortless compared to the other methods!
The only way to counter this method of capping is by encrypting the communication to the tracker. And that's where the HTTPS tracker comes in.
Show/HideI know my ISP is throttling bandwidth... what do I do now?
Your ISP can throttle these IPs for days, so just replacing your HTTP with HTTPS torrent won't do a thing initially. However, setting up your client for the worst case scenario isn't too hard.
To test this out with immediate results, do the following:
• First, remove all of your torrents from your client, regardless of what tracker they run on. Some clients still do a scrape tracker request occasionally when torrents are inactive - so you really need to remove them.
• Make sure your client supports HTTPS/SSL trackers. µTorrent, Azureus and Transmission all support HTTPS trackers and all the options listed below.
• Now, with your client empty, change the port number to bypass any possible port cap that might still be in effect. You may need to reconfigure your router/firewall to open this port.
• Enable transport encryption, and do not allow unencrypted peers to connect - just in case your ISP inspects packets too.
• Set the maximum connections in your client to 10 or 20, not higher.
• Restart your client
• Now that everything is taken care of, get a torrent from UG that you haven't had in your client for at least a week. This in case your ISP throttles peer IPs regardless of ports. Ideally, you should upload your own torrent and wait or ask someone in IRC to try downloading it. With you as only seeder this should be the perfect way to test if you're able to upload normally again.
All that remains is enjoying seeing your torrents going full speed again! If you've confirmed this working, you'll want to try to undo the first four steps one at a time to find out what triggers the capping, and what not. If adding a torrent with a normal HTTP tracker slows you down instantly again, your ISP throttles your port. In this case, you should use two bittorrent clients: one for UG and other HTTPS capable trackers using a different port than the other, which is for public and normal HTTP trackers.
For me (lenk), HTTPS only on a different port works already. My upload went from the 0-4KB/sec to the full 180KB instantly - and that's the first time I've seen upload speeds above 4KB/sec on Underground Gamer since my ISP started capping BitTorrent using Sandvine one and a half year ago. That means that I can finally upload some torrents again!
Now, these instructions aren't hard, but not clear for everyone and different clients have different names for the same options. It would be awesome if some of you could make a step-by-step tutorial for your client and post it in the topic or the Underground Gamer wiki. Feel free to add to/improve on this post as well. Also, let us know what works for you and what does not on your ISP!
Last edited by lenk at 2009-02-09 18:01:49
