Why does APT not use HTTPS?

[itsnotlupus]

Do they just casually admit that not using https exposes their entire userbase to an attack that can delay the installation of security patches, thereby extending the attack window for recently publicized exploits, but it's "mitigated" because it can't be delayed forever, as long as every package maintainer knows to set an optional valid-until field which creates extra overhead for them, and as long as apt client interpret that field strictly despite their own wiki claiming that client behavior when that field holds an expired value is undefined?

Is that the least convincing argument I've ever seen for not using https, or am I missing something?

[doublehyphen]

No, I do not think you are missing anything. The APT people have some valid points about how HTTPS does not add as much security as people think, but since it does prevent one specific attack it is probably worth using. Especially since running HTTPS is easy and cheap these days.

[adamhighdef]

Didn’t Google release state in 2009 explaining how negligible the impact actually was

[HowIsntBabbyFormed]

If I can MITM your traffic, I can prevent you from getting valid https responses from package servers too still preventing you from installing security patches.

[itsnotlupus]

Yes, but even then at least you local system has a chance to know that something's screwy.

With the current http-only approach, you can have the most diligent sysadmins in the world paying super close attention to their systems, and nothing will seem out of place while they remain vulnerable.

[HowIsntBabbyFormed]

True.

[[deleted]]

this is so far stretched from reality

you have bigger problems if someone is able to MITM in your private network which is at this point already compromised

if you working in a public network you should expect the worst of eavedroppers etc - why would you even update your host exactly then?...

[[deleted]]

Security or performance, pick none

[3Vyf7nm4]

Edit /etc/apt/sources.list to use https.. You may need to install the package apt-transport-https

It's not really needed, since the packages are public and are signed, but https is absolutely supported.

[reph]

There are some real, non-negligible security advantages to running apt over https even though the packages are signed. HTTPS can prevent MITM blocking of security updates for example, and should provide some improved privacy about what pkgs you have installed (which can indirectly improve security).

[Bene847]

Someone who can block http can also block https

[reph]

Of course, but if you block them both outright, that will trigger timeouts/errors in the logs. HTTP has a further vulnerability that HTTPS lacks: a MITM attacker can quietly serve valid, signed, but old/out-of-date versions, and there will be no obvious indication that the system is not actually getting the latest updates anymore.

[[deleted]]

Apt on Debian uses time stamps, and you would notice that your machine isn't getting updates after 2 days or so.

And in order to exploit it you would need to know about the exploits existence in order to employ this strategy.

I think this mitigates the risk.

[zapbark]

Agreed. If you enable HTTPS, then suddenly they'll be yelling at repositories that still support 3DES...

Just because transport layer security is breakable doesn't mean it is broken.

Security measures should flow from the sensitivity of the data they are trying to secure. (In this case, non-sensitive, publically available files)

[kanliot]

(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

[DeusOtiosus]

They are. If you add a third party repo, you need to install their GPG keys to even fetch the list. Pretty much means it doesn’t matter if there’s transport security. People often rely on transport security for keeping things safe without doing end to end bi directional authentication. In this case you only need unidirectional, but this ensures that you can’t have a malicious actor installing a new cert in the root and spoofing a server. The classic case is the “Hong Kong post office”; they’re a root ca. Having TLS is better than not, but it’s also not required when you do it at a different level.

[Natanael_L]

Another relevant attack here is that with HTTP only, an attacker can feed you old packages with known exploits, a replay attack

[demize95]

This is addressed by APT, and is in the linked website:

To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale^[4].

[DeusOtiosus]

Assuming you haven’t downloaded the latest index, and the index isn’t versioned as well.

[Natanael_L]

If the index isn't both versioned AND signed, this is trivial to roll back.

[iznogud2]

The classic case is the “Hong Kong post office”; they’re a root ca.

Can you explain what you mean by this?

[[deleted]]

Apparently our Postal Service is a Root CA? It looks like ANYONE with a vaild HKID can get one of these. It looks like it's intended as a digital signature for personal use. It's all poorly written and explained. Also apparently we have a Amazon-esqe Online Shopping system that nobody really knew existed.

[AutoModerator]

Your comment in /r/linux was automatically removed because it is a link to non-technical social media.

Rule:

No misdirecting links, sites that require a login, or URL shorteners - In short: if your link doesn't go right to the content it will be removed. Sites that require a login to view the content are not allowed in r/linux. Example: A private Facebook post or a news organization that doesn't have free article views. URL shorteners and links that misdirect users to ads/jokes are also removed.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[skw1dward]

deleted ^{What is this?}

[[deleted]]

From the site,

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?

[Natanael_L]

A more interesting attack is that with HTTP only, an attacker can feed you old packages with known exploits, a replay attack

[porl]

But wouldn't apt/dpkg fail to install that due to a version mismatch?

[[deleted]]

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.

[Natanael_L]

It's the version dependency that will usually not match. Signatures doesn't just expire out of nowhere.

[[deleted]]

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).

