The very, very short version of this post: we’re improving our security to make users even more safe than they were before. Everything is perfectly up to standard now; this is just a proactive move to make things even more secure.
The more detailed version: In the near future, you might notice that µTorrent and BitTorrent are now checking for software updates over an encrypted HTTPS connection, instead of over unencrypted HTTP. We made this change as part of a proactive security review of our auto-update process. We don’t believe there are any threats to our software. However, given recent events, we decided to examine our infrastructure. We didn’t find any problems, but we did find one place where we could make things even more secure – and made it happen.
A few recent events triggered our investigation – two news stories about hackers using other software’s auto-update mechanisms. The first story is an FBI report of travelers’ laptops being hacked via rogue devices on hotel networks; the second was the Flame malware. While our products weren’t affected by either of these events, they highlight a trend of attackers hijacking auto-update processes. With that in mind, we decided to reevaluate our process and ensure we were doing everything possible to keep our users safe.
The end result of that evaluation is: everything’s fine. Our current update system is very safe for the foreseeable future. The updater checks multiple cryptographic values to ensure that the program update that it downloaded matches what it expected, and also makes sure that BitTorrent, Inc signed the binary. All of these checks are done in multiple, independent ways, which makes it nearly impossible for anyone to hijack the process.
With everything considered, we identified one opportunity to make our processes even more secure. By switching to HTTPS from HTTP, we made it more difficult to interfere with users’ updates. That being said, even standard SSL isn’t entirely secure because it trusts too many people. It’s possible for attackers to compromise a “Certificate Authority” and make new, “valid” certificates.
An example of this was the attack against Comodo, in which a hacker exploited a CA to create “valid” certificates for google.com. The solution to that problem is a technique called “Certificate Pinning,” best described by Adam Langley in his blog post “Public key pinning.” We’re using a version of this to ensure that the HTTPS certificates only come from trusted sources.
Overall, the auto-update process is even more secure than it had been, and should continue to be so for a long time to come.
So do you think HTTPS connection is very safely? How about a malware site using HTTPS connection, is it possible?
We considered that threat: it’s why we use certificate pinning. Because we pin our certs, it’s basically impossible for anyone to run an HTTPS server masquerading as us. That eliminates the chance of having an autoupdate session hijacked to download malware. In addition to that, we also have several checks on the actual binary being downloaded, so any attacker would have to break several other pieces of cryptographic authentication before the client would run what was downloaded.