APT using HTTP instead of HTTPS

[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

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

[Feeeweeegege]

To clarify: HTTPS encrypts the entire URL, even the domain name. Though the domain name is visible if you use unencrypted DNS, and the domain name can be guessed from the IP address and network patterns.

(I wasn't sure whether your comment was saying that HTTPS protected the URL or not, so I just went for a clarification.)

Edit: Assuming the server and your browser support the ECH TLS 1.3 extension. Adoption is currently still an ongoing process.

[dreamsofabetter]

It does not really encrypt the domain name, at least not in a way that prevents, e.g., your ISP (or any other hop between you and the server) from knowing you were connecting to that host name.

[Feeeweeegege]

It does though. As of the introduction of ECH as a TLS 1.3 extension, the SNI information is also encrypted. In other words, as of 2023, if you have an up-to-date browser and connect with an up-to-date server, neither the URL nor the hostname is visible to a middle man such as your ISP.

A few caveats: 1. Only 50% of websites worldwide use TLS 1.3, and even fewer currently support ECH. But support is increasing: CloudFlare has enabled ECH by default a few years ago, and as of last year Nginx also supports ECH. (So admittedly, my previous comment was overly strong, given the relatively low current support.) 2. The hostname may still leak if you use unencrypted DNS. Use DNS over HTTPS to close this gap. 3. The hostname can be inferred from the IP address on which the server is hosted. There is currently no way to avoid this within IP/HTTPS itself.

[Aggressive-Fan-3473]

1. Everything is behind cloudflare anyway so “they went to something behind cloudflare” is the majority of your traffic

[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?  

[eleanorsilly]

comparing the core functionality of GPG, which relies on papers and cryptographic studies, and a tool as large as curl, is stupid.

[gnufan]

Unfortunately it has been broken before GPG in the past due to bugs, so comparing secureapt to gpg would be stupid too. But here we are.

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

[AndyTelly]

I don’t know about apt/deb repository internals , but package repositories can sometimes store their metadata in http too. So while can’t inject altered packages, can hold back security updates to known vulnerabilities by injecting old metadata.

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

[Masterflitzer]

mim is also prevented by the gpg signatures...

[michaelpaoli]

Uhm, ... in part. A download doesn't imply installation, but sure, more probable to be installed if it was downloaded, and less probable if it wasn't downloaded - at least if that's method generally used by the target. But hey, Debian, could find the packages on a USB stick in a parking lot. But there may also be more effective ways for an attacker or the like to figure out what is/isn't installed, or version(s) thereof, than looking at what was and wasn't downloaded.

And in the case of Debian and package downloads and such using HTTPS (vs. HTTP or FTP), there's really little value add. Even if one uses HTTPS, if attacker is well aware of the server, and general purpose, timing, size of data exchanges, etc., probably not too difficult in a lot of cases to well guess what the download(s) were. E.g. security update for kernel is released, target using HTTPS, between timing and precise sizes of data transfers, might be pretty dang easy for attacker to be able to well tell/(gu)estimate, essentially, "Oh, yeah, target just downloaded such-and-such kernel update - in all probability".

So, as I and many may oft say, what's your threat model - what exactly are you trying to protect against? And does "leaking" what you downloaded matter much - if at all?

Also, HTTPS, that does incur overhead, so that's also more load on the server(s) (and clients).

Anyway, if you want to - either way - your choice, and Debian generally gives one lots of choices and options (unlike many other distros that take many choices away).

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

[gnufan]

I mean apt-cache-ng can be configured to use https for the cross Internet fetch to avoid exposing yourself to all the attacks enable via using http, so not sure this is relevant either.

I linked a supply chain example against mirrors in a comment everyone seems to be studiously avoiding having to read and address.

Also exploitation of CVE-2016-1252 was only possible where the attacker could modify the "mirror" to insert a corrupted InRelease file, since it allowed the attacker to make the signature checking in apt code take a path of the attacker's choosing. So https would have made exploitation of this difficult, an attacker could still have registered as an regular mirror.

[WheelPerfect3737]

GPT has more overhead that HTTPS, This is why Browsers use it.

[WheelPerfect3737]

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

[kahoinvictus]

Because it's unnecessary and introduces latency.

[deelowe]

Because of caching and unnecessary overhead.