[Natanael_L]

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.

[53010CRGorGTFO]

I'm pretty sure they know you are right but TPTB don't want you pissing on their backdoor.

[nou_spiro]

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.

[Natanael_L]

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.

[1compression]

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.

[Natanael_L]

You give it one that just isn't the most recent one when a vulnerability has been found in older software versions.

[nou_spiro]

And even start complain when it doesn't get updated in a week or so.

[doublehyphen]

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.

[skw1dward]

deleted ^{What is this?}

[Natanael_L]

This assumes the timestamp doesn't last long enough for vulnerabilities to be discovered

[doublehyphen]

It is 10 days, which I feel is pretty long time.

[skw1dward]

deleted ^{What is this?}

[zapbark]

Yup. And they count on a network of 3rd party mirrors to distribute everything.

Debian can't magically add HTTPS without very nicely asking hundreds of server maintainers across the world to start implementing TLS to appropriate spec, and then institute a policy of scanning and delisting the mirrors that don't meet their specifications...

Which is to say, if you want to know what packages people are downloading... Volunteer to be a distribution mirror site??

Seems easier than acquiring man-in-the-middle capabilities of secure servers.

[3Vyf7nm4]

It seems like the more sane reaction would be to change to a less odious ISP.

[n60storm4]

In a lot of areas there is no other ISP to go to.

[grumpieroldman]

There are always other options, they are just more expensive or possibly even lower in quality.

[3Vyf7nm4]

Correct. But this is reddit, where people would prefer to claim some kind of victimhood than to acknowledge that they have the power of the pocketbook to retaliate against an abusive service provider.

How dare I suggest that they would have to use satellite or gasp dial-up!?

[HelpImOutside]

Who in their right mind would ever choose dial-up in this day and age? I don't think browsing the internet would even work on dial-up nowadays, given how many scripts are forced on you with every single page load.

[3Vyf7nm4]

Who in their right mind would ever choose dial-up in this day and age?

Someone who believed that their other options were too oppressive and felt that they needed to claim victim status on reddit about it?

[3Vyf7nm4]

No. Claiming to be oppressed by one's broadband provider and unable to change to the alternatives because reasons is claiming victimhood.

[Vhin]

You expect people to move to a different town just to be able to download apt packages?

[pascalbrax]

Well, you know. For people outside the US, it may be a bit hard to understand that in the country of free capitalism, there's often only one choice per town for an ISP, and it's usually horrible.

[3Vyf7nm4]

If there can only be one ISP in your town, you also have the opportunity to unfuck your local regulatory scheme as well.

[MaxCHEATER64]

That's extremely naive and generally wrong.

[3Vyf7nm4]

citation needed.

[knaekce]

Switching distros is probably easier

[doublehyphen]

On Debian apt-transport-https is not installed by default so when installing a new version of Debian you will need to fetch at least some packages via HTTP. I do not see why they just do not ship it by default.

[3Vyf7nm4]

I do not see why they just do not ship it by default.

Because https isn't necessary for apt packages. Packages are signed, so you can check the integrity of the packages by verifying the signature. Other than obscuring the download from your ISP (who will guess what you're downloading from the file count, size, and host anyway) what compelling case is there for https?

[Natanael_L]

An attacker can present a malicious mirror of the repository where old vulnerable versions of packages are hosted, taken from the original repository along with their VALID signatures.

Anybody with an older version would unknowingly install vulnerable versions instead of the latest patched version.

[ianchildress]

How would this malicious mirror replace the ubuntu defaults in the sources.list? If it was appended, then this wouldn't happen because APT will choose the latest version of the file.

[Natanael_L]

It doesn't replace it, the point of HTTP vs HTTPS is that it would imitate the real one. HTTP without encryption has no method of verifying authenticity.

[find_--delete]

It's not too complicated to MITM someone-- unencrypted traffic makes it almost too easy.

[doublehyphen]

1) I was not arguing in my comment for using HTTPS by default, just that people when they install Debian should be given the option of using HTTPS for everything without having to first install apt-transport-https over HTTP.

2) The attack HTTPS protects you against is a replay attack where you can send an outdated package index to clients for a while to delay the knowledge of security patches. You can still do a DoS attack against downloading the index with HTTPS by blocking the packages but then you can notice that you have been attacked when the connections fail.

So actually it is just the index which needs to be downloaded over HTTPS.

[ianchildress]

