> 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?
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.
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.
These are both very good points, though I want to point out that the first doesn't lead to RCE, which is a much more severe problem that information disclosure. I think Alpine should add SSL, but my message is that I don't think that the problem on display here is result of a flaw in the current design.
What you're doing here is a technique called the Gish Gallop - in which rather than engage with debate you just try to introduce more and more "reasons" you're right, most of them entirely spurious, hoping to somehow win on the numbers.
That is not an honest way to have a conversation. Knock it off.
I'm doing no such thing. I have issued rebuttals and new arguments, not just new arguments and a tactical ignoring of the counterarguments. If you can't address my points then don't.
Don't acuse me of arguing in bad faith. You can knock that off, thank you very much.
1. Any citation whatsoever for your claim that "Certificate authorities are regularly compromised"
2. Any citation whatsoever for your claim that "PGP keys are much more secure"
3. The list of those maintainers and their countries you're actually trusting for some reason with your current stance even though you're supposedly worried about "sketchy countries". Yes, a list, I know, you don't have one. Which is illustrative that in fact this "sketchy countries" concern was pure invention and you don't actually care.
4. The measures Alpine puts in place to protect these keys. Again in reality there aren't any, and in reality you don't care, because your concerns are bullshit. In the technical sense.
5. The public forum where I, as a third party, can see that this is all above board and not, as is the reality, just nobody cares and it's all assumed to be fine. For reference for the Web PKI this forum is operated by Mozilla, mozilla.dev.security.policy
Things you did provide:
1. A big list of non-threats like on-path governments somehow tampering with HTTPS.
That's a Gish Gallop. You don't engage with the existing debate, you just keep spewing more "new arguments" of no value, in the hope people will accept you're right.
4: I don't know the particular steps ncopa et al take to safeguard their private keys, but that doesn't mean that my concerns are technical bullshit.
5: You're looking for alpine-devel, a public mailing list.
I'm not going to entertain further discussion with you if you aren't going to be civil. Ask questions and I will ask them. Acuse me of bad faith and call my concerns bullshit and I won't.
I didn't ask you for "explanation" I asked you for citations supporting such extraordinary (indeed I'd go so far as to say ridiculous) claims. You still haven't done so and I think it's entirely reasonable to conclude that this is because you cannot.
Not technical bullshit, bullshit in the technical sense.
"Bullshit" is a technical term that's distinct from a lie. Lies are told on the understanding that they're a falsehood, with the intent to deceive, but bullshit isn't interested in the veracity of the claim at all, it serves only a rhetorical purpose.
Comodo has had their signing keys compromised multiple times. I can probably dig up the old ZeroForce (ZF0) chat logs that show them poking around their forum servers that had copies of the signing certs. I am not even kidding. They had their signing certs sitting on their phpBB forum. That all started from one of their employees taunting some kids on irc.
Symantec has signed and provided signing certs for multiple government agencies and proxy vendors, allowing them to sign for anything. That is part of the reason Google is distrusting them.
There are many more, but a majority of certs in use today are from one of those two companies. They also have numerous re-sellers with signing certs, so the names won't always be Symantec or Comodo, hence one more need for intermediate certs.
TLS today just means the average Joe won't be able to see the specific bits you are transferring. Sorry Joe.
Whilst pwning Comodo's web server is presumably fun, the signing _keys_ don't live in a Linux box running phpBB or whatever nonsense that was, they're in a dedicated HSM. The certificates on the other hand are public documents, everybody has a copy of those.
Symantec certainly did sell certificates to the US government, and to companies that make breakfast cereal, and indeed to at least one bona fide children's party clown. But those didn't allow them to "sign for anything". I was part of the distrust discussions you're talking about so let's see how close to the facts you were.
Here are the real issues closest to what you've described:
Issue L: Symantec signed the US government's "Federal Bridge" PKI, which is a PKI for the use of the Federal Government, a vast sprawling mess.
Issue P: Symantec issued a subCA to UniCredit (an Italian bank) which was operated incorrectly and without an audit until October 2016
Issue T: The Korean firm "CrossCert" and three other Symantec partner companies were able to issue certificates as Registration Authorities, although Symantec was not effectively overseeing this activity. Non-compliant certificates were issued, mostly for Korean firms, and Symantec says CrossCert did not have any paperwork for these certificates, which Symantec should have known about back when the certs were issued.
Issue V: Symantec's "GeoRoot" programme provided subCAs under technical control to five companies to issue their own trusted certificates within certain constraints. These five were: Aetna, Apple, Google, Intel, and Unicredit (but see P above) and the audit paperwork for these subCAs was always reprehensible garbage, an unnamed root program (probably Microsoft, given that Apple and Google are on the list) was pressuring Symantec to fix this, but they had not done so before Symantec got themselves distrusted.
Issue Y: The "VeriSign Universal Root Certification Authority" CA has a couple of subCAs that are not themselves constrained to prevent issuance in the Web PKI but are also not sufficiently audited or subject to oversight. Symantec swore these subCAs aren't actually used in the Web PKI, but without a technical constraint that's hard to enforce.
Back when Symantec was operating a CA, the two companies together (all of Symantec, including Versign and other brands, plus Comodo) had than 40% of "market share" in the top 10K web sites, and far less in the deeper corners of the web. Most certs are from Let's Encrypt and that's still true today.
Because of how modern TLS works, bad guys would need either to use a large quantum computer for each individual session they want to break (problem: those don't exist) or they'd need not only a publicly trusted certificate, but also a live active attack on the session as it happens, which would of course be detectable.
Comodo most certainly had copies of everything on their forum servers. They had to be revoked. Yes, some time later they started using HSM's. Too little, too late. They lost a lot of trust after those incidents.
The problem with the story "they had to be revoked" is that er, they weren't revoked. Comodo's roots from that era are still in use today. That's because though you've said so twice now, those keys weren't "on their forum servers" and remained in Comodo's hands.
I think you're conflating two incidents, one from 2008 when ZF0 broke into a poorly secured web forum on Comodo's systems and one in 2011 where "ComodoHacker" gained access to Comodo's issuance system because they used a single factor password login system, and was able to create a bunch of certificates for themselves using the account credentials they had.
You might even be further conflating problems at DigiNotar, which "ComodoHacker" also claimed responsibility for, where Iran was using certs DigiNotar had no record of to MITM its citizens. DigiNotar is gone, the company is defunct, that entire hierarchy was distrusted seven years ago.
> 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".
Actually X.509 keys evolved under enterprise pressure and some devices have nice additional security measures. For example it's possible to attest that a given X.509 key was generated on a Yubikey (so it's only in hardware, no copies exist) [0]. Microsoft EV code signing certs require hardware keys. OpenPGP doesn't have this.
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?