Attacks against GPG-signed APT repositories

Discussed on HN 3 months ago: https://news.ycombinator.com/item?id=16432435 (13 comments)

Arbitrary package attack - fixed >4 years ago, requires explicit config to enable downgrade, but some distros screw that up

Replay and Freeze attacks -- Ouch! sounds like every repo should set an aggressive Valid-Until (24 hours?). This attack still works with a compromised SSL mirror, and seems (according to the link below) to already be addressed as of at least 5 months ago

Extraneous Dependencies -- sounds like a bug in apt, also manifests for a compromised TLS mirror.

Endless Data -- nothing to do with GPG or TLS

Improper error handling in APT -- 18 month old bug

apt-key silently fails to remove GPG keys -- unfortunate and doubtlessly due to gnupg's lack of a real API

Conclusion -- at least 3 of the listed bugs manifest identically with SSL, another 2 are fixable implementation bugs. None are issues endemic to using GPG in preference to SSL, and none exclusively support the article's conclusion to always use SSL. Post fails to contrast the GPG bugs situation with the fact that e.g. Heartbleed occurred during the same timeframe as the bugs that were mentioned, one of many crucial factors in deciding the relative security of either solution, post additionally fails to mention with GPG the root of trust is the repository signer, which is still required with SSL, SSL only protects 'last mile' and specifically does not protect against a compromised mirror

I must admit though, the replay attack is scary and a very nice find.

Be sure to also read https://whydoesaptnotusehttps.com/ to see the other side of the coin

Finally, consider perusing the list of OpenSSL CVEs since 2014: https://www.openssl.org/news/vulnerabilities.html and the corresponding list for gnupg: https://nvd.nist.gov/vuln/search/results?form_type=Basic&res... -- bearing in mind that when SSL is deployed the union of both lists applies, without SSL only the gnupg list applies

`apt-transport-https` has been merged in apt since v1.5. Good.

https://ftp.us.debian.org returns a certificate for `mirrors.wikimedia.org`. https://ftp.it.debian.org returns a certificate for `ftp.bofh.it`. Do mirrors support TLS?

The linked paper was a precursor to the work on The Update Framework https://theupdateframework.github.io/ which is a signing framework to alleviate these issues. It was originally developed for Tor, and has a well designed threat model.

As noted in the previous discussion of this, it is, IMO not unfair to call this a PR hit piece. The authors are competing with the official APT repositories, and instead of informing users to patch, like a usual vulnerability announcement, it is instead in their business interest to drive as many clicks as possible and exaggerate the vulnerabilities. Regardless of the partially valid issues raised, it was apparent from the reading it that marketing their services was the prime goal of this article, so I rejected and still reject this article out of principle (and have felt extremely reluctant to use their services ever since).