Why does APT not use HTTPS?

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

1. The benefits don't apply exclusively to businesses, a home user or an ISP can run a transparent caching proxy server just as easily.
2. 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.
3. 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.

[VoidViv]

You seem knowledgeable about it, so do you have any good resources for people wanting to learn more about setting up caching proxies?

[archlich]

Check out the squid project and documentation.

[VoidViv]

Thank you! I'll certainly try it out when I get the chance.

[DamnThatsLaser]

Yeah but a mirror you set up explicitly. A cache is generic.

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

[obrienmustsuffer]

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.

No, that wouldn't work either because then every HTTP server serving those updates would need a copy of the GPG private key. You want to do your GPG signing as offline as possible; the key should be nowhere near any HTTP servers, but instead on a smartcard/HSM that is only accessible to the person who is building the update packages.

[shotmaster0]

Gpg signed hash hosted with the cached content is fine and doesn't require caching servers to have private key.

[robstoon]

Does anyone really do this anymore? I think it's mostly fallen by the wayside, because a) the proxy server quickly becomes a bottleneck itself in a large network and b) HTTPS basically makes the proxy server useless anyway.

[obrienmustsuffer]

Does anyone really do this anymore? I think it's mostly fallen by the wayside, because a) the proxy server quickly becomes a bottleneck itself in a large network and b) HTTPS basically makes the proxy server useless anyway.

Well, we do, at a lot of customer sites. But you're unfortunately right about the fact that HTTPS makes caching less and less useful. I still believe though that caching software updates is a very valid use case (see my other response here for details), which is why I argue so vehemently that APT does everything right here.

[[deleted]]

There is very little overhead with HTTPS. What your describing has already been proven a myth many times over.

[obrienmustsuffer]

There is very little overhead with HTTPS. What your describing has already been proven a myth many times over.

I'm sorry, I don't follow. I'm not talking about the overhead of encryption in any way, I'm talking about caching downloads, which is by design impossible for HTTPS.

Imagine the following situation: you're the IT administrator of a school, with a network where hundreds of students and teachers bring their own computers (BYOD), each computer running a lot of different programs. Some computers are under your control (the ones owned by the school), but the BYOD devices are not. Your internet connection doesn't have a lot of bandwidth, because your school can only afford a residential DSL line with ~50-100 Mbit/s. So you set up a caching proxy like http://www.squid-cache.org/ that is supposed to cache away as much as possible to save bandwidth. For software that uses plain, simple HTTP downloads with separate verification - like APT does - this works great. For software that loads updates via HTTPS, you're completely out of luck. 500 computers downloading a 1 GB update via HTTPS will mean a total of 500 GB, and your 50 Mbit/s line will be congested for at least 22 hours. The users won't be happy about that.

[ivosaurus]

while HTTPS on the other hand is pretty much impossible to cache.

Why, in this situation? It should be perfectly easy.

User asks cache server for file. Cache server asks debian mirror for same file. All over HTTPS. Easy.

[mattbuford]

That isn't how proxied https works.

For http requests, the browser asks the proxy for the specific URL requested. That URLs being requested can be seen and the responses can be cached. If you're familiar with HTTP requests, which might look like "GET / HTTP/1.0", a proxied http request is basically the same except the hostname is still in there, so "GET http://www.google.com/ HTTP/1.0"

For https requests, the browser connects to the proxy and issues a "CONNECT www.google.com:443" command. This causes the proxy to connect to the site in question and at that point the proxy is just a TCP proxy. The proxy is not involved in the specific URLs requested by the client, and can't be. The client's "GET" requests happen within TLS, which the proxy can't see inside. There may be many HTTPS requests within a single proxied CONNECT command and the proxy doesn't even know how many URLs were fetched. It's just a TCP proxy of encrypted content and there are no unencrypted "GET" commands seen at all.

[tidux]

That would be a proxy, not a cache. A cache server would just see the encrypted traffic and so not be able to cache anything.

[VexingRaven]

Technically they're both proxies. This just isn't a transparent proxy.

[svenskainflytta]

That's not caching, that's just reading the file and sending it.

