Serving large amounts of content over HTTPS is expensive. When the data is signed anyways you gain nothing by using TLS other than privacy.
My laptop can do 1,400 RSA 2048 sign operations per second per core [4], 16,000 P-256 ops and 25,000 X25519 ops per second per core [5], so I wouldn't care about handshake performance either.
With large files, you don't care about the performance of the handshake, but if you do care about handshakes you can reuse http connections and use TLS session resumption for new connections, which avoids the relatively expensive asymmetric crypto (with modern servers, ECDHE and RSA digital signature). libcurl will do it, among others, so build your client using a good https library.
What is expensive about serving large amounts of content over HTTPS?
1 - https://en.wikipedia.org/wiki/AES_instruction_set
2 - https://en.wikipedia.org/wiki/CLMUL_instruction_set
3 - run "openssl speed -evp aes-128-gcm", my laptop does 4.5GB/s
4 - openssl speed rsa
5 - openssl speed ecdh
This assumes that package hosts segregate themselves by all possible privacy-related dimensions.
They don't. If you host illegal-in-country-X content on AWS and someone downloads it there, HTTPS would've prevented that from being seen. HTTP does not.
---
HTTPS belongs everywhere. It has flaws, of course, but there's no reasonable alternative at the moment. You can't predict what governments will decide in the future, and HTTP-now means they can record it and apply rules retroactively if they change their mind. This kind of thing gets people killed.
Also, HTTPS is not expensive, contrary to popular belief.
> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.
(source: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...)
Wouldn't it have prevented this bug?