I'm downloading an .iso file that is offered through the main website, which recommends users to use BitTorrent. In addition, they offer the download via HTTP using different mirror sites that belong to different countries, and they claim that the downloads from an HTTP mirror are more prone to be intercepted to serve malicious downloads. I'm curious as to why these kinds of downloads would be more prone than the original downloads.

If I had to guess, it would be because of the differences in security implementations between servers around the world that hold the files. Am I completely off?

  • 10
    Is it possible that they're referring to the integrity provided by the BitTorrent infohash?
    – forest
    Commented Oct 28, 2019 at 1:03
  • The illusion of security can be worse than using something that is known to be insecure since if you mistakenly believe it's safe you won't be as inclined to take extra precautions.
    – aslum
    Commented Oct 28, 2019 at 16:07
  • 7
    Is HTTPS offered either for the .torrent file or for the .iso file itself? Or only HTTP?
    – usul
    Commented Oct 28, 2019 at 16:51
  • 4
    Do you learn what exactly to download via bittorrent from a web page served by http? Commented Oct 28, 2019 at 18:59
  • Are you sure that it's HTTP and not HTTPS? Most of the internet has gone HTTPS nowadays, so a plain HTTP connection is relatively rare. Commented Oct 29, 2019 at 17:18

7 Answers 7


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.

  • 6
    You may want to specify that the checksum is SHA-1, which is not ideal in certain scenarios (attacker influences both original and malicious torrents), but better than a "traditional" non-secure one like CRC.
    – forest
    Commented Oct 28, 2019 at 1:28
  • 11
    @forest I don't think that ends the debate quickly. That SHA-1 collision was produced on a file specifically designed for this, and took 6,500 years of CPU computation time and 110 years of GPU. Would it work on any 2mb chunk of data without altering the chunk's length, while introducing a viable malicious program? Otherwise I think the stance "practical impossibility" is still accurate
    – ig-dev
    Commented Oct 28, 2019 at 3:01
  • 7
    @ig-dev It is trivial to create arbitrarily many pairs of colliding inputs for SHA-1 using the starter kit that Google published: roughly, if two messages x and y collide under SHA-1, then appending the same suffix z to both x and y also collides under SHA-1. The burden is on you to show that the system you're discussing defends against these attacks, not on forest to show how to break your system—it is unlikely that forest cares enough to go to the trouble that a dedicated adversary would go to. Formats can be very flexible; take a look at the polyglot PoC||GTFO issues for examples. Commented Oct 28, 2019 at 3:34
  • 8
    Any collision between two pairs is not enough - you have to find a collision with the existing chunk, and that collision has to contain your malicious code. A chosen prefix collision attack has been found in 2019, and I have appended this to the answer (prior to your comment). The reader can decide if this is trivial or not
    – ig-dev
    Commented Oct 28, 2019 at 3:41
  • 15
    @ig-dev A collision, by definition, is between any two pairs. Finding a matching digest with an existing chunk is called a second preimage attack, and SHA-1 is not known to be vulnerable to any preimage attack. What this means is that an attacker can't modify an existing, benign torrent, but they could create two torrents (or convince a legitimate torrent creator to use a file they have influenced), one of which is safe, the other of which they specifically tailor to you. No one would report the torrent is dangerous because they get the safe version, but you don't, despite a matching hash.
    – forest
    Commented Oct 28, 2019 at 5:04

Suppose the author of a document (say, a .iso file) has a way to share a .torrent file with you out-of-band that an adversary has no power to subvert—in other words, when the author creates the document and then makes a .torrent file for it, you are guaranteed (somehow) that you can get the true .torrent file and not a forgery. Maybe you got the .torrent via HTTPS, but you would get the .iso from a mirror over HTTP. This is crucial! If you download the .torrent file itself over HTTP, everything below about BitTorrent is moot.

If the adversary is trying to trick you into getting a malicious document, what's the difference between downloading the document via HTTP vs. downloading the document via BitTorrent using the .torrent file?