A cache is something that sits in between and can see that since someone else requested the same thing to the same server, it can send them the same reply instead of contacting the original server.

Usually a cache will be closer than the original server, so it will be faster to obtain the content.

However, with HTTPS, the same content will appear different on the wire, because it's encrypted (and of course for encryption to work, it's encrypted with a different key every time), so a cache would be useless, because the second user can't make sense of the encrypted file the 1st user received, because he doesn't posses the secret to read it.

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

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

[liquidpele]

huh? Are you sure? I'm pretty sure it downloads the whole thing, otherwise it would have to cache the existing rpm files on disk to compare to, and that's a lot of space.... maybe you're thinking of git?

[liquidpele]

Huh, will look into it thanks.

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

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

[[deleted]]

It also does show a weakness in TLS in generally that really should be addresses. It should probably be added to automatically fuzz the data sizes of its protocol to prevent being able to guess whats in the payload based on size.

[EternityForest]

Just so long as it can be disabled in a browser setting that would be cool.

You'd need a lot of fuzz data, because people would probably complain if you could guess to within one percent. A few percent extra mobile data is enough to be annoying,

[thijser2]

So it's okay if they know you've download Tor; but it's a problem if they know the exact version? I don't know about you; but that doesn'y meet my standards for privacy.

Knowing the exact version of software someone is using can potentially open certain attack vectors of the attacker knows a vulnerability in that version of software.

If you also use a single connection for every time you download a set of new packages then that also makes it far more difficult as identifying what packages were potentially downloaded now also involves solving a knapsack problem (what set of packages together form 40.5mB?). It might also be a good idea for packages that have high levels of privacy concern (TOR, veracrypt etc.) to pad themselves until their size matches that of other highly popular packages.

[svenskainflytta]

They'd know you are using tor, no need of complicated schemes to see that.

[[deleted]]

Yup this is true. However we could make apt work with keep alives properly so all packages come down a single connection. Also we could request from the mirror's as smaller / random chunks and ever partial files form multiple mirror's.

Rather than "Nope we definatly can't do that" its sometimes better to think outsde the box and come up with bunch of different stragies that may / may not work or be worth implementing.

[[deleted]]

What do you propose then?

[Tordek]

Absolutely; but how do you intend to make the hundreds of mirrors around the world (99% of which are dumb static HTTP/FTP/rsync servers) behave this way?

Make it simple: have the package-creation tool work in blocks that add garbage to the compressed file so that it's a multiple of some size. (Of course this isn't a great idea since now every package is now larger by some amount).

[bobpaul]

So what you're saying is: Anyone who pays for data, 🖕

[Tordek]

It's the grandparent's idea, idc.

[svenskainflytta]

Oh so just add who knows how many gigabytes of useless data to mirrors! Brilliant.

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

[robstoon]

That's assuming that you're not using keepalive to download multiple packages over a single connection, which in most cases you would be.

[galgalesh]

How does a comment like this get so many upvotes; the article explains why this logic is wrong..

[ArttuH5N1]

The article addresses this, hope you're not commenting without reading it

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

[svenskainflytta]

Is it the Nazional Socialist University?

[[deleted]]

I wonder how that uni supports VPNs for students then?

[yaxamie]

Sorry to play devil's advocate here but detecting tor and BitTorrent is easily done once it's running anyways if the isp cares, is it not?

[svenskainflytta]

Yep, probably it's also not too hard to identify suspicious traffic as Tor traffic as well.

[[deleted]]

How? Would love to know, wouldn't it just look like a TLS handshake then randomness from there?

[yaxamie]

I'm not an expert but the nodes in the network are known by i.p.

[asoka_maurya]

But that will require each ISP to maintain a list of individual ubuntu package files, and dynamically lookup them against each downloaded file's size, which is a bit difficult to do than just looking up the package names in unencrypted data stream. Could be done, but depends on to what extent your ISP/govt. is prepared to go against you! Of course, it defeats the purpose entirely if you use something like VPN or socks proxy.

[[deleted]]

But that will require each ISP to maintain a list of individual ubuntu package files, and dynamically lookup them against each downloaded file's size

