4 ms·

I don't think the table really covers the everything quite well enough. In reality it doesn't really matter if the download is over HTTP or HTTPS as long as you

by Etzos 10y ago

I don't think the table really covers the everything quite well enough. In reality it doesn't really matter if the download is over HTTP or HTTPS as long as you can safely verify that the file you have is indeed the correct file. For example, Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now. Even if one has provided instructions for doing so it's still going to require that the end user cares about checking the validity of the files.

nickpsecurity 10y ago
"Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now." One of the points in that and article jacquesm linked is that checksum verification still requires trusting the transport. Otherwise, you get fake binary plus fake checksum that then look safe but were for malicious app. There's just an extra thing to change for attacker. No work at all given what was already put in to get to that point. So, trustworthy transport of binary and/or checksum is necessary. The checksum should still be there even if binary is sent safely, though, to verify no corruption of binary happened due to transmission or storage faults.
- Etzos 10y ago
  The checksums and PGP signature are on the HTTPS page which links to all the downloads. You have to trust that page from the start no matter what (or establish the PGP signature trust from other ways, which is quite possible just far more involved) because that's the source of all downloads and anything there could be faked from mirror links to checksums to PGP signature (assuming no trust chain is actually established by the user). My initial point is that no matter the solutions offered, the user has to care about checking. Forcing HTTPS transport for the download isn't really going to make it any more secure because it's still possible the file is illegitimate and you should be testing the signatures. tl;dr: Arch's downloads are over HTTP, the checksums and signature are over HTTPS and on the official download page.

by Etzos 10y ago

nickpsecurity 10y ago

"Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now." One of the points in that and article jacquesm linked is that checksum verification still requires trusting the transport. Otherwise, you get fake binary plus fake checksum that then look safe but were for malicious app. There's just an extra thing to change for attacker. No work at all given what was already put in to get to that point. So, trustworthy transport of binary and/or checksum is necessary. The checksum should still be there even if binary is sent safely, though, to verify no corruption of binary happened due to transmission or storage faults.

Etzos 10y ago
The checksums and PGP signature are on the HTTPS page which links to all the downloads. You have to trust that page from the start no matter what (or establish the PGP signature trust from other ways, which is quite possible just far more involved) because that's the source of all downloads and anything there could be faked from mirror links to checksums to PGP signature (assuming no trust chain is actually established by the user). My initial point is that no matter the solutions offered, the user has to care about checking. Forcing HTTPS transport for the download isn't really going to make it any more secure because it's still possible the file is illegitimate and you should be testing the signatures. tl;dr: Arch's downloads are over HTTP, the checksums and signature are over HTTPS and on the official download page.