Here are some powers the adversary might have:

  1. The power to intercept traffic on your internet connection and replace it in transit.

    • With HTTP, the power to intercept your internet connection is enough for the adversary to fool you into accepting a malicious forgery. This is because HTTP does nothing whatsoever to verify authenticity of data received on the internet: it is like a particularly naive clerk who lets the guys in high-visibility vests into the secret control room because they said they had a job to do.

    • With BitTorrent, the power to intercept your internet connection is not enough for the adversary to fool you into accepting a malicious forgery. This is because the .torrent file has a SHA-1 hash of each chunk of the real document, so without control over the real document, an adversary has no hope of finding a malicious replacement that matches the SHA-1 hash in the .torrent file. (This is what cryptographers mean when they say SHA-1 is ‘preimage-resistant’, or, more specifically here, ‘second-preimage-resistant’.)

  2. The power to run a mirror or BitTorrent node.

    Mirrors may be run by many different parties and may not be scrutinized as closely as the main site—and anyone can run a BitTorrent node. This doesn't require any network interception.

    • With HTTP, the power to run a mirror is enough for the adversary to fool you into accepting a malicious forgery. They just serve you the forgery when you ask for it, and you have no way a priori to distinguish the forgery from the real document.

    • With BitTorrent, the power to serve data from a BitTorrent node is not enough for the adversary to fool you into accepting a malicious forgery. Again, whatever forgery the adversary feeds you will not—with this power alone—be able to find a forgery that matches the SHA-1 hash in your .torrent file.

  3. The power to influence what the author puts into the real document—as long as it passes review.

    This may sound like a weird power to worry about, but consider how modern software development has evolved from the Stack Overflow style of copypasta to a cavalier reliance on npm packages like left-pad. The maintainer of a package like event-stream may tire of the task and sell ownership of the package name to an unsavory character who now has the power to influence what goes into newer versions of deployed software packages like an OS image you might distribute by BitTorrent. (More on games one can play with this power: [1], [2].)

    Obviously, if the adversary can slip malicious code into the real document without anyone noticing, you're hosed. But if we limit the adversary just a little bit to have a benign influence on the real document—something that will pass review by the author—then you may still be hosed with BitTorrent!

    • With BitTorrent, the additional power to influence what goes into the document—even if it is subject to review so there's nothing malicious in the real document!—may be enough for the adversary to fool you into accepting a malicious forgery.

      How? An adversary playing the long game could simultaneously make two versions of a chunk of the document, a benign version and a malicious version which collide under SHA-1. (This is because SHA-1 is not what cryptographers call ‘collision-resistant’. They may have no power over what the SHA-1 hash will be—only that the benign version and the malicious version have the same SHA-1 hash.)

      The adversary could then persuade the author to include the benign version (which passes review!) in the document—but then intercept the torrent on the internet as you're downloading it and replace the benign version by the malicious version. Your BitTorrent client will be none the wiser because the malicious version has precisely the SHA-1 hash specified in the .torrent file!