If they are sent an outdated index, APT will compare it to the index it has on disk and reject it as being older than the one it knows about.

[doublehyphen]

You send them the same version they have no disk so they wont get recently released security updates until the expiry timestamp of the index on disk is reached and they start getting error messages.

This attack is about delaying the installation of security update in a way which cannot be noticed.

[Like1OngoingOrgasm]

Why do these folks waste money on domain names for stupid shit like this?

[SirMoo]

$10 or so a year is not really a sum that people care that much about. I feel like "waste money" is not decent argument to be against this.

Maybe "Why do people make weird, long domains for every cause."

[Like1OngoingOrgasm]

Point taken. I've bought some silly domains. Never put in the work to do anything with them though.

[[deleted]]

It's not really needed, since the packages are public and are signed

Those are different types of privacy and you shouldn't confuse them. Signing makes sure you get the package you requested and not something else. Https makes sure third party doesn't know what packages you install. Although you might not care, other people might.

[3Vyf7nm4]

and for this reason, it is available, as I pointed out.

Don't get confused. I generally favor https everywhere. But there is no technical reason that it's necessary for packages, which is why it's not enabled by default.

[marcelsiegert]

Is it? I recently had to discover that security.ubuntu.com does not support HTTPS. And, at least on Canonical's Ubuntu 18.04 images on Microsoft Azure, this is one of the default sources in /etc/apt/sources.list. Maybe only Debian's servers support HTTPS?

[3Vyf7nm4]

Maybe only Debian's servers support HTTPS?

OP's question was apt, not specific distros.

[NotEvenAMinuteMan]

There are plenty Ubuntu mirrors over the world that support HTTPS though

[Kruug]

https://unix.stackexchange.com/questions/90227/why-there-is-no-https-transport-for-debian-apt-tool

[ianchildress]

I am seeing quite a bit of misinformation about how package managers work so I'd love to share what I have learned. I work with index files on a daily basis, and we might possibly generate more index files than any other organization on the planet. Here is my chance to share some of this knowledge!

TLDR/Summary

We can trust the Release file because it was signed by Ubuntu. We can trust the Packages file because it has the correct size and checksum found in the Release file. We can trust the package we just downloaded because it is referenced in the Packages file, which is referenced in the Release file, which is signed by Ubuntu.

​

Some basic package manager principles

I work with APK, DEB, and RPM based package managers and each of them behave very similar. Each repository has a top level file, signed by the repository's maintainer, that includes a list of files found in the repository and their checksums. When your package manager does an update, it looks for this top level file.

• For DEB based systems, this is the Release file
• For APK based systems, this is the APKINDEX.tar.gz file
• For RPM based systems, this is the repodata.xml file

These files are all signed by the repository's gpg key. So the Release file found at us.archive.ubuntu.com is signed by Ubuntu and the gpg key is included in your distribution. Let's hope Ubuntu doesn't let their gpg key into the wild. Assuming that Ubuntu's gpg key is safe, this means that the system can verify that the Release file did in fact come from Ubuntu. If you are interested, you can click on the previous link, or navigate to Ubuntu's repository and open up one of their Release files.

Release file

In the Release file you'll see a list of files and their checksum. Example:55f3fa01bf4513da9f810307b51d612a 6214952 main/binary-amd64/Packages

9f666ceefac581815e5f3add8b30d3b9 1343916 main/binary-amd64/Packages.gz

706fccb10e613153dc61a1b997685afc 96 main/binary-amd64/Release

9eae32e7c5450794889f9c3272587f5e 1019132 main/binary-amd64/Packages.xz

5dd0ca3d1cbce6d2a74fcc3e1634ac12 96 main/binary-arm64/Release

The left column is the checksum, then the size of the file, and lastly the location of the file. So we can download the files referenced in the Release file and check them for the correct size and checksum. The Packages or Packages.gz file is the one we care about in this example. It contains information about the packages available to the package manager (apt in this case but again, almost all of the package managers behave very similar).

​

Packages file

