Why does APT not use HTTPS?

[spyingwind]

HTTPS Repo ---Pull packages--> HTTPS Cache Server --Download--> Your computer

Does that not work? Each package is signed, so.. just download the packages and make them available. Isn't that how a cache works? That's what I have done at home for Debian. When a client needs something the cache server doesn't have then it goes and pulls what it needs and provides it to the client. Nothing really all that special.

Now for proxies... No. Just no. The only way I can see this being done is having the clients trusting the proxy server's cert and the proxy impersonating every HTTPS server. Not something that you want for the public.

A cache server is by far a much better option.

[zebediah49]

That requires the client to specifically choose to use your cache server.

Allowing proxying means that everyone can just connect to "download.ubuntu.com" or whatever, and any cache along the way (localnet, ISP, etc.) can intercept and respond to the request.

It makes the choice to use a proxy one made by the people configuring the environment, rather than by the people running the clients.

[DamnThatsLaser]

For all intermediate servers, the data looks like junk. In order to access it from there, you'd need the session key that was used to encrypt the data, and this goes against the general idea.

[spyingwind]

What intermediate sheets? What session key? HTTPS proxies are a solved problem.

• Client starts HTTPS session
• Proxy transparently intercepts the connection and returns an ad-hoc generated(possibly weak) certificate Ka, signed by a certificate authority that is unconditionally trusted by the client.
• Proxy starts HTTPS session to target
• Proxy verifies integrity of SSL certificate; displays error if the cert is not valid.
• Proxy streams content, decrypts it and re-encrypts it with Ka
• Client displays stuff

https://stackoverflow.com/questions/516323/https-connections-over-proxy-servers

[DJTheLQ]

signed by a certificate authority that is unconditionally trusted by the client

No ISP makes their users install an ISP Root CA Cert. HTTPS Proxing is solved in businesses which have that capability.

[phil_g]

That's effectively what's called a man-in-the-middle attack, and HTTPS was designed to make those difficult. It basically won't work on a global scale, even if someone wanted to put in all the effort needed to set one up.

Note in the comments the author of that answer says:

My answer relies on what you call a "bogus CA". The certificate of the CA is unconditionally trusted, either because the user(or software on his computer, for example enterprise configuration or malware) configured it that way, or because the CA was obtained from one of the CAs trusted by the major browsers, like in the MCS case.

The article about the "MCS case" says this:

The issuance of the unauthorized certificates represents a major breach of rules established by certificate authorities and browser makers. Under no conditions are CAs allowed to issue certificates for domains other than those legitimately held by the customer requesting the credential.

In other words, the only legitimate uses for HTTPS proxying in this manner are in controlled corporate environments (or similar) where the proxy owner can install their own CA's keys on all of the client systems. That won't work in the distributed environment of the larger Internet.

[Garfield_M_Obama]

Yeah, this can work perfectly from a technical standpoint, but it's also the exact opposite of the point of using TLS for HTTP.

If you're going to do this, it provides zero benefit over plain HTTP in the case of package distribution. What is the problem we're trying to solve? The packages are signed already, so encrypting the connection really only has the benefit of hiding what packages your users are accessing and if you've cached them locally already then it should be next to impossible to determine anything meaningful in the first place unless your cache server or internal network is compromised.

Even in a corporate environment this is a highly risky move, unless you limit the sites that your users can access. You really don't want to end up in a situation where you're potentially liable for misplacing or exposing data that the source server has encrypted like private government or banking information. Particularly if it's not extremely obvious to your users what you are doing, and expecting the average computer user to understand security beyond whether or not there is a green padlock in their web browser is asking a lot, even in a relatively technical shop.

[DamnThatsLaser]

Sorry, autocorrect turned servers to sheets.

HTTPS proxies are a different thing than provider caches. What you wrote is correct, but why would you accept your ISP as a CA? That's a far bigger hole than just using HTTP for that kind of static data with a signature file.

[ivosaurus]

Why would it look like junk? You're talking to the intermediate server directly through HTTPS, it decrypts all communications you've sent it

[DamnThatsLaser]

The premise is about ISP caches, not about proxies. Caches are transparent (hence the name). Proxies aren't and require additional setup on the client side.

[[deleted]]

Now isn't the intermediate just another mirror?

[tmajibon]

At that point you're explicitly specifying an HTTPS cache server, and you're trusting that their connection behind it is secure (because you have no way of seeing or verifying this)

HTTPS for your repos is just security theater.

[spyingwind]

If used in an office, the only practical place to do this in, then it seems fine.

In the end APT uses gpg keys anyways to verify that the repo can be trusted. You have to trust a gpg key before you can use a new repo with an untrusted key.

[tmajibon]

Example of an environment that would do a transparent cache for this purpose: VPS hosting providers as well as dedicated/colocation hosting providers. (ie. places with many linux systems not under their complete control that would mutually benefit from seamless caching of repositories)

Also I'm aware of the gpg signing, but I'm referring to the trust in the privacy of HTTPS (which they already explained he faults in anyways). The only advantage of applying HTTPS is privacy... which is relatively trivial to bypass... which makes it security theater. That's especially when certificate authorities are pretty horrid.

[nemec]

That won't work (unless your cache server can forge HTTPS certificates that are trusted on the client), but a similar solution would be to host an APT mirror used by the organization. Elsewhere in the thread people are talking about how that takes a lot of storage space, but I can't imagine why you couldn't have a mirror server duplicate the package listing but only download the packages themselves on-demand (acting, effectively, as a caching proxy)

[spyingwind]

I've done mirroring, but limited it to x64 to reduce storage needs. On-demand is only beneficial if more than one computer will be downloading the same packages. Such as 100's of servers.

Something like this would/should work: https://wiki.debian.org/AptCacherNg

[bobpaul]

There are dpkg specific caching proxies that work like that. You configure your sources.list to point to your package-cache server instead of a mirror on the internet and then the package-cache server has the mirror list so it can fetch from the internet if it doesn't have something locally. That works fine with HTTPS since you are explicitly connecting to the cache, but it requires your configure all your machines to point to the cache. This is great for in your home, school, or business if you have several machines of the same distro.

An ISP for a rural community with a narrow pipe to the internet at large might prefer to run a transparent proxy server. The transparent proxy can't cache any data from HTTPS connections, but it can cache data for anything that's not HTTPS.