The difference is that the BitTorrent protocol has a mechanism to verify that you received what you intended to receive, whereas HTTP does not.
HTTP has no mechanism...
- to verify that you are actually connected to the server that you intend to connect to,
- or actually downloading the file that you expected to receive.
If any of the HTTP mirrors have security vulnerabilities, or are not under the provider's control, an attacker could simply replace the file, and it would go undetected on the side of the recipient.
Furthermore, if the circumstances allow, HTTP is susceptible to a Man-in-the-Middle attack. Meaning, from your end it looks like you are connected to example.com, but actually you are connected to a third party which is intercepting the traffic, manipulating the network traffic, and only making it look like you are connected to example.com. You then request to download a certain file, but the attacker sends you a malicious file instead. (On a side note, correctly configured HTTPS, with
S, prevents this.)
A file that is transmitted via BitTorrent, on the other hand is first divided into chunks. Each of those chunks is then hashed using SHA-1, i.e. a checksum is generated, by the torrent creator. The hashes are given to each BitTorrent client prior to the download - usually contained in a
.torrent file. As the file chunks are then downloaded by the client, they are first hashed by the client itself, and compared with the previously received hash. Only if the hash matches, meaning that the chunk contains exactly the same bytes as the expected chunk, is it accepted. It is a practical impossibility to manufacture altered chunks that have malicious content, but retain their original hashsum.
Since these hashes are shared with you prior to the download, presumably from a trusted source, it is harder (to impossible) to manipulate the expected files in transit when received via BitTorrent compared to a HTTP download. The provider can distribute the torrent, which is a small file, from a single secured server via HTTPS under his own control, and the hashing mechanism will provide a validation for the actual download.
If on the other hand, your hashes or torrent file are tampered with prior to the download, or due to a MitM attack if downloading the torrent itself via HTTP, then the checksum validation offers no security.
Lastly, there is a way how the checksum mechanism can be circumvented by an attacker if he has access to the file prior to the hashsum generation, i.e. prior to the original creation of the torrent. It is then possible for an attacker to modify the file in such a way that some of the file's content can later be substitute with pre-engineered code during transmission of the torrent without being detected by the SHA-1 hashsum check, despite being different to the file that was originally checksummed.