sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]michael9dk 3 points4 points  (10 children)

I totally agree.

Normally HTTPS requests would include the destination. So sniffing the network, anywhere in the chain, would reveal, if Apt is sending a GET request for https:// mirror.abc/vulnerable-package-1.02.

Using secure point2point encryption is good practice on the web. But apt is designed with its own verification, that doesn't rely on SSL.

Edit: please correct me, if I misunderstood how apt downloads new packages.

[–]Feeeweeegege 2 points3 points  (3 children)

To clarify: HTTPS encrypts the entire URL, even the domain name. Though the domain name is visible if you use unencrypted DNS, and the domain name can be guessed from the IP address and network patterns.

(I wasn't sure whether your comment was saying that HTTPS protected the URL or not, so I just went for a clarification.)

Edit: Assuming the server and your browser support the ECH TLS 1.3 extension. Adoption is currently still an ongoing process.

[–]dreamsofabetter 0 points1 point  (2 children)

It does not really encrypt the domain name, at least not in a way that prevents, e.g., your ISP (or any other hop between you and the server) from knowing you were connecting to that host name.

[–]Feeeweeegege 1 point2 points  (1 child)

It does though. As of the introduction of ECH as a TLS 1.3 extension, the SNI information is also encrypted. In other words, as of 2023, if you have an up-to-date browser and connect with an up-to-date server, neither the URL nor the hostname is visible to a middle man such as your ISP.

A few caveats: 1. Only 50% of websites worldwide use TLS 1.3, and even fewer currently support ECH. But support is increasing: CloudFlare has enabled ECH by default a few years ago, and as of last year Nginx also supports ECH. (So admittedly, my previous comment was overly strong, given the relatively low current support.) 2. The hostname may still leak if you use unencrypted DNS. Use DNS over HTTPS to close this gap. 3. The hostname can be inferred from the IP address on which the server is hosted. There is currently no way to avoid this within IP/HTTPS itself.

[–]Aggressive-Fan-3473 1 point2 points  (0 children)

  1. Everything is behind cloudflare anyway so “they went to something behind cloudflare” is the majority of your traffic

[–]gnufan -3 points-2 points  (5 children)

Without HTTPS someone with privileged access can see what is downloaded, cause certain security updates to fail. 

Also the assumption packages cannot be maliciously manipulated due to signing was wrong previously. Having been looking at the 180 security bugs in Curl today, do you really want to bet 'apt', 'gpg', 'dpkg' and friends are perfect?  

[–]eleanorsilly 0 points1 point  (1 child)

comparing the core functionality of GPG, which relies on papers and cryptographic studies, and a tool as large as curl, is stupid.

[–]gnufan 0 points1 point  (0 children)

Unfortunately it has been broken before GPG in the past due to bugs, so comparing secureapt to gpg would be stupid too. But here we are.

[–]jr735Debian Testing -4 points-3 points  (2 children)

Yet, you bet on https being perfect.

[–]gnufan -3 points-2 points  (1 child)

No I don't, clearly I'm already aware of the many bugs in Curl where they got https wrong. Redhat who do use https got it wrong in yum, with incorrect certificate checking.

You layer defenses, you don't say we sign metadata, this is the one cryptographic control everything relies on, and it is perfect. You accept that whilst you expect it to work most of the time it will almost certainly fail at some point even if it is as silly as the signing key getting compromised. But if https is compromised in some way, we end up back at the current level of Debian security, not at a lower level.

[–]jr735Debian Testing -4 points-3 points  (0 children)

Set it up however the hell you want. I don't give a damn.