4 ms·

The sad state of alarmist posts for karma.

goodplay 10y ago
> alarmist How so? The author is voicing criticism that a lot of people (including myself) have with regards to the current state of software distribution security. Furthermore, his survey of the top distributions is interesting for people who take their security seriously.
- zdkl 10y ago
  It's misconstruing the problem as a primarily mitm threat. Considering the different methods of tampering with your download, I'd be more worried about server side compromises rather than otw
  - goodplay 10y ago
    That doesn't mean we shouldn't mitigate MITM. Using either gpg or tls without the other makes the security of the system weaker than it needs to be. Gpg key authenticity can't be practically verified by end users. I remain unconvinced.
nickpsecurity 10y ago
The table in the link isn't alarmist: it's alarming. Secure distribution... at least an effort... was a requirement in INFOSEC since the Orange Book in 90's. FOSS proponents pushed Linux distro's, and still do, for the foundation of security-oriented projects. This is 2016. They still don't have trustworthy distribution under control except Fedora apparently. It's worth noting. Anyone wanting to build on this should apply same methodology to major BSD's to see how they compare.
- 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.
- deleted 10y ago
  [deleted]
- clarry 10y ago
  I would not apply the same methodology. I would prefer that anyone building on this apply sane methodology. Otherwise people will get the wrong idea.
  - nickpsecurity 10y ago
    Do you have any specific recommendations to improve their methodology?
- danieldk 10y ago
  FreeBSD: Signed checksums are linked from the same table as the ISOs on the download page: https://www.freebsd.org/where.html https://www.freebsd.org/where.html https://www.freebsd.org/releases/10.3R/signatures.html https://www.freebsd.org/releases/10.3R/signatures.html Downloads are via FTP by default, but I agree with those that HTTPS cannot be trusted either. Signatures plus building up key trust is the way to go. Hopefully Keybase.io will make it easier in the future to establish trust in such keys.
- RaleyField 10y ago
  > except Fedora apparently I don't know fedora, but when I tried to switch I found the following blocking issue. Fedora has packages missing that you can get in Ubuntu (irc it was vlc for me). There is RPM Fusion but it doesn't have reliable method of verifying repo keys - they send instructions only over http and have only selfsigs on keys. As this has been going on for years and without bothering anyone I can't trust them even if they fix it sometime in the future.

> alarmist How so? The author is voicing criticism that a lot of people (including myself) have with regards to the current state of software distribution security. Furthermore, his survey of the top distributions is interesting for people who take their security seriously.

zdkl 10y ago
It's misconstruing the problem as a primarily mitm threat. Considering the different methods of tampering with your download, I'd be more worried about server side compromises rather than otw
- goodplay 10y ago
  That doesn't mean we shouldn't mitigate MITM. Using either gpg or tls without the other makes the security of the system weaker than it needs to be. Gpg key authenticity can't be practically verified by end users. I remain unconvinced.

nickpsecurity 10y ago

The table in the link isn't alarmist: it's alarming. Secure distribution... at least an effort... was a requirement in INFOSEC since the Orange Book in 90's. FOSS proponents pushed Linux distro's, and still do, for the foundation of security-oriented projects. This is 2016. They still don't have trustworthy distribution under control except Fedora apparently. It's worth noting. Anyone wanting to build on this should apply same methodology to major BSD's to see how they compare.

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.
deleted 10y ago
[deleted]
clarry 10y ago
I would not apply the same methodology. I would prefer that anyone building on this apply sane methodology. Otherwise people will get the wrong idea.
- nickpsecurity 10y ago
  Do you have any specific recommendations to improve their methodology?
danieldk 10y ago
FreeBSD: Signed checksums are linked from the same table as the ISOs on the download page: https://www.freebsd.org/where.html https://www.freebsd.org/where.html https://www.freebsd.org/releases/10.3R/signatures.html https://www.freebsd.org/releases/10.3R/signatures.html Downloads are via FTP by default, but I agree with those that HTTPS cannot be trusted either. Signatures plus building up key trust is the way to go. Hopefully Keybase.io will make it easier in the future to establish trust in such keys.
RaleyField 10y ago
> except Fedora apparently I don't know fedora, but when I tried to switch I found the following blocking issue. Fedora has packages missing that you can get in Ubuntu (irc it was vlc for me). There is RPM Fusion but it doesn't have reliable method of verifying repo keys - they send instructions only over http and have only selfsigs on keys. As this has been going on for years and without bothering anyone I can't trust them even if they fix it sometime in the future.