Some day, BitTorrent may transition to an alternative to SHA-1 that is collision-resistant—likely SHA-256. That would render the complexity of this story moot. My point in telling the more nuanced story is not that BitTorrent is as bad as HTTP—it's not: under the assumption that your .torrent file is good, BitTorrent defends against adversaries (1) and (2) while HTTP doesn't even do that—but rather there are still tricky issues with BitTorrent. This is because SHA-1 is bad news (and MD5 is even worse news), and analysis of protocols that were naively built on an assumption of collision resistance is very tricky if that assumption goes out the window like it did with SHA-1 a decade and a half ago when a collision attack on SHA-1 was first published in 2005. (More on dangers and timeline of SHA-1's demise.)

  • Didn't they get the torrent file over HTTP? If the theoretical attacker can MITM the download of the .iso file, they can do the same with the .torrent file.
    – Moby Disk
    Commented Oct 29, 2019 at 11:46
  • @Moby Nowhere in the question does it make a statement about the transmission method of the torrent itself. The provider of the torrent is raising concerns about HTTP in the first place, so it is reasonable to think that he is distributing the torrent via HTTPS from a server under his control.
    – ig-dev
    Commented Oct 29, 2019 at 12:37
  • 1
    @MobyDisk I don't know. The question didn't specify. That's why I devoted the entire first paragraph to emphasizing that it is crucially important that the .torrent file be genuine for the rest of the answer to be applicable. Commented Oct 29, 2019 at 14:28
  • Ubuntu took a vexingly long time to serve security sensitive stuff like gpg keys over https, so this is not a trivial consideration Commented Oct 31, 2019 at 2:23
  • I was responding to another comment here, your answer is well reasoned 🙂 Commented Oct 31, 2019 at 3:46

The main concern with HTTP mirrors is that the maintainer of the mirror can simply change the files at will. This is mitigated using BitTorrent because the tracker contains a hash of the file.

Equivalent security could be achieved by serving a hash of the files at the same location as the torrent file, as long as you verify that hash manually.

BitTorrent is not necessary for security, the author just likes it.


Your assumption that this claim is true is flawed. They are both susceptible to interception. One could claim that BitTorrent is less so since it's decentralized, but simply downloading the .torrent manifest is enough to reconstruct what requests you will make to other peers anyway.

At least .torrent files have a cryptographic hash calculated over them to protect against corruption. This doesn't really support the assertion in your question though, because if this .torrent is served over HTTP, then it's equally susceptible to being manipulated over the wire.

  • 1
    I kind of agree with both being susceptible to interception (with different likelihoods) , but the idea that ".torrent" being served via http makes it more vulnerable is like saying that e-mail is more vulnerable because you can get phishing http links in the message, I don't think it's much of an argument.
    – ChatterOne
    Commented Oct 28, 2019 at 11:59
  • 1
    Your whole argument builds upon the torrent being distributed via HTTP, but that's not in the question. Equally likely (or, in my opinion, more likely) the torrent is distributed from a secured server under the providers control via HTTPS, if he is raising this concern about HTTP in the first place.
    – ig-dev
    Commented Oct 29, 2019 at 2:56
  • If a .torrent can be distributed via HTTPS, why can't an .iso? Commented Oct 30, 2019 at 14:26
  • That's kind of my point, though. They're equally interceptable. The important part is how you serve it—e.g., over TLS—and not whether the bulk of the transfer happens over HTTP or bittorrent. Commented Nov 3, 2019 at 1:07

If I had to guess, it would be because of the differences in security implementations between servers around the world that hold the files.

You haven't given enough information to be sure, but you're probably right.

As discussed in other answers, .torrent files contain a cryptographic digest of the file data. This means that they are as trustworthy as the files they describe, no more or less. (The hash function is SHA-1, so collision attacks are possible, but a collision attack requires that the files themselves be maliciously generated or modified, and I would say that the files and the .torrent are both equally untrustworthy in that case.)

So I think it's wrong to say that downloading via a torrent is intrinsically safer than downloading directly.

The advantage of the .torrent file is just that it's much smaller. Web sites that provide Linux installation images and the like generally can't afford to serve disk images to everyone for free. When they do provide the option to download them directly, it's usually donated bandwidth on third-party servers that they don't control. In contrast, they can afford to provide .torrent files to everyone from their own server, which they may have better reason to trust.

If you download an image from a random third-party server (even if it's not an official mirror), and compute a cryptographic digest (ideally SHA-256 or better) of the image, and it matches the published digest on the official server, that's just as good from a security perspective as using a .torrent file downloaded from the same official server over the same protocol. If that protocol is really HTTP (as opposed to HTTPS), then both options are pretty insecure, but neither one is significantly worse than the other.


They want you to use bittorrent, because it uses bandwidth supplied by other downloaders (which is free for them) as opposed to bandwidth of their server (which they have to pay for).

That's rather common, e.g. gaming services like Battle.net used to "steal" bandwidth by making their downloaders (unconscious) uploaders. Debian explicitly mentions reduced bandwidth usage on their servers as reason to use bittorrent.

So, I suppose the talk about security is nonsense and only meant as distraction.

  • Yes, I’ve never seen them mentioning security benefits. Usually they say that BitTorrent is faster and/or reduces load on their servers. This Quora answer states that Steam doesn’t do peer-to-peer downloads: quora.com/How-do-I-do-peer-to-peer-with-Steam
    – Michael
    Commented Oct 29, 2019 at 16:53
  • @Michael you're right, actually they seem to abandon this, might be an interesting question as to why that
    – Haukinger
    Commented Oct 30, 2019 at 10:00

There's no security difference.

Yes, BitTorrent has a reasonably secure mechanism to ensure you get what you're supposed to get. However, you're still downloading that torrent file via HTTP--if you're going to be MITMed they can just replace the torrent file with one that points to their malicious content.

However, there is a substantial non-security advantage to BitTorrent: it protects against corruption and is very good about handling failures.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .