BitTorrent Developers Introduce Comcast Busting Encryption
Written by Ernesto on February 15, 2008Several BitTorrent developers have joined forces to propose a new protocol extension with the ability to bypass the BitTorrent interfering techniques used by Comcast and other ISPs. This new form of encryption will be implemented in BitTorrent clients including uTorrent, so Comcast subscribers are free to share again.
BitTorrent throttling is not a new phenomenon, ISPs have been doing it for years. When the first ISPs started to throttle BitTorrent traffic most BitTorrent clients introduced a countermeasure, namely, protocol header encryption. This was the beginning of an ongoing cat and mouse game between ISPs and BitTorrent client developers, which is about to enter new level.
Unfortunately, protocol header encryption doesn’t help against more aggressive forms of BitTorrent interference, like the Sandvine application used by Comcast. A new extension to the BitTorrent protocol is needed to stay ahead of the ISPs, and that is exactly what is happening right now.
Back in August we were the first to report that Comcast was actively disconnecting BitTorrent seeds. Comcast of course denied our allegations, and ever since there has been a lot of debate about the rights and wrongs of Comcast’s actions. On Wednesday, Comcast explained their BitTorrent interference to the FCC in a 57-page filing. Unfortunately they haven’t stopped lying yet, since they now argue that they only delay BitTorrent traffic, while in fact they disconnect people, making it impossible for them to share files with non-Comcast users.
In short, the Comcast interference works like this: A few seconds after you connect to someone in a BitTorrent swarm, a peer reset message (RST flag) is sent by Comcast and the upload immediately stops. Most vulnerable are users in a relatively small swarm where you only have a couple of peers you can upload the file to.
For the networking savvy people among us, here’s an example of real RST interference (video) on a regular BitTorrent connection. In this case, the reset happens immediately after the bitfields are exchanged. Evil? Yes - but there is hope.
The goal of this new type of encryption (or obfuscation) is to prevent ISPs from blocking or disrupting BitTorrent traffic connections that span between the receiver of a tracker response and any peer IP-port appearing in that tracker response, according to the proposal.
“This extension directly addresses a known attack on the BitTorrent protocol performed by some deployed network hardware. By obscuring the ip-port pairs network hardware can no longer easily identify ip-port pairs that are running BitTorrent by observing peer-to-tracker communications. This deployed hardware under some conditions disrupts BitTorrent connections by injecting forged TCP reset packets. Once a BitTorrent connection has been identified, other attacks could be performed such as severely rate limiting or blocking these connections.”
So, the new tracker peer obfuscation technique is especially designed to be a workaround for throttling devices, such as the Sandvine application that Comcast uses. More details on the proposal can be found at BitTorrent.org, which aims to become a coordination platform for BitTorrent developers.
TorrentFreak talked to Ashwin Navin, president and co-founder of BitTorrent Inc. who has some of his employees working on the new extension. He told us: “There are some ISPs who would like people to believe that “slowing down” BitTorrent or “metering” bandwidth consumption serves the greater good. Consumers should be very weary of this claim.”
“In recent months, consumers enjoyed unprecedented participation in the political process thanks to the ability to upload opinions and feedback in the YouTube presidential debates. Musicians, filmmakers and artists are finding ways to connect with their audiences across the world thanks to MySpace and BitTorrent. Students are engaging with interactive learning tools in their schools. Which bandwidth intensive application will banned or shaped or metered next by these ISPs? The creative spirit of millions has been ignited, and our need to participate, to communicate will not be silenced.”
“The US government should encourage ISPs to innovate and invest in their networks,” Ashwin said. “Permitting them to interfere or interrupt in the communications of consumers, to protect ISP profit margins, would be a tremendous set back for our country and economy, when we are already slipping behind the first world (UK, EU, Japan, Korea, Singapore, etc) in its broadband capacity.”
We wholeheartedly agree with Ashwin on this one, as we’ve said before. The Internet is only a few years old, if the plan is to keep using it in the future, ISPs need to upgrade their networks. So, invest in more Internet gateway capacity, 10Gbps interconnect ports, and peering agreements. BitTorrent users are not the problem, they only signal that the ISPs need to upgrade their capacity, because customers will only get more demanding in the future. The Internet is not only about sending email, and browsing on text based websites anymore.
The new protocol extension is still under development, but the goal is of course, to get it out as soon as possible.
Hang on…
Previously: Village People Hire Web Sheriff for Assault on The Pirate Bay, ABBA on Standby
Next: PRQ Fire Takes Down Several Torrent Sites
113 Responses (Add yours or TrackBack)
Pages: « 1 [2] 3 4 5 » Show All
OK, so it’s an overly complex tracker extension to prevent an ISP simply reading the peer list and the info hash from your communications with the tracker.
You know what already exists and is already supported by most clients and easily implemented into trackers? SSL/https. It prevents the ISP reading anything that you send to the tracker, or the tracker sends back to you, and requires no recoding of either end to add support for the RC4 encryption. It also requires not a single change to the announce string.
As for this new extension being the saviour where comcast is concerned, I wouldn’t count on it. All it does is prevent them from reading your info_hash on announce. It doesn’t stop them reading your announced port or from dropping connections initiating transfers on that port. SSL on the other hand encrypts even the port number.
Also, tables to contain all the possible results of sha1 hashing a sha1 hash may seem infeasable now, but they will reach a point where they aren’t. Once that point comes, using the sha1 as the key seems like a really bad idea.
Even without having to wait for tables to become possible, and ISP can easily monitor your plain http traffic for downloads of torrent files. They can then grab the hash from there in the same way your client does. Given a user who downloads 20 torrent files before starting the client, it’s a massively simple operation to sha1 20 info hashes. If only 5 of those torrents contain the obfuscate-announce-list then it cuts 3/4 of the work.
But, guess what. SSL will also protect you from this form of attack as well.
The solution is already there, and it protects against a hell of a lot more than this proposal. We don’t need this half assed crap.
I’m glad that there are those who fight for their right instead of becoming apathetic thank you
@26 - think “shared secret”
Shared secret does noting over ssl. The only possible weakness is that the ISP could request the peer-list from the tracker and then use that to kill connections but thats very unlikely. Since they would need to scrape torrents and whatnot.
@28: What about shared secrets?
The info_hash is serving as a not very secret shared secret sure, but the word itself does not make this work.
The spec says that info_hash is changed to sha_ih in the announce, and that’s it.
So here’s what we have.
announce?info_hash=xxxx&port=123
becomes
announce?sha_ih=yyyy&port=123
Your ISP sees that announce with that port, they know that the port is handling bittorrent data no matter whether you encrypt your client to client messages or not.
All they have to do now is cut or limit the connections on that port.
Yes, you could rig up some proxy software or a hacked client to send a fake port number, but that would make you unconnectable. When everyone is unconnectable, bittorrent is broken.
Anyway, with SSL, your ISP will see a connection to the webserver and that’s it. Your client sends nothing until the SSL connection is set up, not even the GET request.
So the ISP sees a connection open, then nothing but gibberish. They could not tell you whether you are reading the forums or announcing 100 torrents. They cannot pull the port number from any of it, and cannot be sure that closing incoming encrypted connections on all ports will hit bittorrent only.
BTW, from the specs page:
The returned peer list is encrypted using RC4-drop768 encryption using the infohash as a shared secret
The info_hash itself is not protected in any way. Like I said, it can be gathered by simply looking at the torrent files you download.
@29 - RC4 is SSL (been there, done that, old news)… this new method is an improvement on the concept, based on a ’shared secret’.
(yea, I read the whitepaper)
I effin’ hate the fake spymac links. To those who haven’t figured it out, people are in a stupid mindless contest on spymac and they are luring you to the site with crap so they can get stupid hits and win a stupid contest. GHEY.
SSL is more than just RC4.
RC4 is only one of the supported ciphers. SSL can support others such as 3DES, AES, RC2 etc.
RC4 is also not just SSL, but is also found in WEP and others.
HTTPS also uses shared secrets to cut down on computation. The difference is that the secret is only shared by the server and one client, and it is sent encrypted using a public/private key pair making it a genuine secret.
The new extension on the other hand simply sha1 hashes a publicly known string that is possibly also known to the intruder (your ISP). Once the intruder knows your shared key, and the algorithm you are using (fixed in this extension, variable in SSL), it’s all over.
As already mentioned, SSL/HTTPS encrypts everything sent to the tracker, from query strings to cookies. It does a much better job of blocking known and future attack vectors. Maybe in future comcast will start automatically deleting accounts found on certain trackers, unlikely to happen yes, but protected against with HTTPS.
So I wouldn’t call this an improvement on SSL/HTTPS, although simply stating “use SSL” wouldn’t have gotten BT.inc another mention in the blogs.
@ #12 Pray tell….
Spymac must fucking die.
Flawless victoly !
It’s nice to see people taking action! The government and the internet providers aren’t gonna do anything, but we can!
Awesome work Comcast! Now you see how things go when you mess with things.
Its very wierd that mostly EU ISPs upgrade and improve networks and are against monitoring and interfering, while US ISPs seems to be the opposite, maybe its the US profit machine model or their just to swamped with lobbyists from the music industry? hmm its wierd anyway..
Im downloading right now on Comcast
Just give comcast the boot …tha’ll learnem
if i’m not mistaken the advantage this has over SSL is that it might actually be feasible for trackers to implement. Do you think there’s no reason SSL hasn’t been done? The reason is that most trackers are already pushed to their limits without trying to encrypt every connection. This scheme would be much much easier on the trackers.
Perhaps it will be possible for Sandvine to defeat this by caching torrent infohashes or some other method but it’s worth a shot and at the very least it should take them months to design and deploy the new software. Also keep in mind that ISPs, unlike the RIAA, don’t really care about piracy. If it becomes expensive enough for them to block p2p traffic they’ll stop trying and probably just impose monthly bandwidth caps or something.
rtfa 41.
“Even without having to wait for tables to become possible, and ISP can easily monitor your plain http traffic for downloads of torrent files. They can then grab the hash from there in the same way your client does.”
Even if you download the tiny torrent file from within the Tor network?
The only way to permanently stop this kind of crap from the ISP’s is to make the protocol cost them even more bandwidth when they try to interrupt them (for example, maybe something like resending the connection request every 500ms or so). By doing so, they will screw their own network by attempting to hinder the protocol.
I dunno what the legal implications of this would be, at least in the US, since it seems even idiots can sue and win, and they might be able to make a case that this type of protocol would be an attack on them. However, even that can be resolved by designing the protocol correctly.
Do you think there’s no reason SSL hasn’t been done?
There are a few private trackers that do indeed allow users to utilize SSL.
Are you sure the quote was:
“Consumers should be very weary of this claim.”
???
Although plausible, it’s more likely that he said:
“Consumers should be very _wary_ of this claim.”
The ambiguity of this phrase combined with the difficulty of spelling makes it useful to add an (sic) annotation when quoting it in print.
File sharing increases the load on the networks so users who share files should pay for the bandwidth they use. This is the only way ISPs can finance network capacity increase.
3 references to this post
Pages: « 1 [2] 3 4 5 » Show All
Add your response