qBittorrent quietly fixes 14-year-old security hole

qBittorrent, a popular peer-to-peer file sharing app that's been around 2006, has been accepting just about any SSL certificate in domains and addresses put into the app's DownloadManager component for over 14 years, and has now patched that vulnerability. The commit that created the potential security hole was introduced back in April of 2010, and was quite simple; all it did was change the default state of SSL verification from enabled to disabled. This did away with pesky security errors, something that could potentially annoy users and keep them from being able to download content from unverified sources. As of October 28, 2024, and version 5.0.1, the default state is set to enabled once again. It's worth noting that qBittorrent offered no explanation for the change, and did not notify users in any special way, aside from the usual patch notes that accompany new versions. 

SSL certificates are security tokens that do two things; they verify that a source of web traffic is coming from the website it claims to come from, and allows the content coming across that connection to be encrypted. Given that BitTorrent, as a protocol, is based around peer-to-peer file transfer, it stands to reason that one may be receiving perfectly safe files from somebody's home server, or even their PC, which means that they may not be properly equipped to author an SSL certificate. Leaving this check disabled would allow users to communicate with and download from such sources without issue. 

The flip side of the issue is that the lack of an SSL certificate, or acceptance of an illegitimate one, opens up the possibility for almost any source of web traffic from any server to pose as the one the user is trying to reach. This, in turn, would allow bad actors to hijack the traffic, possibly stealing information from host systems or user systems, and possibly injecting almost any code they want. In many ways, this sort of man-in-the-middle attack sidesteps many conventional security measures, such as firewalls, that would otherwise protect users from bad actors. 

The setting that governs whether the app will accept a connection without performing an SSL certificate verification is still accessible to users, so those who are willing to take the risk can simply disable it. The average plug-and-play user is not typically expected to dive into the app settings before using it, or to know how SSL certificates work and what risks are created by leaving the setting disabled, making this move a net positive for app security.