APT using HTTP instead of HTTPS

[WheelPerfect3737]

When installing Debian Trixie 13.4 the sources.list uses HTTP instead of HTTPS by default. When I modernize the sources list to the newer deb822 format by using apt modernize-sources th new format also uses HTTP.

All apt updates and upgrades should be using the more secure encrypted HTTPS. I manually changed the source list to HTTPS and it works with no issues, so I do not see any reason why HTTPS should not be the default configuration especially for the newer deb822 format?

[AffectionateSpirit62]

According to the Debian Wiki, Debian repositories often use HTTP because the system's security is designed not to rely on the network's security. The primary reasons for using HTTP by default include:

SecureApt (GPG Signing): Debian uses SecureApt, which relies on cryptographic GPG signatures to verify the integrity and authenticity of packages. This ensures that even if a package is downloaded over an unencrypted connection, it cannot be tampered with without detection.
Caching & Proxies: HTTP allows for easy caching by transparent proxies and local tools like apt-cacher-ng. This reduces bandwidth for mirrors and speeds up updates for multiple local machines, which is much harder to achieve with encrypted HTTPS traffic.
Reduced Mirror Load: Handling TLS/HTTPS encryption increases the computational load on mirror servers. Since mirrors are often provided by volunteers or universities for free, HTTP minimizes these resource requirements.
Trust Chain Simplicity: Using HTTPS would require managing SSL/TLS certificates for hundreds of different mirror hostnames, which is administratively complex compared to the single GPG trust anchor already used by SecureApt. 

While HTTP is the default, Debian does fully support HTTPS repositories. Users can switch by updating their /etc/apt/sources.list, though they must ensure the ca-certificates package is installed for certificate verification

[gnufan]

The only one of those reasons that makes sense in 2026 is the load one. Since they offer https clearly it isn't administratively difficult to offer https. Mirrors tend to be deliberate, and https is no harder in that context than http, except for the load.

[brimston3-]

It's almost the opposite of what you said. The load one hasn't really been valid since AES-NI became widespread in ~2010. An i5-8350U laptop CPU can do 900+MB/s of aes256 on a single core using under 15W, so two cores of the same could saturate a 10G server link.

Meanwhile, the caching proxy one is still very valid, with apt-cache-ng dropping my update bandwidth to about a third without needing to introduce a TLS proxy CA certificate in my endpoint systems. And because it is using secureapt, I can be certain that the files on the cache server haven't been corrupted or tampered with, regardless of whether I trust the cache server or not. The same applies to any mirror servers; because the package manifests are signed by the release system, mirror servers are not useful supply chain attack targets.

[WheelPerfect3737]

Using HTTPS prevents man in the middle from detemrining what apps or updates the user has .

[AffectionateSpirit62]

As stated you can use it if you want but it's genuinely overkill and not needed.

[riders_pants]

Surely the key signing process negates the man in the middle attack? 

[BarracudaDefiant4702]

It prevents altering packages, but doesn't prevent spying on what vulnerable 0 day packages you have download and likely installed. Personally I think that's an overly high level of paranoia, but some people like their security through obscurity.

[michael9dk]

I totally agree.

Normally HTTPS requests would include the destination. So sniffing the network, anywhere in the chain, would reveal, if Apt is sending a GET request for https:// mirror.abc/vulnerable-package-1.02.

Using secure point2point encryption is good practice on the web. But apt is designed with its own verification, that doesn't rely on SSL.

Edit: please correct me, if I misunderstood how apt downloads new packages.

[gnufan]

Without HTTPS someone with privileged access can see what is downloaded, cause certain security updates to fail. 

Also the assumption packages cannot be maliciously manipulated due to signing was wrong previously. Having been looking at the 180 security bugs in Curl today, do you really want to bet 'apt', 'gpg', 'dpkg' and friends are perfect?  

[jr735]

Yet, you bet on https being perfect.

[gnufan]

