HTTP is the null hypothesis, since it's simpler. Usually there is a great reason to reject this null hypothesis - it prevents security vulnerabilities. But if there is no added value, then there is no reason to do it.

Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?

It's worth noting that a large number of people don't agree with you that HTTP is the null hypothesis. Instead, they think that HTTPS is a security/privacy best practice and a great part of defense in depth.

You can see this pro-HTTPS opinion all over this discussion.

As for your "consider", I personally do double-wrap many streams: I have a VPN for my browser. The VPN is great for hiding my home traffic from being spied on by my ISP. Without the VPN, HTTPS streams would reveal hostnames (SNI) and IP addresses to my ISP.

> Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?

If it's the exact same implementation then that doesn't really add a second layer. If, however, I am provided the option to run HTTPS over a VPN tunnel, then I would happily do that in a heartbeat. In fact, I frequently do run my web traffic over a proxy, thereby giving it at least two layers of encryption.

Yet it’s actually not simpler for the user, since their transfer can then be tampered with either by accident or intentionally leaving the user with a broken download and then what do they do? A redownlaod from a different mirror makes no difference.

The situation you described is the same thing that happens with a MITM attack with HTTPS. You would get a failed download from any mirror.

Do you have a response to my question? "Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?"

It’s not the same, Comcast and other ISPs don’t tamper with HTTPS, and if they break the HTTPS connection then it’s a clearer problem for the ISP to troubleshoot than corruption.

Sorry I don’t understand what double wrapping has to do with it, or why you’d ever do that.

Because that just makes things slower for no good reason?

I was being glib because I didn’t think I needed to explain fully, but here we go.

Double-encrypting something with the same technique is pretty much always a sign of cargo cult crypto. Modern ciphers, like those used by TLS, are strong enough that there’s no reasonable way to break them applied once, and the downside is that applying them twice is making things slower than they need to be for zero added benefit.

On the other hand, TLS and PGP are very different things serving very different purposes, so nesting those makes sense. There is an added benefit from TLS, namely that you ensure that everything is protected in transit - including the HTTP protocol itself (which is currently not protected and which might be subject to manipulation as shown in this post). Plus, it provides some resistance to eavesdropping (and with eSNI + mirrors hosted on shared hosts, that resistance should improve further).

also, the apt way to fix this would be to a) move release.gpg out of the package path and b) require the release.gpg to be wrapped and signed with the previous valid key instead of being accepted blindly

Some country's firewalls distrupt https, which makes downloading things via https difficult.

So you create an non default http mirror for that minority, instead of making the majority insecure.

so if north korea is subjugating some poor souls over there, the whole world must suffer along? there could be a setting with a big warning to disable the default HTTPS behaviour...

Which countries? I’ve only seen HTTP connections tampered with in practice, and China’s GFW blocks HTTP no different than HTTPS from what I’ve seen.

Also some companies, to allow IDS to inspect traffic without having to extract keys from clients.