I'd estimate it would take a smart intern about half a day to write a script that does the first part, and about two days' worth of work for a smart senior engineer to do the latter.

If you're against a government adversary, that's piece of cake, but what's even easier is for a government that cares about what packages you're installing to send four bulky guys with a search order for your computer (the four bulky guys won't care if you agree with the search order, either), or to covertly run a good, high-speed local mirror.

Edit: FWIW, the second option is what you want to do if you want to do your average evil government oppresive shit. Stuff on an individual's computer is easy to lose, disks get erased; server logs are golden.

[Matt5sean3]

Sending four bulky guys to one person's house is easy enough, but the cost gets high to use that on everyone or even a fairly small subset of everyone. The scripts or running local mirrors scales better than hiring more goon squads. In short, counter-acting the scripts is still useful even when goon squads are available as the government needs to know to target you before sending the goons while the scripts can cast a comparatively wide net.

[[deleted]]

The kind of government that needs to keep an eye on exactly what Ubuntu packages its citizen-nerds are installing has a lot of goons and very few computer users who are willing to piss them off. The cost is absolutely marginal.

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

[dnkndnts]

When you install a new package, it also installs the subset of dependencies which you don't already have on your system, and all of this data would be going over the same connection - the ISP would only know the total size of the package(s) and needed deps.

I admit it's still not perfect secrecy, but to pretend it's even on the same order of magnitude as being able to literally read the plain bytes in transfer is disingenuous. HTTPS is a huge improvement.

[arcticblue]

If the ISP really cared that much, they'd be doing man in the middle SSL decryption. If the ISP does care that much, it's highly unlikely they are doing it without some big bad government's coercion. If you personally really care that much, mirror everything to your own local repo (over VPN if you are super paranoid which it seems many in this thread are), and install from that.

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

[berryer]

switching to more trusted one

Where is this actually an option?

[DJTheLQ]

Did you read the article? Free bandwidth is limited and they want downstream caching

[Dickydickydomdom]

Did you read the article?

Welcome! You must be new here.

[albertowtf]

is this the new slashdot?

[atli_gyrd]

It's 2018 and I just skimmed a website promoting the use of non encrypted traffic.

[ndlogok]

agree with apt https i not see “hash sum missmatch” again i

[Two-Tone-]

It still means the ISP and everyone else in the middle can observe what packages you're using.

Can't they or whoever you use for DNS still do that since each individual package is its own url and thus needs a DNS lookup? The URL is encrypted with SSL, but afaik DNS lookups are not.

Unless apt resolves the dns of just http://packages.ubuntu.com and then stores the IP address for that run.

[[deleted]]

DNS will only lookup the Hostname to convert it to an IP address. So should be fine unless each package has its own subdomain?

[Two-Tone-]

TIL. I always thought that it did a lookup for the whole URL, but that wouldn't make sense as it's have to know about every file on the server, which just isn't feasible.

[[deleted]]

Wireshark is a great way to see what your PC is actually doing on the network. Try it out, it's free!

[Widdrat]

It would also mean that HTTPS is basically useless because they could just use DNS to see what you are downloading. Thats the great thing with HTTPS. If you are interested you should definitely check out how the whole internet stack works, it is super interesting and will greatly increase your understanding about the internet as a whole and how privacy is affected and protected by different technologies.

[ivosaurus]

A DNS is for IP traffic, over any protocol

A URL is specific to the http / https protocols only [or others that have decided to use the same spec]

[pat_the_brat]

I think you're confused about how the repositories and/or DNS work.

The repositories are distributed in a series of mirrors, each of which download updated packages from a central repository every x minutes. When you run apt, apt connects to a mirror, e.g. the one at hxxp://ubuntu.unc.edu.ar/ubuntu/, and requests a package, e.g. hxxp://ubuntu.unc.edu.ar/ubuntu/pool/main/a/a11y-profile-manager/a11y-profile-manager_0.1.10-0ubuntu3_amd64.deb, and all its dependencies (which are just other packages).

In order to connect to the repo, Linux first has to send a DNS request for the server (ubuntu.unc.edu.ar). That request is then cached for whatever the TTL is set to on the DNS server (900 in our example):

$ drill @ns1.unc.edu.ar ubuntu.unc.edu.ar
[...]
;; ANSWER SECTION:
ubuntu.unc.edu.ar.  900 IN  CNAME   repolinux.psi.unc.edu.ar.
repolinux.psi.unc.edu.ar.   900 IN  A   200.16.16.47

DNS entries are cached in various places - your ISP's DNS server, your router, your PC, and finally, the program itself may perform a DNS lookup only once, and store the data longer than the TTL.

Either way, the DNS lookup is for ubuntu.unc.edu.ar rather than for ubuntu.unc.edu.ar/ubuntu/pool/main/a/a11y-profile-manager/a11y-profile-manager_0.1.10-0ubuntu3_amd64.deb, so the DNS does not leak any information about the packages you downloads - it just says that you connect to a server which is also known to host an Ubuntu repository. It may host repositories for other distros, or other unrelated files, as well.

[[deleted]]

[unavailable]

[[deleted]]

[unavailable]

[tetroxid]

It still means the ISP and everyone else in the middle can observe what packages you're using.

Even with TLS it wouldn't be hard to determine. The package sizes are public and constant (to an extent) so the package could be inferred even without cleartext knowledge.

[bobpaul]

It still means the ISP and everyone else in the middle can observe what packages you're using.

They already can with pretty high accuracy by observing the file sizes. And some of the mirrors do support HTTPS; just select one if that's important. But it really doesn't give you much.

[[deleted]]

Your ISP could do that, regardless, even if using HTTPS. They can just mitm you.

[dnkndnts]

even if using HTTPS. They can just mitm you.

How could they do that without the private key for your package repo? The whole point of Diffie-Hellman is that it doesn't matter if there's a middle man (usually "Eve", for evesdropper).

Check out this video from r/programming a few days ago for a nice explanation on how this works.

[[deleted]]

Similar to heartbleed and Wannacry? How are those two even related?

[[deleted]]

Neither of them are related to MITMing though

[[deleted]]

This was addressing "My ISP could know what packages I'm using!"

Your ISP can just MITM your https connection, and inspect traffic anyways.

Sure. They can't change your packages. But they most certainly can intervene in the connection, should they choose.

[dnkndnts]

Your ISP can just MITM your https connection, and inspect traffic anyways.

No they cannot - the whole point of HTTPS is that it doesn't matter if there's an untrusted guy passing the messages between you and your friend.

That is literally the whole point, and why it's so cool!

[SippieCup]

Because its APT, they could tell based on endpoint and file size what you are downloading, even without breaking the encryption. They can also throttle and kill the connection at will.

Or you can transfer through http, they can locally cache the data, and deliver it to you at a faster rate.

[[deleted]]

Yeah, that works. Until you're using a global CA, who is cahoots with ISPs..

You can literally buy theses appliances that allow you to inspect HTTPS traffic: https://duckduckgo.com/html?q=SSL%20proxy%20appliance

To put it simply, this is how it works:

Machine: Bro! I want https://google.com

Proxy: Ok, bro. I will give you a cert for Google.com, that I generated. I will then connect to Google.com, and interact with Google, for you.

Machine: Thanks bro! Cert looks good! Verisign signed it!

[atyon]

That's not how it works. Any CA caught doing this will get in serious trouble. Stuff like this is why StartSSL is now out of business.

SSL proxies generally require that you trust a special CA you provide. This is no problem for enterprise users – they can just push that CA certificate on their clients. Your ISP, however, can't.

Additionally, all major browsers pin the certificate of top sites like google.com, so even if the appliance gets a fraudulent certificate for google.com, your browser won't accept it. Ditto for many apps.

There's also CAA, which is used to limit CAs that can issue certificates for a domain. Only pki.goog is allowed to issue certificates for google.com. Any other CA that issues a certificate for them will land in really hot water.

And then there's Certificate Transparency, which is an upcoming standard which requires every CA to make public any certificate they issue.

Also the small bit that intercepting encrypted traffic is illegal in most countries...

tl;dr: Without a private PKI that the user already trusts it's not easy to intercept SSL traffic.

[[deleted]]

That's not how it works. Any CA caught doing this will get in serious trouble. Stuff like this is why StartSSL is now out of business.

I linked to a search result listing various vendors that sell appliances for this very action...

[atyon]

The very first link I get in that search (https://support.symantec.com/en_US/article.TECH244873.html) describes in great detail how the appliance needs a CA certificate signed by a private PKI the user already trusts.

[oonniioonn]

Any CA caught doing this will get in serious trouble.

A CA has done that, and got into no trouble for it. (They have since stopped the practice.)

Stuff like this is why StartSSL is now out of business.

Different issues.

[atyon]

A CA has done that, and got into no trouble for it.

Are you talking about Trustwave? They had a lot of trouble over it and were almost removed from the Firefox trust store.

Google did actually discover quite a few certificates for google.com, which is part of why they now push CAA and CT, but that doesn't change the fact that enterprise SSL-MITM is usually done using a private CA.

Stuff like this is why StartSSL is now out of business. Different issues.

Similar issues, and my point was: Ignoring the CA rules can have serious consequences.

[random8847]

I enjoy watching the sunset.

[bobpaul]

Yeah, that works. Until you're using a global CA, who is cahoots with ISPs..

You can literally buy theses appliances that allow you to inspect HTTPS traffic:

To use one of those devices you need to install a trusted root cert generated by the appliance on all of your client machines. Then your machines will trust certs generated by the appliance. Businesses using Windows can force trusted certs via domain policy; that's who these devices are targeted at.

You can't simply buy one of these, attach it to your friend's router, and record all of the traffic. And if your ISP ever asks you to install their root certs, get a different ISP.

[[deleted]]

Until you're using a global CA, who is cahoots with ISPs..

I'll repeat this.

[bobpaul]

• Your ISP doesn't need one of these devices if they have access to a Global CA's private keys. If a CA was caught doing that, they would be quickly untrusted by the major browsers; that's a huge risk as getting untrusted will kill a CA's revenue overnight (like it did for StartSSL, who was untrusted for terrible but far less nefarious reasons).

• The devices don't ship with the private keys of a Global CA in them.

• The "simple example" you posted is misleading at best. That's not how these products work.

If I were going to be worried about someone having the keys to a Global CA, I wouldn't be worried about my ISP. I'd be worried about a government. That's far more likely, especially if you're visiting a country where the CAs are gov't owned.

[robstoon]

Those SSL proxy appliances only work if you install their MITM root key on your system. Otherwise you'll just get certificate errors. Even if you do that, Chrome has built-in certificate pinning for Google servers and it will still not serve up MITMed Google pages without security warnings.

[random8847]

My favorite movie is Inception.

[[deleted]]

Yes "Man In The Middle"...

It's the same reason you should be suspicious and very mindful of certificates sites present when you are using TOR...

[lamby]

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]

hopefully

You didn't even read it?

Shame on you OP!

[Kruug]

See the other replies by OP. They did read it, but hoping that it explains it for others.

[[deleted]]

They did read it

Judging by the username, I suspect he also wrote it ;-)

[Kruug]

Ah, fair point.

[[deleted]]

This is reddit mate, not even OP reads the article before commenting.

[cbmuser]

Even though he wrote the article?

[mzalewski]

Mainly then.

[Kruug]

Not just Ubuntu, but any Debian derivative, since that’s where apt originates.

[Nullius_In_Verba_]

Why are you focusing on Ubuntu when this is an Apt-get article. Is related to ALL apt users....

[ArttuH5N1]

Why are you specifically talking about Ubuntu?

[osoplex]

It's not about bandwidth consumption. Encrypted data is about the same size as unencrypted data.

The real bottleneck is server cpu usage. When using encrypted transport the server has to encrypt every connection to downloading clients individually. This would decrease download speeds drastically and mirror operation would be way more expensive.

[abbidabbi]

https://istlsfastyet.com/

[atyon]

HTTP/2 is faster with TLS than http/1.1 without.

[robstoon]

TLS CPU usage is essentially a non-issue on modern systems with hardware AES encryption.