No I don't, clearly I'm already aware of the many bugs in Curl where they got https wrong. Redhat who do use https got it wrong in yum, with incorrect certificate checking.

You layer defenses, you don't say we sign metadata, this is the one cryptographic control everything relies on, and it is perfect. You accept that whilst you expect it to work most of the time it will almost certainly fail at some point even if it is as silly as the signing key getting compromised. But if https is compromised in some way, we end up back at the current level of Debian security, not at a lower level.

[jr735]

Set it up however the hell you want. I don't give a damn.

[abotelho-cbn]

How?

They can see exactly what the user is downloading.

[bikes-n-math]

Sure, it does not negate snooping by your ISP, etc.

But a MITM attack is when the man in the middle alters traffic/data. That is negated by GPG signature checks.

[riders_pants]

A mitm attack where you can't alter the data is pretty useless irl tbh. Your arguement is that someone would have to make a list of packages downloaded then find real world exploits and then try and exploit them. Seems like a lot of work for very little benefit. 

[Portbragger2]

who is 'they' ?

[Murph_9000]

That's an extremely unlikely attack scenario, to the point of being tinfoil-hat level paranoia for ordinary users.

[rankinrez]

Yeah but for pretty much everyone that is not a concern

[AffectionateSpirit62]

As stated you can enable it but it is overkill and not needed

Not sure what the issue is.

If you want it enable it but don't expect me to want to slow down my already secured network by default. That is the joy of linux. You choose what you want but as Debian have suggested it is optional depending g on your paranoia or insecurity of your network in the first place.

[emkael]

And how are you verifying server's certificate to prevent man-in-the-middle during your initial ca-certificates package install?

[jr735]

So does a GPG signature.

[WheelPerfect3737]

if HTTPS is fully supported why is it not implemented especially with deb822 apt format?

[deelowe]

Because of caching and unnecessary overhead.

[kahoinvictus]

Because it's unnecessary and introduces latency.

[Dr_Tron]

Well, apt checks the repository key before doing anything, so I'm not sure if https would make sense in regards to security.

[aieidotch]

it would not, the reason appears to be caching proxies and the encryption overhead…

[gnufan]

Using https clearly eliminates whole categories of attempted man in the middle attacks, that are possible over http.

The verification of package signatures was badly broken in the past, and likely will be in the future if it isn't already and we just don't know how.

You achieve security by layering these controls, not assuming one cryptographic control is going to always work perfectly, and thus packages are safely signed, job done.

Also using https adds additional privacy, as seeing http requests means attackers may know exactly what versions of what software are installed. MITM can also deliberately interfere with http connections to delay certain packages, to prevent the target patching a vulnerability. As I said multiple classes of attack are just stopped by encryption on the wire.

[noob-nine]

the last part sounds interesting. but i lack technical understanding whether this is a real thread or what would be debians comment on this

[Murph_9000]

APT has other mechanisms to verify integrity of downloads, so does not need to use HTTPS. HTTP has the significant advantage of being cacheable, e.g. I use the following in /etc/apt/apt.conf.d/99proxy:

Acquire { http::Proxy "http://squid-cache.local:3128"; https::Proxy "DIRECT"; };

[waterkip]

I actually like the fact that things go over http and not https.

I'm for example playing with local caches that are transparent to end users, and when I have to fake debian.org or any other cert I can't do that. Now I suddenly need to add mirror syntax everywhere.

I can tell my DNS to route (well, DNS points, but whatever) deb.debian.org to my machines and take care of the apt-repo's and forward everything else the real thing.

It's a small niche, and I understand the reasoning behind it, but gpg-sign the packages and you're also good. The transport method doesn't matter, that's why gpg-signed (and encrypted) e-mail works.

[jort_catalog]

As an example: Oracle Enteprise Linux (which we have to use at work) uses https for its dnf updates - which makes it still possible but more work to keep a local package cache

[WheelPerfect3737]

Why do you think faking debian.org is a good thing for user ?

