While I empathize with last Guest's reply, we need to forego emotions to get Tixati whitelisted.
@alienware thanks for posting the client list. This will actually be instrumental because it shows how uneducated the pickings are.
Checking the padlock next to the URL, it seems the site's HTTPS certificate is from cloudflare.
Tracker URL seems to be on HTTPS as well
It is safe to guess the tracker is also behind Cloudflare. Good job.
The argument goes that Cloudflare is essentially a MITM. It must be. It must be in the middle and read all your traffic unencrypted to function as the proxy they are. There're two problems with it:
1) You can be certain they're collaborating with three-letter agencies at some level and have been for a long time now. Shocker: all major US ISPs do too. The smaller ones abide by the law and have equipment in place in case the receive a warrant/request.
2) There can be awful configuration mistakes. For example your traffic to CF servers is encrypted, but CF to their website server IS NOT or it is not verified properly. Described in detail here: https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security-absolutism/
No, #1 is not a conspiracy theory, but it is a real conspiracy. PRISM was a 'dumb conspiracy theory' right until Snowden revelations. As someone who's absolutely serious about security and privacy, I'd not use Cloudflare for anything but static CDN (deliver static files) on a website's subdomain.
Registration date seems to be logged, says joined "x ago" on forum posts.
on the site under the "my active connections tab" it shows my client and IP used for each torrent.
I do not know if these are stored "long term"
Well first of all this goes right against the idea of restricting all but few 'trusted clients'. If they care about security and privacy of users, they should have made the forum software not save last visits (certainly time and IP). The classic too: registration date and IP, separately. Ideally you'd want to allow users to erase the e-mail after registration too. You know, think about what's gonna happen when 'someone' gets access to the server and their hands on the database. The hunt for users will begin.
Sure all of this sounds hypothetical right until it happens. You can only act ahead of time, so far I see no positive surprises.
The fun part: lets examine their allowed clients list!
It took me some time to research, I've long wanted to do that but didn't quite have the time or motivation.
Not applicable, 2008: BitTorrent 6.0 / uTorrent 1.6/1.7 - Peers Window Remote Code Execution
. Just for the sake of completeness.
Transmission ver ?-2.92
Remote Code Execution with a DNS rebinding JS attack against the web interface.
TF article: https://torrentfreak.com/bittorrent-client-transmission-suffers-remote-takeover-vulnerability-180116
Original Project Zero bug report: https://bugs.chromium.org/p/project-zero/issues/detail?id=1447
(funny how he notes that the devs didn't take it seriously and dragged on for 1.5 months)
Pull request: https://github.com/transmission/transmission/pull/468
qBittorrent EVERY VERSION <=4.1.6
, according to report:
Remote Code Execution via a malicious RSS Feed if one used automation (run commands on transfer).
uTorrent 3.5 (build <= 44351), uTorrent Web (ver?), 2018
Remote Code Execution.
TorrentFreak article: https://torrentfreak.com/bittorrent-client-utorrent-suffers-security-vulnerability-180220/
Threatpost article: https://threatpost.com/utorrent-users-warned-of-remote-code-execution-vulnerability/130030/
Comment 10: https://bugs.chromium.org/p/project-zero/issues/detail?id=1524#c10
Comment 13 (c13): https://bugs.chromium.org/p/project-zero/issues/detail?id=1524#c13
Reddit claims of old versions: https://www.reddit.com/r/torrents/comments/7yyyzy/utorrent_various_jsonrpc_issues_resulting_in/
Apparently BiTorrent borked their first attempt to fix this exploit properly as explained in comment 10. I'm not sure what version has the final fix (maybe 44352, maybe not). Yet funnier is the 'workaround' misleadingly thought to fix the problem (c13):
Some websites tried to persuade people that setting Preferences → Advanced → net.discoverable = false resolves the problem. But it isn't true. This setting just disables port 10000. But you can execute the same actions using port which uTorrent uses for all incoming connections. For example, I use port 45705 for incoming connections, and a simple GET request to
http://127.0.0.1:45705/fileserve/?callback=error crashes the program.
There's no definite consensus whether uTorrent 2.x is vulnerable too. Comments 30, 24 say, as far as I can tell, these are not vulnerable. Normal users from reddit claim otherwise.
A gem from the vulnerability description:
While not a particularly strong secret (8 bytes of std::random_device), it at least would make remote attacks non-trivial. Unfortunately however, the authentication secret is stored inside the webroot (wtf!?!?!?!), so you can just fetch the secret and gain complete control of the service.
Basically the password was accessible in plaintext to anyone via HTTP. This is a client family to be trusted for sure!
uTorrent 3.5.5 build <= 45505
(fix in 45574)
Remote Denial of Service (crashes client). Any remote peer can crash the client.
Original write up: https://blog.whtaguy.com/2020/09/utorrent-cve-2020-8437-vulnerability.html
Proof of Concept video by the author: https://www.youtube.com/watch?v=wIXZvz_Y4Ag
I'm done proving my point here that the allowed client list is totally arbitrary. Not just that, but in case of the latter they effectively CANNOT filter out the 'bad vulnerable' client version because they all carry 3.5.5, simply differing in build numbers that afaik are not communicated in any way.
Further isn't BitTorrent client essentially the same codebase as uTorrent (and has been for a few years)? I cannot find the bencode fix in their changelogs: BitTorrent 7.10.5 For Windows (build 45665), June 30th, 2020 and 7.10.5 (build 45496), January 17, 2020.
I did not investigate BitTorrent, uTorrent Mac, rtorrent or Deluge in particular. I just wanted to show that even the most 'trusted' clients have had their loopholes and STILL are on the 'safe' list. And with uTorrent 3.5.5 DoS the whitelist is useless.
I hope this has been enough research into the past to conclude that the admins didn't do their due diligence (my personal opinion and I object such restrictive whitelists without a reason). You can copy my response verbatim to them (maybe without the parentheses part :P)
This should've been enough convincing done to allow Tixati <3 There be(en) worse things.
Finally: Open source or not, both Transmission and qBittorrent just had been waiting for someone for years to find the vulnerabilities.
In fact they can't be sure the outdated uTorrent (3.5), Transmission and qBittorrent users (still allowed) hadn't been already breached. Although not even whitelists can prevent users from installing/getting malware elsewhere. What needs to be done is general education for computer literacy and threat mitigation (as well as detecting malware and repairing your PC). I have reasons to believe that Tixati users are on average more literate than those jesters running uTorrent and downloading "funnyclip.mp4.exe" off of TPB.