Is your ISP crippling Soulseek transfers? You can help us test Soulseek protocol obfuscation.

There have been way more reports than usual in the last few months about Soulseek transfers being unusually slow for different users, from different places on earth at different times of day. We suspect many Internet service providers have taken to slowing down peer Soulseek connections, and have set out to try and do something about it. Since it's not clear what each ISP is doing in each case, we had to resort to a lot of guesswork. Our starting theory is that in many of these cases, protocol analysis is done by the ISP to identify peer Soulseek connections. This isn't very hard to do as the P2P handshake between any two Soulseek clients looks more or less the same in each case. It's our understanding that many ISPs perform traffic-shaping exactly by way of doing basic pattern matching on new TCP connections. What I've been working on over the last two days is a way of obfuscating Soulseek peer-to-peer traffic in order to completely randomize its appearance. If our theory is at all correct, this should help prevent at least some of these ISPs from recognizing these connections as Soulseek connections. If you're fairly certain your ISP is culpable of such tampering, you can use the the client linked to below to test this newly implemented protocol obfuscation and see if it changes your situation any. You will need to test this with someone who is also using the new client. The client will simply revert to regular, non-obfuscated peer-to-peer communication if the other end doesn't support it. Also bear in mind that lot of changes have been made to the client infrastructure in order to implement this new mechanism, so while I've brought it to a state where it doesn't seem to crash on my end, it might crash for you in places that it hasn't before. If that happens, you can always submit a crash report in the usual fashion. In any case, let us know how your tests go!

Thanks, Nir

SoulseekQt protocol obfuscation 1.zip (Windows only right now)

edit: The link above was removed as the latest version of SoulseekQt available on the download page at the time of this writing includes this (of yet untested) protocol obfuscation functionality.

Tags: 

Comments

Although I don't currently have any issues with my ISP and traffic-shaping, I have in the past and really appreciate your efforts to add obfuscation into the soulseek protocol. I came across an interesting article on how protocols are classified even when obfuscated and even encrypted.

https://www.iis.se/docs/hjelmvik_breaking.pdf

Maybe this is useful to you?

Thanks again.

Oh yes! I saw this paper mentioned in an old Ars Technica article but haven't looked at it yet. Some of the mechanisms discussed in the article would be a lot harder to circumvent without major, backward-incompatible changes to the Soulseek protocol. Some I'm just holding off on until I have more data from users whose service providers tamper with their Soulseek connections, things like more variable packet length for example (the packet length in each case is already somewhat variable, but it can be made much moreso.) What I have right now is absolute binary non-repetition of any otherwise repeated data in Soulseek peer-to-peer packets, across packets and within the same packet, and I'm rather excited to find out if it would make any difference at all. I'll definitely refer to this paper if I need to come up with any new methods of obfuscation. Thanks!

I think (guesswork) that I'm currently being throttled - so this is my last / only hope of getting soulseek back again in a usable condition.

I've just installed the new client (lots of nice new interface ideas!) , but I have no indication of whether anyone else in the search results is using a client that supports obfuscation -

Anybody currently using this client who would like to volunteer a username and some shared files for me to test against?

All of my download attempts so far have still been hopelessly slow, with lots of PM_UPLOAD_FAILED and 'aborted' messages... but I guess the chances are that most people out there won't be using this build of Qt. (my port is definitely open and forwarded)

I can't connect to Soulseek at all, through any client. The ISP is windstream.net. I hate it but I'm stuck with it. I just go to other people's houses in the meantime. Anyway, if you were not aware of this one, I thought you should be.

I wonder if they're blocking the Soulseek server port. This is something I've been dealing with lately, and even went to the length of exposing a slew of additional ports on the server to be able to test for this. This version of the client: SoulseekQt-random-port-test.exe will attempt to connect to one of these extra ports at random each time you start the client. If your ISP is blocking the Soulseek server port, or certain ranges of ports, you should be able to connect using this version at least after a few restarts. If it does connect, the last port mentioned in the Diagnostics->Logs->server tab should be the one that worked. Of course, it's possible they're just blocking our server IP address, in which case there really isn't anything we can do. One more thing we can try is forming a connection over port 80, which should always be open to allow for web traffic. I need to move some things on the server to make that happen, but once I do we can try that as well.