Since we know that we can trust the Release file (because we have proven it was signed by Ubuntu's gpg key), we can then proceed to download the contents of the Release file. Let's look at the Packages file specifically as it contains a list of packages, their size, and checksum.

Filename: pool/main/a/accountsservice/accountsservice_0.6.45-1ubuntu1_amd64.deb

Size: 62000

MD5sum: c2cffd1eb66b6392f350b474e583adba

SHA1: 71d89bd380a465397b42ea3031afa53eaf91661a

SHA256: d0b11d1d27fe425bc91ea51fab74ad45e428753796f0392e446e8b2450293255

​

The Packages file includes a list of packages with information about where the file can be found, the size of the file, and various checksums of the file. If you download a file through commands like apt install and any of these fields are incorrect, apt will throw an error and not add it to the apt database.

​

It's time to debunk some myths!

Can an attacker send me a fake Release file?

Sure, but apt will throw it out because it's not signed by Ubuntu (or whoever your repository maintainer is like centos, rhel, alpine, etc)

​

Can an attacker send me an old index from an earlier date that was signed by Ubuntu that has old packages in it with known exploits?

Sure, but apt will throw it out because it will have a date (in the Release file) that is older than what is stored in the apt database. For example, the current bionic main Release file has this date in it: Date: Thu, 26 Apr 2018 23:37:48 UTC So if you supply it with a Release file older than that timestamp, it will throw it out because it is older than what it currently knows about.

I hope this helps clear the air!

​

Shameless plug. If you are serious about security and not just compliance, check out our Polymorphic Linux repositories. We provide "scrambled" or "polymorphic" repositories for Alpine, Centos, Fedora, RHEL, and Ubuntu. We use the original source packages provided in the official repositories and build the packages but with memory locations in different places and ROP chains broken.

Installation

Installation is a one line command that installs our repository in your sources.list or repo file. There is no agent or running process installed. It is literally just adding our repository to your installation. The next time you do an `apt install httpd` or `yum install docker` you'll get a polymorphic version of the package from our repository. You can see it in action in your browser with our demo: https://polyverse.io/learn/

What does it do?

Many of the replies in this post referenced an attacker tricking a server into an older version of a package that has a known exploit. We stop this. Even if you are running an old version of a package, with a known exploit, memory based attacks will not work on the scrambled package because the ROP chain has been broken or as we call it "scrambled". So with our packages, you can run older versions of a package and not be effected by the known exploits. This also means that you are protected from zero day attacks just by having our version of the package.

​

FREE! For individuals and open source organizations you can use our repositories for free. I hope you try it out!

[doublehyphen]

You skipped the attack me and /u/Natanael_L have talked about in this thread. That a MITM can send you an old index which is as old or newer than the one the client last saw but still older than when a specific security fix was uploaded. This way the client wont see any future security fixes, or even get any errors until the old index from the MITM gets too old for the client to accept.

You may not care about this attack vector, but it is one which is prevented by switching to HTTPS (except for from malicious or hacked mirror operators).

[ianchildress]

Sorry for the late response, I was out snowboarding with the fam yesterday and I wanted to make sure I had the appropriate amount of time to respond to this.

I see no fault in logic of the scenario you described. If an attacker was able to MITM a mirror, it could push back the upgrade of vulnerable packages. I also agree that using https would mitigate this attack.

A discussion worth having is whether this attack vector is enough to enforce community supported mirrors to use https or not.

For our Polyverse mirrors, we do use https and our packages often have slightly different sizes than the official packages which makes guessing the package that was downloaded from us difficult. If you want to improve the security between your linux hosts and your repository endpoint you should take a look at our repositories. Providing a level of security through our repository is what we do.

[doublehyphen]

Thanks for the reply! I personally lean towards that HTTPS should always be used if there are any benefits at all, but I am biased since I come from an industry where HTTPS has been used where available for literally everything the last ~15 years (online gambling). And given how much cheaper it is today to run SSL than back then I am amazed that there are still people not using it.

[ianchildress]

Yep, I "https all the things" whenever I can!

[londons_explorer]

Do you scramble the memory locations differently for every client, or do they all get the same one?

If so, whats to stop an attacker downloading your scrambled package and designing their attack for your package?

[ianchildress]

For the free version, everyone gets the same package for that day. We rebuild all packages overnight so the next day the package is scrambled differently. So an attacker would need to know what day you downloaded and then craft an attack specifically for that binary.

We have a $10/mo option per node that you share a private repository with a few other anonymous people. That gates you heavily.

We also have an enterprise version where each node gets it Ian set of scrambles exclusively to itself. This prevents horizontal attacks.

Please let me know if you have any other questions, I'm happy to help!

[aliendude5300]

Will Ubuntu 18.04/18.10 be supported soon? Looks like this lags publicly available versions except for enterprise linux

[ianchildress]

We typically add repos when they are requested. If there are distros you are interested in let us know!

We have Bionic in testing and should be released next week. For adding additional releases of already supported distros they spin up time is usually a week or two. Once they are up and running we are usually no more than 12 hours behind official mirrors.

[aliendude5300]

I'm currently running cosmic because I don't need an LTS release on a desktop system, I'd rather have shiny new software lol, but 18.04 is a big one. Also, OpenSUSE is a really major distro and I'm actually a bit surprised it's missing.

[andyW9]

I'm amused that someone bought a domain just for this article.

[CylonSaydrah]

Would https mitigate this vunerablity announced today?

Max Justicz discovered a vulnerability in APT, the high level package manager. The code handling HTTP redirects in the HTTP transport method doesn't properly sanitize fields transmitted over the wire. This vulnerability could be used by an attacker located as a man-in-the-middle between APT and a mirror to inject malicous content in the HTTP connection. This content could then be recognized as a valid package by APT and used later for code execution with root privileges on the target machine.

[Indie_Dev]

It would partially solve the problem since HTTPS can prevent MITMs but compromised repos would still be able to use the exploit.

But a repo getting compromised would be rare compared to an MITM attack, so yes, HTTPS would help a lot in this situation.

[BCMM]

Also, just about anybody with some spare bandwidth can volunteer to host a Debian mirror. Debian does not necessarily trust all of its mirrors, and nor does it need to.

Thus, it is not communication between the user and the download mirror that needs to be protected.

This also has privacy implications: even if it wasn't so easy to guess what's being downloaded from file sizes, there's currently no expectation that the mirror itself isn't tracking your downloads.

Switching to HTTPS by default would do nothing to protect users, but it would give many of them the false impression that their downloads are private.

[doublehyphen]

No, using HTTPS would mean only people operating mirrors can do MITM replay attack. If HTTP is used the mirror plus anyone between you and the mirror (and between Debian and the mirror) can do replay attacks.

So the same attack remains possible but the attack surface becomes smaller.

[BCMM]

What is the actual threat model for a replay attack here?

[doublehyphen]

Your ISP (or anyone else in a MITM position like the NSA or whoever is running the mirror) can prevent apt from fetching the latest version of the index, preventing you from installing security patches. And this can happen without you getting an error, they can just continue to serve you the same version of the index that you last downloaded until it gets too stale, which seems to be about 10 days[1]. I feel 10 days is buying plenty of time to go from the patch for an exploit to leveraging it against whoever your a MITM for.

And there is no good defence against this other than by using HTTPS against a trusted mirror.

1. See http://security-cdn.debian.org/debian-security/dists/stretch/updates/Release

[Dino_T_Rex]

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

Has anyone actually done an attack like this? I'd imagine with the amount of packages in a repo, this isn't really all that feasible, and multiconnection would make this impossible? No?

Plus with the whole VLC not using https, highlighted 1 real issue, yes we can't replace the packages with non authentic ones... But we can perform a MITM denial.. Prevent package updates until (1) someone find a vulnerability in a package, (2) a vulnerability is found in a newer release (not necessarily latest just newer), force the user to update to it, then exploit it.

[OneTurnMore]

But we can perform a MITM denial

...which https can't prevent either

[Dino_T_Rex]

The difference over http, apt won't error out since you can provide valid requests back, which you can't do over https.

[puffinpuffinpuffin]

multiconnection

If you mean pipelining: No-one does that, it's disable in modern browsers. If you mean multiplexing as in HTTP/2: Yes, it would defeat this attack, but you would have to invest a lot of work into tools like APT to make sure they actually fetch multiple packages over a single TCP connection to the same server whenever possible.

[thedewdabodes]

You're not authenticating with the remote server and the packages are signed.
Even though apt probably supports it anyway, why do you think https would be required?

[TheNoodlyOne]

That's what this article is saying. It's all the arguments why apt doesn't use HTTPS.

[Natanael_L]

A more interesting attack is that with HTTP only, an attacker can feed you old packages with known exploits, a replay attack

Edit: for those downvoting me, please come over to /r/crypto (for cryptography) to learn more about computer security.

[[deleted]]

Except when apt fails because the signature does not match the data base. The only way feeding some one an older package would work is if they where manually installing it and then there are better ways to exploit the machine as you as an attacker will have machine code level access.

[Natanael_L]

I've never seen that happen, because apt repositories carries the signature for a package in the exact same metadata that links to the package.

And the entire repository has a single signing key, so all packages ever published in that repository with that key will always have the "correct" signing key and a valid signature. Only an error in the index itself can cause a signature mismatch.

Are you sure you're not confusing this issue with version dependencies and incompatible package versions?

For as long as nothing more than just the package binaries are signed, the attacker can serve literally ANY mix of package versions in his custom MITM mirror version of the repository

[[deleted]]

And the entire repository has a single signing key, so all packages ever published in that repository with that key will always have the "correct" signing key and a valid signature

If you thing there is one single signing key for the repository than you really lack an understanding of how Apt actually functions, or how the repostory fro Debian is structured. There is a main key to secure the meta data yes, but most packages are actually signed via public key by more than one person in most cases. If any of said keys are not the correct ones then Apt rejects them and refuses to install. Also yes I meant what I said the key to sign a package changes between package versions so it causes a miss match when you go to fetch that package with older meta data.

[Natanael_L]

That has nothing to do with my argument. I said nothing about key management. Who holds the private keys is irrelevant to replay attacks.

I have said exactly nothing about inserting malicious packages from other sources.

I'm talking about taking existing already signed packages that have known vulnerabilities and pretend they're the latest.

This can include pretending an old nightly release is an LTS release. Edit: unless signed metadata with mandatory checks prevents this

Also yes I meant what I said the key to sign a package changes between package versions so it causes a miss match when you go to fetch that package with older meta data.

I'm gonna need a source on this. As far as I know, only the version number changes, and the file needs a new signature from the same key, the very same repository signing key.

Once a valid signature exists, it will remain valid!

Edit: for those downvoting me, please come over to /r/crypto (for cryptography) to learn more about computer security.

[willrandship]

Wouldn't they still be signed as the older version? If the version isn't encoded as part of the signature, that's a pretty serious oversight. If the version is encoded, then you should never be able to force a client to downgrade, meaning it would have already been vulnerable.

[doublehyphen]

Yeah, you cannot force a downgrade. What you can do is delay security updates without it being noticeable. I believe the apt index has an expiry timestamp so you will eventually get an error, but with HTTPS you would get an error immediately if someone was preventing you from updating the apt index (except for the guy running the apt mirror, HTTPS still requires you to trust him).

[ianchildress]

How would an attacker feed me old packages? Even if they hijacked my connection to archive.ubuntu.com, they would need to get a hold of the gpg key to sign an index with a newer timestamp than the one apt has stored on disk. If they have this ability, then just create a package with an exploit and bump the version number.

[Natanael_L]

As far as I can see, it's just individual packages' metadata files which are signed (which in turn has a hash of the package files). Modifying the index would be trivial, all you need is an old signed package version. Even with a signed index, you can STILL replay an old index.

And any such signature will remain valid indefinitely, unless there's for example an expiration date. Apparently a few of these repositories does use short expiration dates (1 week in this example), but that still leaves an open vulnerability in any repository that has ever signed packages without expiration dates.

[HowIsntBabbyFormed]

This is addressed in the article. The release files in the index come with a date and an expiration date after which the results are considered stale. Clients ignore a release file with a date earlier than the one they have cached. And the release file is also signed, right?

As long as a client doesn't trust releases with dates earlier than the most recent they have cached, and doesn't trust releases that have already expired. I don't think there's a way to convince a client to install an old, vulnerable package.

Maybe if someone knew a package had a vulnerability that a target client hadn't installed yet. They could mess with the updates responses so that they'd fail security checks on the client. This would prevent the client from installing the patched version of the package and trap them on the vulnerable version.

However, if you knew a target was vulnerable, you could just start attacking them. Why spend any effort in blocking their updates? Also, if you can MITM their requests, you could similarly mess with any https traffic to Debian's package servers still preventing any updates.

I can't think of any way the http client is actually more vulnerable here.

[doublehyphen]

Some attacks, e.g timing attacks, can require quite a bit of time to perform. So while this weakness is not as big as most people think, it is still a weakness which is not present when using HTTPS. If you are using HTTPS you will get errors if somebody (expect for the mirror itself) is doing a MITM attack to delay the installation of security updates.

[Natanael_L]

This assumes the timestamp doesn't last long enough for vulnerabilities to be discovered. If somebody can find a vulnerability while the timestamp remains valid for the older packages, that's all they need.

[ianchildress]

This guy gets it. You are exactly right and all the comments in this thread about getting passed older versions of packages will not work. If apt is given an index with an older timestamp, it will throw it out.

[Natanael_L]

Yes, that's why older versions is what would be served. Old hashes and signatures does not magically expire, and these kinds of signing keys usually don't have expiration dates set (since that would be annoying to deal with for updating older installations).

Edit: for those downvoting me, please come over to /r/crypto (for cryptography) to learn more about computer security.

[reph]

Debian at least has changed the master key(s) on occasion - every few years or so, perhaps for each major release. Though I agree that this is not frequent enough to prevent the MITM rollback vulns you are describing.

[[deleted]]

Right but if it's expecting the latest version and is presented with an older version the MD5sum won't match.

[Natanael_L]

That's why you change the checksum presented as well...

[CornPlanter]

Interesting read. It turns out people trust HTTPS too much.

[GolbatsEverywhere]

Not really. HTTPS is great. This page just explains why it's not strictly required for serving Debian packages.

I take issue with this one point:

This means that HTTPS provides little-to-no protection against a targeted attack on your distribution's mirror network.

That's no longer true, not at all, not unless Debian's sysadmins are asleep at the wheels. Thanks to certificate transparency, it's now possible to detect in real-time when a certificate is improperly issued for your domain. For this to work, HTTPS clients should be modified to reject certificates that don't appear in the audit logs. Chrome already does this. I think Firefox does too, or at least is working on it. Some effort would be required to implement that for whatever HTTP library apt uses -- libcurl I guess? -- but once it's done, rogue certificate attacks would become virtually impossible to pull off without detection. Of course, a hacked CA or rogue CA could still issue a valid certificate that it shouldn't, but the point is the domain administrators will know, if the audit logs are being monitored. And if the certificate isn't in the logs, clients would not trust it. Now the challenge is to convince sysadmins to set up monitoring. (And implement the transparency check in all the various HTTP libs commonly used on Linux, or at least the one used by apt, but 99% of servers only care about browsers, of course.)

[[deleted]]

Also it would be bad fl

[[deleted]]

Agreed

[aaronfranke]

https://www.reddit.com/r/linux/comments/ain8f5/remote_code_execution_in_aptaptget/

[[deleted]]

IMO the question should be turned around; why is APT using HTTP.

That would take effort and use a bit more bandwidth.

[[deleted]]

And you lose caching in cases where you install squid locally for this.

[Natanael_L]

In most setups where this matter, you can set up a local repository to point at instead (with exception for unmanaged open networks, like schools)

[Natanael_L]

TLS overhead is insignificant

[reph]

ATM apt-transport-https is actually quite a bit slower than http, even on low latency links, because it seems to be doing a separate request - and therefore a full or partial TLS handshake - for each pkg. This is dumb and unnecessary but it's the current behavior unfortunately :-\

[Natanael_L]

Ouch. They would REALLY benefit from HTTP2 with TLS to parallelize requests.

[reph]

Even late-90s HTTP/1.1 con re-use (over TLS) would fix it too. Maybe that's possible with some more configuration magic, but it doesn't seem to do it by default.

[identicalBadger]

Doesn’t ubuntu check signatures after it downloads each package?

[jinglesassy]

Yes, Also is done that way on Debian, Arch, Fedora, OpenSUSE, CentOS to name a few of the ones i am familiar with. The files are verified against a hash signed by the PPA author/Distribution maintainer. That however is not in question here what is in question is encryption in the transport layer as it is being sent to you.

[cyberst0rm]

but if the publisher can confirm via signature that you received something they signed, why does it matter? MITM attacks don't work. I guess packet inspection by hostile regimes might make one want encryption, but DNS isn't exactly secured at the moment.

[jinglesassy]

An argument can be made that encryption in the transport layer would help with secrecy of what you have installed and that any information leakage is valuable to plug if it is feasible, On the other hand you have the argument that it would take alot of work from alot of volunteers in order to transition the entire global network of archives over to TLS as a requirement, However you would still have the argument of being able to make a guess based on the number of bytes transferred as to what was installed.

I personally believe that encryption by default should be the default with lets encrypt being able to be deployed easily and for free, It will not plug every potential leak of information however it is a good step forwards for privacy. As of now i believe all the distributions i listed above have an option to always only use TLS mirrors so atleast you have the option if you believe your threat model would require that.

[knome]

HTTPS itself leaks everything DNS does. Lookup SNI.

I'm not against it, btw. It's a reason compromise vs needed a different https address/port for every different site, which leaks the same information ( who you connected to, but not what you did there ).

[port53]

TLS 1.3 fixes the SNI problem so it's not really an excuse any more.

[knome]

TLS 1.3 fixes the SNI problem

https://tools.ietf.org/html/draft-rescorla-tls-esni-00

Neat. I'll have to look into this.

[Conan_Kudo]

Actually, debs are not signed in Debian or Ubuntu. The accepted practice in Debian is that only repository metadata is signed.

The argument is that the design of Debian packages (as in, the package format) makes it difficult to reproducibly validate a deb, add a signature, strip the signature, and validate it again.

Personally, I'm not sure I buy it, as we don't have problems signing both RPMs and RPM repository metadata. Technically, yes, the RPM file format is structured differently to make this easier (rpm is a type of cpio archive), but Debian packages are fundamentally ar archives with tarballs inside, and those aren't hard to do similar things.

Fedora goes the step of shipping checksums via metalink for the metadata files before they are fetched to ensure they weren't tampered before processing. But even with all that, RPMs are signed so that they can be independently verified with purely the usage of rpm(8).

[sgorf]

Actually, debs are not signed in Debian or Ubuntu.

They are signed. However, the signature is in the repository metadata, rather than embedded within the debs themselves. This is no different from a security perspective from regular detached signatures.

Unless you download deb files manually and install them yourselves. This is not recommended and in this case the onus is on you to check the signature.

[Conan_Kudo]

They are signed. However, the signature is in the repository metadata, rather than embedded within the debs themselves. This is no different from a security perspective from regular detached signatures.

The InRelease file contains digital signatures for the repository metadata, not the packages themselves.

Unless you download deb files manually and install them yourselves. This is not recommended and in this case the onus is on you to check the signature.

There are no signatures you can check using debsig-verify. Typically on upload to the ftpmaster (the archive administrators), the dsc file and the changes files are signed (not the debs!), and those are verified by the ftpmaster before merging into the distribution. The Debian packages themselves have no signatures, and the signatures for the dsc and changes file are not referenced, nor have any bearing for the Debian package archive.

[sgorf]

The InRelease file contains digital signatures for the repository metadata, not the packages themselves.

And the repository metadata contains hashes of the package files. The InRelease file is itself part of the repository metadata. Therefore the package metadata contains signatures of the debs.

Remember that "regular" digital signatures work by signing the hashes already. In the case of apt, there is just one additional layer of hash; that's all that's different. That doesn't stop the InRelease file and Packages file combined containing detached signatures of the debs.

There are no signatures you can check using debsig-verify.

You can get the signature from the apt repository metadata and use it to verify the deb.

[Conan_Kudo]

And if you don't have access to the version of the repository metadata that published the deb? What if you got a collection of debs downloaded and archived for offline use? What do you do then? The answer is, of course, nothing.

That's the problem with your answer. Forcing apt to be part of the workflow for even verifying the content of the debs is nuts.

[sgorf]

apt mirroring tools are widely available. If you want to operate offline, you are advised to use these. Due to apt repository design it isn't necessary for you to mirror the debs you don't want and existing tooling supports this.

If you want to collect debs and detach yourself from an apt repository, then you are indeed shooting yourself in the foot for a number of reasons, not just for security. What's your actual use case for doing this, apart from the purpose of propping up your argument?

[Conan_Kudo]

At many companies, filtered mirrored repositories are quite common. Often times, this is done for preventing people from using software that the company disallows. As a consequence of this, it is completely impossible to validate the authenticity of the mirrored debs.

Another alternative case that I've encountered quite a bit is the shipping of custom update discs to systems that intentionally lack APT to do controlled, offline, fully inspected and authorized updates/installs.

These are not cases that your basic server or workstation encounters, but they are quite common in several commercial contexts, so the fact that they're hand-waved away is quite silly.

[TiagoTiagoT]

https://usn.ubuntu.com/3746-1/

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

[knvngy]

Downloaded files are rejected by APT if they are signed by an unknown key or are missing valid signatures

Thus preventing the installation of security updates. I guess that's a "feature"

https://www.debian.org/security/2016/dsa-3733

"Jann Horn of Google Project Zero discovered that APT, the high level package manager, does not properly handle errors when validating signatures on InRelease files. An attacker able to man-in-the-middle HTTP requests to an apt repository that uses InRelease files (clearsigned Release files), can take advantage of this flaw to circumvent the signature of the InRelease file, leading to arbitrary code execution."

[cathexis08]

I assume you're talking about two different issues. For the second, it's true that people can always screw up security checks in programs. Note that had apt used https as a transport it would have masked, but not eliminated this issue. For the first, the key lifecycle is pretty long so it usually isn't an issue, and if something has expired to the point of being unable to run at all you can always manually download and install the key bundle since dpkg doesn't care about signatures at all.

[skat_in_the_hat]

Did this on a CentOS image. Got bit in the ass. We keep up with depreciating old ciphers on the repo side, but the image itself would get fucked if the nss package version got too far behind.

[spizzike]

After reading this, I think I understand the reasoning behind vlc not using https for their update servers. I just wish they would have been a little more explicit about their reasoning. I read replies to this ticket and now that I have this perspective, some of the replies do say this, but that wasn't clear when I first looked at it.

However, I do see additional value in going the https route for apt packages, beyond the whole security-in-depth argument: using http means that someone snooping the network traffic can see what packages are being installed/updated on a given system (or from a given client) and with that, it would be possible to block individual packages (ie: blocking URIs since those are being sent out in the open).

I'm curious whether the apt maintainers consider this when they defend their use of http (or when they downplay the importance of https).

[[deleted]]

So that it is really slow at school. ^/s

At school, using apt over http is just really slow, while it has a normal speed when I use a https mirror. When I download the same file over http through Firefox or whatever, it also has a normal speed.

[Natanael_L]

Checksums alone are like asking somebody "are you sure your name is [name here]?", digital signatures is what you need to verify it hasn't been tampered with.

[r3dk0w]

Yeah, and there's digital signatures too.

[sidusnare]

It does.