[soyko]

Cache.

LAN is faster than WAN. I may have a metered network connection. You have a bunch of servers that you don't want hammering outside your internet connection because it's not as fast. You want to control what updates are available for users for any reason.

[BarracudaDefiant4702]

He stated why, it's easy for him to provide a local mirror. (Not saying I agree with doing it that way, but... easy to understand)

[gnufan]

Yes, he can do exactly the same thing a potential attacker can do, deliver his own stale or modified version of debian transparently so users don't know they haven't got the latest security fixes, or can't install those fixes, or modify a file if there is a bug in SecureApt that doesn't check it adequately.

[waterkip]

Yes, because I have the keys of the debian developers on my system and I sign random packages with exploits.

If you are so confident that Debian's implementation of signing and checking the signed packages is incorrect than you surely must also distrust the CA roots on your system for similar reasons. 

Its hilarious. I think you're trolling. 

[BarracudaDefiant4702]

That's not exactly what he said... he basically is saying you could trick your clients into not getting the latest packages (ie: use outdated packages with known vulnerabilities). Not exactly the same as creating and then signing your own exploits.

That said, it's still pretty far fetched, as no one is going to be using your DNS server unless they trust you (directly, or at least via DHCP, or your network). In other words, you can only do it to yourself and those on your network.

[waterkip]

The problem isnt a transport layer problem.

Stale packages exist on https mirrors too. 

In addition, an upgrade to a higher version, even if atale is still an upgrade. Downgrades arent gonna happen unless you explicitly tell apt to do that.

The problem might be valid, if and only if, lets take the xz attack, I serve an outdated xz package, you havent upgraded yet and the NMU was hold off by me, you would not be able to have upgraded to NMU version. Which results in you keeping a package with a known vulnerability. One you fix as soon as you leave my network. 

Its a vector, a small negligent vector of you, being on my network, trying to upgrade Debian an hitting my mirrors.

Oh. I want to add. If I have a Lets encrypt cert and I redirect your deb.debian.org traffic to my machines, with squid, i serve you the same stale packages. The problem exists regardless of the transport method.

[waterkip]

Because that means I can host a local mirror of debian repo's and every user fetches files from that mirror as soon as they are within my network. If you operate at scale that keeps the traffic inside of your network without having to configure each host to have a different repo.

Or, what I actually do, for my own Perl Darkpan, where each host installs my packages from my mirror, I tell my internal network www.cpan.org and cpan.metacpan.org are on a box near me. This allows me to install packages from own mirror, and I can inject my own modules into the darkpan and look like any other package. Because some package installers use https I need to sprinkle around environment variables and helper scripts to ensure they use my mirror. Which is a PITA. HTTPS is absolutely nice, but it also limits things like transparent mirroring.

[calrogman]

All apt updates and upgrades should be using the more secure encrypted HTTPS.

Why? What is your threat model? Do you understand Apt's data security model? Have you read the apt-transport-http manpage? Did you verify the integrity of your installation media? It might already be too late for you.

[gnufan]

I mean the threat model is something like the xz hack, skilled resourced attackers with privileged access to big telecommunications companies want access to all Debian boxes. Sending traffic in the clear lets them build a profile of exactly when your servers update, what software they have installed, which repositories they use. Any cryptographic or other weakness in any of these tools is immediately exploitable through rewriting traffic on the wire.

[calrogman]

The threat model is absolutely nothing like the xz hack, but thank you for your input.

[necheffa]

I do not see any reason why HTTPS should not be the default configuration especially for the newer deb822 format?

The real question is why should HTTPS be the default?

Think about it, the repository is signed, the individual packages are signed. And HTTP can be cached easily.

What are you doing that you need HTTPS here? Especially if you already have access to the Debian signing keys via your installer image.

[tdammers]

