Why does APT not use HTTPS?
388 comments · 92% upvoted · source · other discussions
comments
amountofcatamounts
DJTheLQ
Everyone is missing a huge plus of HTTP: Caching proxies that save their donated bandwidth. Especially ones run by ISPs. Using less bandwidth means more willing free mirrors. And as the article says, also helps those in remote parts of the world.
If you have bandwidth to run an uncachable global HTTPS mirror network for free, then debian and ubuntu would love to talk to you.
[deleted]
Caching proxies that save their donated bandwidth. Especially ones run by ISPs.
As a former ISP owner I can tell you that caching large files is not really that common and filtering for content-type usually would be limited to images, text etc.
Also most caching is done by a third parts (akami etc) and you have little control over the boxes.
I'm sure its done, but not common. Mirrors are a thing for a reason.
lbft
It's done in places where bandwidth is very expensive and/or restricted (e.g. if there's only one cable out of the country/region, or a monopoly/state telco sits between ISPs and the wider internet).
I can certainly remember in the dial-up and early broadband eras that lots of ISPs here in Australia had transparent or manually set proxy servers (usually running Squid), and that was with a lot of them also locally hosting Akamai caches and FTP mirror servers.
Pantsman0
http://mirror.internode.on.net/... the memories...
SippieCup
Its 100% this, I have no idea why no one is talking about it. Maybe they didnt get to the end of the page.
atyon
Caching proxies
I wonder how much bandwidth is really saved with them. I can see a good hit rate in organisations that use a lot of Debian-based distros, but in remote parts of the world? Will there be enough users on the specific version of a distribution to keep packages in the cache?
zebediah49
It's actually more likely in situations like that. The primary setup is probably going to be done by a technical charity, who (if they're any good) will provide a uniform setup and cache scheme. That way, if, say, a school gets 20 laptops, updating them all, or installing a new piece of software, will not consume more of the extremely limited bandwidth available than doing one.
rmxz
I wonder how much bandwidth is really saved with them.
A lot in my home network.
I put a caching proxy at the edge of my home network (with intentionally hacked cache retention rules) when my kids were young and repeatedly watched the same videos.
I think I have 5 linux computers here (2 on my desk, 2 laptops, 1 living room).
So my proxy caching http and https saved apt repos about 80% of my home network traffic.
SanityInAnarchy
How about an uncachable global HTTPS mirror of just the package lists? It'd be nice for a MITM to not be able to, say, prevent you from getting updates while they read the changelogs of said updates looking for vulnerabilities.
And, how many transparent HTTP caches are out there? Because if this is mostly stuff like Akamai or CloudFlare, HTTPS works with those, if you trust them.
Edit: Interesting, apparently APT actually does include some protection against replay attacks.
I still think that making "what packages are they updating" a Hard Problem (using HTTPS pipelining) would be worth it, unless there really are a ton of transparent HTTP proxies in use that can't trivially be replaced by HTTPS ones.
CODESIGN2
there is a package on debian and ubuntu for those that want to use HTTPS
lamby [OP]
"Why does APT not use HTTP... [by default]" is probably not as snappy.
FYI in Debian unstable/testing, this package is actually deprecated as APT itself supports HTTPS.
[deleted]
djmattyg007
The apt-transport-https package just lets you use HTTPS repo URLs. It doesn't automatically switch.over your configured mirror URLs to HTTPS versions when you install it.
asoka_maurya
I was always intrigued about the same thing. The logic that I've heard on this sub is that all the packages are signed by the ubuntu devs anyway, so in case they are tampered en-route, they won't be accepted as the checksums won't match, HTTPS or not.
If this were indeed true and there are no security implications, then simple HTTP should be preferred as no encryption means low bandwidth consumption too. As Ubuntu package repositories are hosted on donated resources in many countries, the low bandwidth and cheaper option should be opted me thinks.
dnkndnts
I don't like this argument. It still means the ISP and everyone else in the middle can observe what packages you're using.
There really is no good reason not to use HTTPS.
obrienmustsuffer
There really is no good reason not to use HTTPS.
There's a very good reason, and it's called "caching". HTTP is trivial to cache in a proxy server, while HTTPS on the other hand is pretty much impossible to cache. In large networks with several hundred (BYOD) computers, software that downloads big updates over HTTPS will be the bane of your existence because it wastes so. much. bandwidth that could easily be cached away if only more software developers were as clever as the APT developers.
BlueZarex
All the large places I have worked with a significant Linux presence would always have a mirror onsite.
kellyzdude
- The benefits don't apply exclusively to businesses, a home user or an ISP can run a transparent caching proxy server just as easily.
- By using a caching proxy, I run one service that can help just about everyone on my network with relatively minimal ongoing config. If I run a mirror, I have to ensure the relevant users are configured to use it, I have to keep it updated, and I have to ensure that I am mirroring all of the repositories that are required. And even then, my benefits are only realized with OS packages whilst a caching proxy can help (or hinder) nearly any non-encrypted web traffic.
- If my goal is to keep internet bandwidth usage minimal, then a caching proxy is ideal. It will only grab packages that are requested by a user, whereas mirrors in general will need to download significant portions of a repository on a regular basis, whether the packages are used inside the network or not.
There are plenty of good reasons to run a local mirror, but depending on your use case it may not be the best choice in trying to solve the problem.
EternityForest
Or if GPG signing was a core part of HTTP, then everything that you don't need privacy for could be cached like that without letting the cache tamper with stuff.
archlich
Google is attempting to add that with signed origin responses.
ign1fy
Yep. You're publically disclosing to your ISP (and, in my case, government) that certain IP endpoints are running certain versions of certain packages.
[deleted]
[deleted]
asoka_maurya
A small nitpick, but I think fedora's yum/dnf might have an edge here as they send only the delta (changed portion) and not the entire package file. And the delta might be of different size for each user depending on their configuration.
albertowtf
Well, its about layers
Why change the ssh port?, bots only have to change the port -> my server stopped being hammered by ssh bots. Didnt even need to bother to set up a knock
Why add a silly homemade captcha to the form in my webpage? any bot will easily break it --> I stopped receiving spam forms
Nobody cares enough about my stuff to break it i guess, but it has his uses
[deleted]
While that is true. But with non encrypted traffic you know the person downloaded a specific package. But with data transferes you know they only downloaded a package of size X. Of which there could be several since there will also be deviation in the size of the headers etc... Also it could be fuzzed in the response eg add a random set of headers X bytes long or rounding them up to a specific size. example all packages < 512KB become 512KB in size thus making this information useless.
[deleted]
[deleted]
thijser2
It would however take more effort to do this and I think you are underestimating how often there are dozens of different versions of the same package with nearly the same size. A little bit of fuzzing/padding there can result in at least our eavesdrop not knowing which version you have.
tehdog
How is that supposed to work if I'm downloading updates to 20 packages all over the same TCP / TLS connection? Sure you can figure it out somewhat, but I doubt you can get even close to 100% accuracy with a lot more work than you can get trivially without encryption. Especially when using HTTP/2, which uses multiplexing.
asoka_maurya
Sure, it could be a nightmare from privacy perspective in some cases.
For example, if your ISP figures out that your IP has been installing and updating "nerdy" software like Tor and Bittorrent clients, crypto currency wallets, etc. lately and then hands your info to the government authorities on that basis, the implications are severe. Especially if you are in a communist regime like China or Korea, such a scenario is quite plausible. Consider what happened with S. Korean bitcoin exchanges yesterday?
[deleted]
This is not as far-fetched as it seems. I know of a particular university that prevents you from downloading such software packages on their network (including Linux packages) by checking for words like "VPN", "Tor", "Torrent" and the file extension. If a university could set up their network this way, then governments could too.
ImSoCabbage
It still means the ISP and everyone else in the middle can observe what packages you're using.
That's the second chapter of the article
But what about privacy?
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.
beefsack
Did you read the page? This specific example is covered; if you're eavesdropping you can tell which packages people are downloading anyway via transfer size.
entw
I don't like this argument. It means you are still relying on untrusted potentially evil ISP instead of switching to more trusted one.
Look, if your ISP is so evil and can use against you information about your packages, then what can it do with the info about your visited hosts? Think about it.
RaptorXP
First, you shouldn't have to trust your ISP. Second, your IP packets are routed through many parties you have no control over. If you're in China, it doesn't matter which ISP you're using, your packets will go through the government's filters.
dnkndnts
Sure, and I could say the same about closed hardware, but the bottom line is sometimes we have no actual choice in the matter, and in that case, we just make the best of what we can.
I'm not going to let the perfect be the enemy of the good (or even the less bad), so if this is an improvement that's within our grasp, let's go for it.
lamby [OP]
The logic that I've heard on this sub is that all the packages are signed by the ubuntu devs anyway, so in case they are tampered en-route, they won't be accepted as the checksums won't match, HTTPS or not.
This is hopefully what the linked page describes.
UselessBread
Nullius_In_Verba_
Why are you focusing on Ubuntu when this is an Apt-get article. Is related to ALL apt users....
lovestruckluna
Personally, my chief argument for keeping http is secure and easy support for caching proxies. I use Docker and VMs a lot, and often end up retweaking install scripts and downloading the same package many times. With HTTP, I can speed build times on my local network by pointing the domain names of some of the default servers to a local caching proxy in local DNS, while having it still work when it leaves my network. Couldn't do that with HTTPS without changing sources.list, and breaking updates outside of my env.
A niche case, for sure, but there are definitely use cases for verifying an not-totally-trusted mirror or cache (I would feel much safer if CDNs/Cloudflare were guaranteed to only successfully pass content presigned by me rather than only relying on the security of the transport and the promise they won't be hacked).
globalvarsonly
Also, most mirrors are volunteers and shouldn't be fully trusted. HTTPS will secure your connection to the mirror, but you need to verify the signature/checksum with the project, not the mirror.
Also, I don't know what this "most people don't check" thing is. Most people use apt-get or some frontend on top of it, which automatically checks the sigs.
And not trusting the root CAs is actually better, if a little more work. This prevents someone (probably a state actor, e.g. China) from using a MITM attack to compromise debian based systems. Instead of trusting Verisign or some 3rd party, Debian only trusts Debian.
Also, the caching argument came up in here. It probably isn't done much at the ISP level, but I can tell you its huge on hobby networks, colleges, and places that run tons of virtual machines. Anybody with a lot of similar systems to update will want to run something like apt-cacher-ng. I desperately want something similar for steam updates on my LAN.
__konrad
trusted keys already stored on your computer
Too bad that many iso downloads are transfered via "http" w/o checksum/signature verification ;) For example, Ubuntu download page is encrypted which gives you an illusion of security, but the actual mirror service may be unencrypted.
physix4
Things like this can happen even with HTTPS enabled everywhere.
[deleted]
[deleted]
[deleted]
Locks can be broken, so why bother at all? This is such a stupid argument. HTTPS makes it more difficult to see what you are doing. Of course it’s not perfect, nothing is. That’s not a valid reason for not doing it at all.
That depends. If a 'security measure' is trivially circumvented it may be better to not use it at all, because it also has a downside: users may think they are protected from a threat, when in fact they are not at all. It is not black and white.
audioen
It would be very difficult to determine exactly what you download based on the transfer size if, keepalive is used. Observer may then see the total size of the transfer, which includes several files, but would have to guess which individual packages would plausibly sum together to the observed size.
BlueZarex
I may have missed it, but where is the example of https being circumvented? I haven't seen such an examples given besides "file transfer size can be detected", but that is not the only reason to to use https.
Https prevents mitm. It also increases the "work" an attacker has to perform in order to get results.
In a non-https setup, they simple have to read..."apt get vim torbrowser emacs" and perform mitm at their leisure
In an https setup they have to go through more work and can't mitm. They can no longer simply read "apt get vim torbrowser emacs" but would have to perform some math to figure out all the packages that could possibly be combined to equal "47MB" of transfer and that might be "vim torbrowser and emacs, or it could be "wireshark, openVPN and vim". They have no way of knowing without performing calculations after the fact and again, also lose their ability to mitm.
Realize, much of security is in fact, increasing the work and difficulty to exploit. If we say its useless in this case, we might as well say its useless in all cases which would drastically reduce security overall. Imagine a scenario where we say that since transfer speeds can be used to figure out what people are downloading from https websites, we might as well not use https for anything but protecting logins.
lamby [OP]
audioen
APT should actually use https. Even insignificant traffic should be encrypted, if for no other reason than that it helps drowning actually privacy-sensitive stuff in the noise.
boli99
I'm glad that it doesn't - it allows me to transparent proxy and cache updates for other machines on my networks.
jfedor
It all seems like a poor excuse.
What if there's a bug in APT that allows code execution with a malicious package specially crafted by the attacker (even if the package is not correctly signed because let's say the bug in in the verification code)? HTTPS mitigates that because now the attacker can't MITM his package into my connection.
RoyMooreOfficial
The actual argument as to why APT doesn't use HTTPS is at the bottom when it should be at the top...
"A switch to HTTPS would also mean you could not take advantage of local proxy servers for speeding up access and would additionally prohibit many kinds of peer-to-peer mirroring where files are stored on servers not controlled directly by your distribution. This would disproportionately affect users in remote locales. "
Pretty much everything before that doesn't directly address the question. I mean, it's still good info, but still
KayRice
If APT mirrors were HTTPS my cloud provider wouldn't be able to cache them and provide (apparent) 1GB/s download speeds to me. Also if HTTPS was used they would have to have a throw-away certificate they shared with all the mirrors.
radarsat1
What I'd like to know is, "why does APT not use bittorrent?"
londons_explorer
APT failing to use HTTPS is a privacy issue. It means an attacker can see which packages I have on my machine by keeping track of which packages I download.
Knowing a list of every installed package is rather good for breaking into a machine...
fragab
Also one practical issue I ran into: If you don't have the package with the CA certificates installed, the download will fail and you have to figure out how to convince apt to continue if it can't verify the certificates.
muungwana
Their argument is like below:
Why bother encrypting traffic to those websites with lots and lots and lots of videos? everybody who cares to know can easily know you are visiting those sites and nobody cares what types of videos you like to watch while there.
Very strange position they have. They should just come clean and say it,using https is too expensive and they cant afford it.
dotwaffle
They should just come clean and say it,using https is too expensive and they cant afford it.
HTTPS provides no real benefit in this application. As the package files are signed with a PGP key, you're not guaranteeing any more authenticity by using HTTPS.
All you are doing is applying encryption to the mix, which isn't helpful -- you can usually tell by the size of the transfer which file(s) were transferred, you can get the hostname from the SNI, and you are then having to rely on the donated mirror network keeping keys up to date: because no-one ever lets keys expire, right?
There is a difference between authentication and encryption. Debian is doing "the right thing" and making sure that what is delivered is authentic, through the use of PGP signatures, and through the use of "Valid-Until" in the release files themselves to prevent stale caching.
ceeant
Exactly, their argument is based on the assumption that all packages are equal. They are not. If I were to live under an oppressive regime, that regime may be very interested in the packages I'm installing. GPG? Oh he has something to hide. nmap? He must be a criminal hacker.
I am not saying that encrypting the traffic to apt repos would be enough to ensure privacy, but not having encryption at all is a loss.
lo0loopback
As others mentioned, they are hashed and verified. Donated mirrors already provide a ton of bandwidth already. It would require mirrors to upgrade their mirrors to handle the same volume. Its not just additional traffic but CPU usage. Im in for encryption but dont see it as a hard default requirement yet. If you have space and its easy to run your local mirror or use https opt in
r3dk0w
Https is very difficult to proxy. Http proxies are easy and in use at most isps.
Most isps also use a transparent proxy so apt using http would greatly reduce the network bandwidth between the ISP and the apt source host.
[deleted]
Going HTTPS would be a tiny and mostly meaningless step. I'd be more interested in why we are still stuck on HTTP to begin with. Why not Bittorrent? Why not Freenet, IPFS, rsync, git-annex or whatever? The way Free Software is distributed has felt very antiquated for a quite while and made it unnecessarily difficult to contribute resources. We are also still lacking in basic features such as incremental upgrades, multi-version, user-installs installs and so on. Apt is really showing its age.
nschubach
The BitTorrent angle was approached a few years back. It would actually make your machine vulnerable to attack because all the attacker would have to do is get a client on the trackers hosting the update files and they get a list of all machines requesting those updates. If you have a zero day exploit, being on that tracker could give you a valid list of ips that are vulnerable to the fix they are downloading. Act quick enough and you could hack the machine before the patch is applied.
LordTyrius
Some mirros use https don't they? This is about apt, but the general idea should be the same (manjaro user here). pacman-mirrors lets me prefer/select only https mirrors (https://wiki.manjaro.org/index.php?title=Pacman-mirrors#Use_specific_protocols_.28prioritized.29).
This is true for packages... the reason as they say is your install already has trusted keys it can use to confirm the signer of the packages is trusted and that they still match the signed digest.
But for OS downloads... Canonical... most people do not check the hashes of their download before installing it. For that case, TLS does help at least reduce the chance that you are looking at an attacker's website with hashes matching a tampered download.
lamby [OP] 132 points · Jan 2018 · :debian:
Indeed, and note it's not enough to check the SHA512 matches what the website claims - that is only checking the integrity of the file; it is not checking that the file is from Canonical.
I mean, if someone could swap the ISO out they could almost certainly swap the checksum alongside it!
CODESIGN2 22 points · Jan 2018
Isn't it a signed checksum using a private key chain that would not be available to the "snoop" though?
lamby [OP] 46 points · Jan 2018 · :debian:
Yes, but this is the bit that people do not check; either they don't run
gpgat all, or they simply trust the stated signature is the one they used before or is part of the web of trust.CODESIGN2 20 points · Jan 2018
I think it's mostly that they don't care.
jones_supa 58 points · Jan 2018 · :linux:
I think many people do care, but when they read about a complicated GPG dance to perform the verification, many will cringe and say "meh, it's probably fine".
A checksum is just
sha1sum filename.isoand then compare the result to the checksum on the website. Even though this is a less secure method, the bar to perform it is much lower.CODESIGN2 4 points · Jan 2018
I don't know that I'm advocating for sha1sum, but yeah the gpg tools could be easier to work with. Even defaulting to perform checks for you and marking somewhere on fs that the user has been irresponsible would be nice. (Mark it like a manufacturer warranty void. Skipped the check? Fuck you pay!)
lamby [OP] 10 points · Jan 2018 · :debian:
Sure.
CODESIGN2 11 points · Jan 2018
I wasn't trying to dismiss your point. It doesn't mean there is nothing that can be done, just that it needs to be automated and built into the systems allowing acceptance of packages, not deferred to the end-user.
lamby [OP] 14 points · Jan 2018 · :debian:
I didn't feel dismissed - it was more that we seemed to be 100% agreeing with each other :)
load 4 more replies →
Nullius_In_Verba_ 12 points · Jan 2018
Why are you two focusing on Canonical for your example? This applies to all distro's. Fedora, Suse, Debian, all included. In fact, a websites security being the weakest link is well known, including a real life example that happened to Linux Mint.
[deleted] 10 points · Jan 2018
Did you verify that before you said it? Debian transfers the ISO to me via HTTPS not HTTP, I'm not as familiar with the others.
load 11 more replies →
load 3 more replies →
masterpi 5 points · Jan 2018
If the website is HTTPS with a Canonical cert, then it is checking that either the file is from Canonical or the website has been hacked, which is as good as you'd get if the download itself were HTTPS.
load 6 more replies →
load 10 more replies →
load 1 more replies →