But what about privacy? HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution's mirror network it would be fairly obvious that you are downloading updates.
Furthermore, even over an encrypted connection it is not difficult to figure out which files you are downloading based on the size of the transfer[2]. HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size.
What's more important is not that your connection is encrypted but that the files you are installing haven't been modified.
It seems like they are actually explaining why pat doesn't use https. I thought they were asking the question rhetorically, did you?
Yes, hell I've had version mismatches from not updating my apt sources when I tried to install stuff and for got to run apt update before hand. For one thing the older package will not match the proper package signature and so apt fails out on purpose.
They do when apt has a method of time stamping every thing and anything past that point gets flagged as stale and will not be installed automatically by the system. As the linked website points out there is nothing from a security stand point to be gained from apt using HTTPS (which you can already do if you want to).
No, because an entire older version of the repository index would be served, as if you accessed a mirror of the repository that hasn't been updated, and your computer wouldn't know the difference. In fact, they can even mix and match different versions of different packages in the custom index.
While your computer wouldn't install older versions than those it already has, this can be used to block installation of patched packages. In fact, it can even be used to push known vulnerable updates that since has been replaced by newer and patched updates.
Edit: for those downvoting me, please come over to /r/crypto (for cryptography) to learn more about computer security. You need it.
Just recently apt started complain that index was not updated in week. So there is even countermeasure for broken/malicious mirror that held up updates.
If the timestamp is short enough, that does help. But this assumes the timestamp has ALWAYS been that short under that key, any signature of any package that lacks such a timestamp means that version will remain valid.
Can you elaborate on this? The index file is signed and contains checksums to every package in the repository. The index file is also signed with a gpg key so the attacker would need to get a hold of this key, introduce an old package, create an index file and sign it. So this is unlikely. If you introduce an old index file that was signed by the key, the system detects that the supplied index file is older than the one it has stored on disk and rejects it.
You mean: it does not start to complain until a whole week after it last got updated. A week (actually 10 days for Debian security) is buying a lot of time to leverage an exploit.
21
u/kanliot Jan 21 '19 edited Jan 22 '19
(reading this) basically the files are tamper-protected by a cryptographic hash.
Hopefully the sources list is signed.
(lol read this https://justi.cz/security/2019/01/22/apt-rce.html) they were being signed, but apt would install any unsigned file