6 ms·

I'm usually the first to step up to the plate and insist on HTTPS, but it's not actually necesary here. The packages are PGP signed, and the public keys are est

I'm usually the first to step up to the plate and insist on HTTPS, but it's not actually necesary here. The packages are PGP signed, and the public keys are established securely at install. This is actually more secure than SSL imo because it uses web-of-trust for key exchange rather than easily compromised certificate authorities.

justicz 8y ago
In this case `apk` does a ton of processing on the package before checking that the hash matches the signed manifest, and the maintainers don't want to/can't change that behavior at this time. As a result, https would be a real security improvement here, at least for now.
iancarroll 8y ago
I don't like certificate authorities either but "easily compromised", especially in this context, is just disingenuous. HTTPS would be a meaningful security improvement to this system.
- Sir_Cmpwn 8y ago
  It's not. Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. PGP keys are much more secure. HTTPS would not be a meaningful security improvement, not accounting for justicz's comment. At best, it would be the same amount of security, but more annoying to maintain.
  - JoshTriplett 8y ago
    > Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. They can't do that silently anymore, though, not without getting caught. Certificate Transparency addresses that.
  - tialaramex 8y ago
    > It's not. Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. PGP keys are much more secure. Citation very much needed for this claim that (publicly trusted) Certificate Authorities are "regularly compromised" while some random guy's PGP keys on his laptop are "much more secure". You claim to be worried about "sketchy governments" so here's a nice simple exercise. List the maintainers of the top say, 100 Alpine packages and for each the countries of which they are citizens and their country of residence. Someone worried about "sketchy governments" would definitely know all this of course, since it's _far_ easier for a "sketchy government" to lean on one individual. Next I'd like to know what Alpine is doing to ensure all those PGP keys are kept safe and that, for example, nobody's PGP key for signing Alpine packages is on, say, an unencrypted backup they took back in 2017... If one of the CAs in the Web PKI does something they shouldn't there's a public forum for discussing how it happened, what's being done about it, how it will be prevented from happening again, and so on. Where can I find the public forum where Alpine maintainers have to confess to anything that goes wrong?
    - Sir_Cmpwn 8y ago
      I still have to trust some random guy, SSL or not. Let me put this in simpler terms. With PGP, I have to trust: - The package maintainer (aka random guy with a laptop, aka ncopa) - ncopa's government With SSL, I have to trust: - The package maintainer - ncopa's government - My government - The governments of anyone along the link - Certificate authorities - The governments of every trusted certificate authority - A workplace's mandatory root certificate which MITMs all browser traffic - etc Which of these lists has fewer threats? SSL is generally more secure than the alternative, but it doesn't add security on top of a PGP-signed package repository.
      - comex 8y ago
        It's not a question of SSL versus PGP. It's a question of PGP + SSL versus PGP alone. SSL provides: - Privacy, i.e. making it harder to learn what packages you are installing, or any data about your system that can be gathered from request headers. (Traffic analysis is still possible, but much more difficult and won't disclose request headers.) - An extra layer of defense if there are flaws in the system doing PGP verification, as in this instance (or perhaps in the HTTP protocol implementation itself). Of course, the most important thing is to fix that system, and IMO apk should continue to be regarded as insecure as long as it continues to unpack files onto the root FS before doing any verification; there are just too many ways to screw that up. Still, in practice, adding SSL would have made it much more difficult for an attacker to get to a position where they could exploit the vulnerability. Both of the benefits above are relatively minor. But in a world where SSL is now the expected default for the vast majority of things served over HTTP, the cost of adding SSL to one more thing should be seen as extremely minor, making it easily justified.
zamadatix 8y ago
I don't understand your argument - why would the SSL certificate need to be publicly signed but it's alright for self signed PGP keys being added as part of initial install? You may ask "well why not just use PGP if it's not going to be publicly signed" and to that I would say "so the attacker can't even establish an HTTP session, further reducing the attack surface".
- Sir_Cmpwn 8y ago
  Because I'm trusting individual package maintainers directly, not a suite of shady CAs. Have you ever looked at the list of trusted CAs? They're large, opaque, and shady businesses that I want no dealings with. CAs don't establish trust, they just establish privacy. I could go make myshadysite.com and get a certificate for it and serve malware. I trust Alpine Linux, not Alpine Linux's certificate authority. And for the record, the initial iso download is secured with SSL. I can also establish trust through my other Alpine installs, with friends who have also installed Alpine, via magnet links from friends (which are inherently sha'd), by emailing several package maintainers and cross verifying their signatures, consulting keyservers, etc. However you do it, once you establish the initial trust PGP is a superior option to SSL.
  - Boulth 8y ago
    > I trust Alpine Linux, not Alpine Linux's certificate authority. Did you check and sign Alpine's maintainers key yourself or do you rely on the Web of Trust to create a path between you two? In the latter case every person in between of you two is acting like a certification authority.
    - Sir_Cmpwn 8y ago
      Yes, but all of those authorities are just people. Not hundreds of businesses with ulterior motives. Plus, compromising one WoT PGP key doesn't break the whole system like one compromised CA will.
  - zamadatix 8y ago
    > Because I'm trusting individual package maintainers directly, not a suite of shady CAs. Have you ever looked at the list of trusted CAs? Again, CAs are only needed for PUBLICLY signed certs but we are talking about a PRIVATELY managed trust and repo. The repo cert can be self-signed by the Alpine group and added to the root store during install the same as a PGP key can be added during install. No 3rd party "trust" involved.
icebraining 8y ago
I don't disagree that SSL/TLS doesn't add much security (though it does provide privacy regarding the packages being pulled), but don't conflate it with the CA system; they could just as easily pin the SSL/TLS cert at install.
- Sir_Cmpwn 8y ago
  Fair point, but this would still be less secure. Packages are generally signed by individual maintainers and as maintainers come and go, the trusted keyring evolves. It also puts the power of signing packages directly into the hands of maintainers, rather than granting access to a single all-powerful private key.
  - iancarroll 8y ago
    I don't think anyone is arguing that you should replace PGP signing with HTTPS.
    - Sir_Cmpwn 8y ago
      I don't think that anyone is arguing that, either. I'm saying adding HTTPS isn't an improvement.
      - vlovich123 8y ago
        And yet the existence of this exploit, which would have been prevented with HTTPS as I understand, counterproves your point. There's a reason security engineers advocate for defense in depth; even if one system fails you have a higher likelihood of preventing any issue or perhaps at least mitigating the scope/severity because other systems are still there. Self-signed HTTPS certs seems about as safe & secure as self-signed PGP packages so how can having both in any way reduce the overall security.
        Sir_Cmpwn 8y ago
        "The existence of an exploit" will undermine literally any system and you can't meaningfully use that argument.
tialaramex 8y ago
The web of trust doesn't come into the system you've described at all. Instead, everything is pinned to a particular key, and trust in that key is absolute. But you can do this perfectly well in TLS, indeed it's been discussed here on Hacker News more than once.
zaarn 8y ago
Well, if the signed package had been transferred over an SSL connection then this exploit would not have happened at all, so it's arguably more secure as it would have prevented a security bug in form of an RCE... You can also always run your own CA and trust it for the purpose of the APK installer or pin the CA or some other method, it would only be a problem if a CA got compromised (which I doubt is "easy" as you say, esp. if you restrict which CA's are allowed) AND APK had this bug.
- Sir_Cmpwn 8y ago
  The presence of a software exploit will undermine literally any secure system, including SSL, so this isn't a meaningful argument.
  - zaarn 8y ago
    You are aware of such things as layered security, yes? SSL isn't unbeatable security, it has holes, but it can help prevent a number of issues, such as the one in the OP to become critical at all. Similarly, PGP signing helps against a certain class of attacks. Both together cover a wider attack scenario than either alone. A software exploit could undermine literally any secure system but in this case the addition of SSL would have prevented this exploit from being dangerous to a huge number of people.
    - Sir_Cmpwn 8y ago
      I am aware of that, yes. Layered security and privacy of which packages you've downloaded are the two most compelling arguments in favor of SSL that I've seen in this thread. But I think it's reasonable to talk about security systems by giving the developers the benefit of the doubt that their code doesn't have exploitable bugs. My main point is that, assuming it's implemented without bugs, PGP is more secure than SSL, and that SSL alone would be worse than PGP alone. Combining them would be an improvement, but I'm rejecting the idea that the current design is insecure. Having the package maintainers personally tell you their package's checksums would have also prevented this problem, but it's clearly not practical. Sometimes SSL isn't practical. If you can design a system which is secure without it, it is an improvement, but not a requirement.

justicz 8y ago

In this case `apk` does a ton of processing on the package before checking that the hash matches the signed manifest, and the maintainers don't want to/can't change that behavior at this time. As a result, https would be a real security improvement here, at least for now.

iancarroll 8y ago

I don't like certificate authorities either but "easily compromised", especially in this context, is just disingenuous. HTTPS would be a meaningful security improvement to this system.

Sir_Cmpwn 8y ago
It's not. Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. PGP keys are much more secure. HTTPS would not be a meaningful security improvement, not accounting for justicz's comment. At best, it would be the same amount of security, but more annoying to maintain.
- JoshTriplett 8y ago
  > Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. They can't do that silently anymore, though, not without getting caught. Certificate Transparency addresses that.
- tialaramex 8y ago
  > It's not. Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. PGP keys are much more secure. Citation very much needed for this claim that (publicly trusted) Certificate Authorities are "regularly compromised" while some random guy's PGP keys on his laptop are "much more secure". You claim to be worried about "sketchy governments" so here's a nice simple exercise. List the maintainers of the top say, 100 Alpine packages and for each the countries of which they are citizens and their country of residence. Someone worried about "sketchy governments" would definitely know all this of course, since it's _far_ easier for a "sketchy government" to lean on one individual. Next I'd like to know what Alpine is doing to ensure all those PGP keys are kept safe and that, for example, nobody's PGP key for signing Alpine packages is on, say, an unencrypted backup they took back in 2017... If one of the CAs in the Web PKI does something they shouldn't there's a public forum for discussing how it happened, what's being done about it, how it will be prevented from happening again, and so on. Where can I find the public forum where Alpine maintainers have to confess to anything that goes wrong?
  - Sir_Cmpwn 8y ago
    I still have to trust some random guy, SSL or not. Let me put this in simpler terms. With PGP, I have to trust: - The package maintainer (aka random guy with a laptop, aka ncopa) - ncopa's government With SSL, I have to trust: - The package maintainer - ncopa's government - My government - The governments of anyone along the link - Certificate authorities - The governments of every trusted certificate authority - A workplace's mandatory root certificate which MITMs all browser traffic - etc Which of these lists has fewer threats? SSL is generally more secure than the alternative, but it doesn't add security on top of a PGP-signed package repository.
    - comex 8y ago
      It's not a question of SSL versus PGP. It's a question of PGP + SSL versus PGP alone. SSL provides: - Privacy, i.e. making it harder to learn what packages you are installing, or any data about your system that can be gathered from request headers. (Traffic analysis is still possible, but much more difficult and won't disclose request headers.) - An extra layer of defense if there are flaws in the system doing PGP verification, as in this instance (or perhaps in the HTTP protocol implementation itself). Of course, the most important thing is to fix that system, and IMO apk should continue to be regarded as insecure as long as it continues to unpack files onto the root FS before doing any verification; there are just too many ways to screw that up. Still, in practice, adding SSL would have made it much more difficult for an attacker to get to a position where they could exploit the vulnerability. Both of the benefits above are relatively minor. But in a world where SSL is now the expected default for the vast majority of things served over HTTP, the cost of adding SSL to one more thing should be seen as extremely minor, making it easily justified.

zamadatix 8y ago

I don't understand your argument - why would the SSL certificate need to be publicly signed but it's alright for self signed PGP keys being added as part of initial install? You may ask "well why not just use PGP if it's not going to be publicly signed" and to that I would say "so the attacker can't even establish an HTTP session, further reducing the attack surface".

Sir_Cmpwn 8y ago
Because I'm trusting individual package maintainers directly, not a suite of shady CAs. Have you ever looked at the list of trusted CAs? They're large, opaque, and shady businesses that I want no dealings with. CAs don't establish trust, they just establish privacy. I could go make myshadysite.com and get a certificate for it and serve malware. I trust Alpine Linux, not Alpine Linux's certificate authority. And for the record, the initial iso download is secured with SSL. I can also establish trust through my other Alpine installs, with friends who have also installed Alpine, via magnet links from friends (which are inherently sha'd), by emailing several package maintainers and cross verifying their signatures, consulting keyservers, etc. However you do it, once you establish the initial trust PGP is a superior option to SSL.
- Boulth 8y ago
  > I trust Alpine Linux, not Alpine Linux's certificate authority. Did you check and sign Alpine's maintainers key yourself or do you rely on the Web of Trust to create a path between you two? In the latter case every person in between of you two is acting like a certification authority.
  - Sir_Cmpwn 8y ago
    Yes, but all of those authorities are just people. Not hundreds of businesses with ulterior motives. Plus, compromising one WoT PGP key doesn't break the whole system like one compromised CA will.
- zamadatix 8y ago
  > Because I'm trusting individual package maintainers directly, not a suite of shady CAs. Have you ever looked at the list of trusted CAs? Again, CAs are only needed for PUBLICLY signed certs but we are talking about a PRIVATELY managed trust and repo. The repo cert can be self-signed by the Alpine group and added to the root store during install the same as a PGP key can be added during install. No 3rd party "trust" involved.

icebraining 8y ago

I don't disagree that SSL/TLS doesn't add much security (though it does provide privacy regarding the packages being pulled), but don't conflate it with the CA system; they could just as easily pin the SSL/TLS cert at install.

Sir_Cmpwn 8y ago
Fair point, but this would still be less secure. Packages are generally signed by individual maintainers and as maintainers come and go, the trusted keyring evolves. It also puts the power of signing packages directly into the hands of maintainers, rather than granting access to a single all-powerful private key.
- iancarroll 8y ago
  I don't think anyone is arguing that you should replace PGP signing with HTTPS.
  - Sir_Cmpwn 8y ago
    I don't think that anyone is arguing that, either. I'm saying adding HTTPS isn't an improvement.
    - vlovich123 8y ago
      And yet the existence of this exploit, which would have been prevented with HTTPS as I understand, counterproves your point. There's a reason security engineers advocate for defense in depth; even if one system fails you have a higher likelihood of preventing any issue or perhaps at least mitigating the scope/severity because other systems are still there. Self-signed HTTPS certs seems about as safe & secure as self-signed PGP packages so how can having both in any way reduce the overall security.
      - Sir_Cmpwn 8y ago
        "The existence of an exploit" will undermine literally any system and you can't meaningfully use that argument.

tialaramex 8y ago

The web of trust doesn't come into the system you've described at all. Instead, everything is pinned to a particular key, and trust in that key is absolute. But you can do this perfectly well in TLS, indeed it's been discussed here on Hacker News more than once.

zaarn 8y ago

Well, if the signed package had been transferred over an SSL connection then this exploit would not have happened at all, so it's arguably more secure as it would have prevented a security bug in form of an RCE... You can also always run your own CA and trust it for the purpose of the APK installer or pin the CA or some other method, it would only be a problem if a CA got compromised (which I doubt is "easy" as you say, esp. if you restrict which CA's are allowed) AND APK had this bug.

Sir_Cmpwn 8y ago
The presence of a software exploit will undermine literally any secure system, including SSL, so this isn't a meaningful argument.
- zaarn 8y ago
  You are aware of such things as layered security, yes? SSL isn't unbeatable security, it has holes, but it can help prevent a number of issues, such as the one in the OP to become critical at all. Similarly, PGP signing helps against a certain class of attacks. Both together cover a wider attack scenario than either alone. A software exploit could undermine literally any secure system but in this case the addition of SSL would have prevented this exploit from being dangerous to a huge number of people.
  - Sir_Cmpwn 8y ago
    I am aware of that, yes. Layered security and privacy of which packages you've downloaded are the two most compelling arguments in favor of SSL that I've seen in this thread. But I think it's reasonable to talk about security systems by giving the developers the benefit of the doubt that their code doesn't have exploitable bugs. My main point is that, assuming it's implemented without bugs, PGP is more secure than SSL, and that SSL alone would be worse than PGP alone. Combining them would be an improvement, but I'm rejecting the idea that the current design is insecure. Having the package maintainers personally tell you their package's checksums would have also prevented this problem, but it's clearly not practical. Sometimes SSL isn't practical. If you can design a system which is secure without it, it is an improvement, but not a requirement.