Idea: Use HTTPS for package downloads

[jawnsy]

Hello,

I use the official Debian image on Google Cloud (thanks for your hard work on this), so this idea is in relation to that platform. However, I think images for other clouds are likely to have the same issue.

There was a recent thread on debian-security where Luca Filipozzi pointed out that the Debian CDN (deb.debian.org) supports HTTPS for additional security. It prevents eavesdropping and provides another layer of defense in case there are bugs in the GPG signature verification code, which has happened before.

I'd like to propose installing apt-transport-https and using HTTPS source repositories by default, at least for the Big Three hyperscale clouds (Microsoft Azure, Google Cloud, Amazon Web Services), but better yet, for all of them. There is a risk that this could break package upgrades on systems with incorrect timing information due to certificates' validity period, but the risk should be much lower for the hyperscale clouds, which I'd expect to have more accurate timekeeping.

I'm happy to work on a pull request, but as this would be my first PR for this project, I require some direction on what must be done. To reduce risk and minimize disruption, we could focus on the next stable release of Debian and leave all existing images as-is.

PS: looks like the same can be done with cloudfront.d.n - https://github.com/andsens/bootstrap-vz/blob/master/manifests/official/ec2/ebs-stretch-amd64-hvm.yml#L31

[drts01]

I would say leave the default http for both size and not baking in certificate-ca. But I would love to see this as an option that can be toggled.

[jawnsy]

@CMeza99 I didn't have to install certificate-ca, just apt-transport-https and modifying sources.list. I tested on Google Cloud with the official image. I don't think it's a huge difference in image size.

Anyway, if there's interest, let me know and give me pointers to work on a PR. If not, we can just close this issue.

[drts01]

Yeah, the size is not a huge difference.

And yes, I was incorrect. ca-certificates is recommended not depends.

~$ apt show apt-transport-https
Package: apt-transport-https
Version: 1.2.24
...
= 1.1~exp15), libc6 (>= 2.14), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:3.0), libstdc++6 (>= 5.2)
Recommends: ca-certificates

But without having CAs, validating the certificate would have to be disabled, correct?

Acquire::https::Verify-Peer "false";
Acquire::https::Verify-Host "false";

I like the idea. I am just not sure about it being default for consistency, as Debain does not do this by default.

(Take my opinion with a grain of salt, as I am a noob to this project).

[mengelmann]

What's the point of using HTTPS if you're going to skip verification of peer (certificate expired, certificate revoked, Man in the Middle attack, lack of anchor) and host (certificate hostname does not match hostname used to access it)? It removes all the security provided by the use of SSL/TLS to secure the HTTP exchanges. Don't do that in production environment :)

[jawnsy]

@mengelmann My proposal would be installing apt-transport-https and ca-certificates, and performing full validation, as I don't think the size of either package should be prohibitive, especially on cloud environments. As a data point, Google Cloud defaults to 10GiB disks by default, and we're talking about servers, not an embedded environment. That said, not everyone may agree with this opinion and may prefer minimal images instead.

@CMeza99 I might've installed ca-certificates as a hard dependency of another package that I was installing. To clarify, I'd suggest installing both apt-transport-https and ca-certificates by default.

The fact that Debian doesn't do it by default is a fair criticism, though I think that's due to philosophical differences:

1. The Debian project may be opposed to relying on proprietary CDNs as a matter of philosophy (I imagine that's why this is a debian.net service rather than a debian.org service); and
2. Using insecure HTTP with GPG verification (to ensure integrity) is sufficient if confidentiality isn't a concern

Not everyone involved in the Debian project agrees, and there are threads that come up from time to time to discuss this, but no consensus (hard to do with thousands of developers!)

There is also an argument for plain HTTP as middle boxes can transparently cache packages.

Lastly, I think there's still some value in encrypting even without validating (though all the usual arguments wrt opportunistic encryption and sslstrip apply). It's less risky than usual because integrity checks are still provided by GPG signature verification, and the worst case (someone eavesdrops and can see what packages you're installing) is the same as the status quo over HTTP.

[mengelmann]

My 2 cents:

• image size is not an issue, as you noted; some external repositories require HTTPS (Node, Docker) so it is required to install apt-transport-https and ca-certificates
• ability to use transparent caching proxy (e.g. apt-cacher-ng) is an issue; with HTTPS it will not be possible to cache packages without playing with HTTPS certificates for it (in our dev and CI environment we use apt-cacher-ng proxy server and have switch in Ansible roles so these systems use plain HTTP where it is possible)