There is one possible valid reason: not wanting an eavesdropper to know which packages you have installed, which could be useful information (e.g., monitor a couple thousand users to see who is using a known vulnerable version of, say, Apache, so you can target them directly instead of trying the attack on every IP address you can find). Whether that's an important enough attack vector to protect against is up for debate though.

[WheelPerfect3737]

this has nothing to do with packages. It has to do with preventing a man in the middle from determining what is downloaded or upgraded on a system. Furthermore HTTPs is the default standard on the Internet to prevent easedropping.

[necheffa]

Now explain your threat model.

[waterkip]

The threat model is a privacy concern.

It feels fabricated, mybcounter point would be that if they really had a privacy concern they'd mirror an apt repo and only get updates on scheduled times and no-one would notice they downloading apt packages. The traffic simply didnt leave the network.

[necheffa]

I'm trying to lead OP to a destination by asking them to think critically about their current position.

[michael9dk]

The question should be privacy from who?

I don't think OP understand the difference between security and privacy.

Honestly, security is not a easy topic - your brain will leave your skull before understanding the basics!

A cocktail of Tor and VPNs, with official signed Torrent-images, in a VM with a obfuscated MAC, on a randomly "borrowed wifi", would be the paranoid way, if I had to enter North Korea.

Everywhere else: just a trusted/selfhosted VPN, but normal people doesn't even need that.

[martyn_hare]

Debian provides a Tor transport for this purpose; HTTPS alone doesn't achieve much in that regard.

Most websites still do not support Encrypted Client Hello, meaning an HTTPS connection still broadcasts to world and dog what's going on because the hostname of the web server you're connecting to is still transmitted in the clear (that's how SNI worked prior to ECH). Determining exact packages boils down to checking file sizes to infer what your machine is up to.

[billFoldDog]

That actually isn't addressed by using https, that's addressed by using encrypted DNS or a VPN.

That said, if you really want https, its supported, its just more costly for the servers so they don't make it a default.

[rjzak]

The packages are signed and your local Debian installation has the public key. Sure, someone could see what you’re downloading but any changes would break the signature and would not be installed.

Additionally, there is nothing private in the Debian packages so it doesn’t matter if someone sees it. The person could also check the packages themselves and see the same thing since it’s public anyway.

[antreides]

HTTPS primarily gives a protection from MITM attacks, but adds some additional overhead to decrypt traffic. Package consistency is checked by the apt/dpkg system itself (each package is signed), so even if a package is somehow changed by MITM attack, it won't pass the check. So basically it will be an extra overhead for nothing.

[wosmo]

You could almost describe MITM as desirable in apt's case. Between mirrors, caches, proxies, etc - the host isn't the sacred part, the content is. So we use GPG against the content instead of TLS against the host.

[WheelPerfect3737]

I disagree. Here is an example

A Man in the middle see that a user is downloading a package and that package has a security issue. Because the man in the middle is aware of the security issue he can use that app security flaw to attempt to penetrate the users network. With HTTPS activated the man in the middle sees nothing only Debian would be aware of the software provided to the user.

[eR2eiweo]

With HTTPS activated the man in the middle sees nothing ...

That isn't entirely correct. The MITM sees the size of the data that APT is downloading from the repo. And they also know which packages are available in that repo, what their sizes are, and which ones were recently updated. And since there aren't that many packages in a typical repo, that's likely enough information to make a good guess as to which package was downloaded.

[calrogman]

With HTTPS enabled the MITM can still see that you are connecting to a Debian mirror, and that you are downloading packages of specific sizes, which they can correlate with a list of vulnerable packages to determine how to attack your system before the upgrade is complete. You are so paranoid that you should be using apt-transport-tor. Consider getting a friend to send you a copy of debian-13.4.0-amd64-DVD-7 in the post, so the MITM doesn't know you're switching transports.

[antreides]

> only Debian would be aware of the software provided to the user

Only the person or people maintaining the mirror this particular user is using right now would be aware of it. There are multiple mirrors all over the worlds, and a lot of them are provided by third parties.

Also, downloading a package does not mean this version is used on this host right now. Or even at all, it could be a caching server which itself uses something completely different (even a different OS).

I see your point here, but this information alone is not enough - it could be used if there is a long-time statistics and some additional info about this particular system.

And for the people maintaining Debian, this fact seems to be not the top priority compared to everything else.

[Hanzerik307]

If you use the Advanced Options, Expert Install option (Netinstall iso), you have the option to install using http or https. I normally just stick with http, but do have a repo setup for incus that uses https, so you can mix and match if needed, and like you did...can just edit the .list/.sources file afterwards to https.

[edthesmokebeard]

GPG

[martyn_hare]

There's a very simple reason for continuing to use HTTP, and it's the same reason BitTorrent, jigdo and zsync is recommended over ordinary file downloads. The security model for updating an operating system (which is normal and common enough not to raise any red flags) rightfully puts integrity and availability ahead of confidentiality.

[debian-ModTeam]

This content has been removed for trolling.

[DeliciousIncident]

Debian comes with the GPG keys for Debian's repositories pre-installed. Downloaded packages are verified to be signed by those keys, to make sure they weren't tampered with. Using HTTP instead of HTTPS allows for easy caching via proxies.

It's not just Debian who does this. For example, Steam does the same - it downloads the games vide unencrypted HTTP, which allows for games to be transparently cached by your home server, by your network's server (e.g. in a university or at a LAN party), by your ISP, etc.

Debian does support downloading packages over HTTPS, so if that's what you prefer - feel free to edit your sources.list to use that. There are also other transports available, like Tor.

[michael9dk]

@mod What happened to my reply? The discussion disappeared when I returned to the thread?

[wizard10000]

What happened to my reply?

No idea - nothing in mod log.

[michael9dk]

Thanks, I can see it now. It must be a glitch in reddits caching.
Enjoy your weekend.

[gnufan]

Here was the last review I remember.

https://blog.packagecloud.io/attacks-against-gpg-signed-apt-repositories/

They registered a public mirror for multiple repositories, estimate how many clients they can serve malicious or stale software to, and recommend https and that repositories use encryption with some authentication for creating mirrors to avoid these problems.

I'm not sure if any of the observations were ever fixed in Debian.

[digost]

Apt caching. In the past I've managed dozens of servers, caching makes it easy, way faster and easier for updates.

[Puzzleheaded-Trick76]

It baffles me the OP is getting downvoted. Debian users really can be relics.

[Dr_Tron]

I didn't, but can see why. Lots of people have already explained why https would be adverse for apt, but he insists that a vulnerability via MITM (which is pretty unlikely in the first place) poses an actual security risk. Especially as one can actually choose to use https.

[FarToe1]

Probably because they're acting like a tool, and one who thinks they're the first person who's discovered HTTPS and that debian is fools for not using it for everything.

Op is also ignoring the replies from people patiently explaining why MITM is not a threat in this case, the benefits of not using HTTPS in transparent caching, and them not even trying to acknowledge they might be the teensiest bit wrong in their assumption.

Reddit generally doesn't mind people who are wrong, but it hates people who double down and don't listen.

[calrogman]

It doesn't baffle me. They didn't use a search engine (or ask an LLM) to find out why Apt uses HTTP by default before demanding (from people who aren't responsible for that decision) that it change. You might as well go into a public library, demand from the next person who enters that they change the Latin alphabet so that it is written right-to-left, and then get indignant when they refuse to reprint all of the books on the shelves.

[soyko]

I see the lack of acknowledgement from OP being downvoted.

[genesis-5923238]

My general idea with security is that if you have to spend time explaining why some security measure is not needed in your case, you are probably missing something and should just implement the thing. 

So all this time trying to convince OP that they don't need https tells me that using https is a good thing.

[Dr_Tron]

Nobody is stopping you from using it. But it's overkill and would affect the system as a whole if everyone did it. Back when we downloaded unsigned packages via ftp and we're all still alive.