Important APT security update - please read the instructions to upgrade APT safely

@debian Ouch. I wondered why Debian wasn't using HTTPS. Any plans to do so now, in the light of this vulnerability?

@wizzwizz4 Debian already supports https. But TLS certificates depends on CAs, and most on them aren't trustworthy. Unless you use DANE/HPKP, don't expect https to *prevent* MITM attacks.


@devnull Fair point. However, loads of CAs are trusted by default for _everything else_, and it's better to pile on extra layers so an attacker will need to break _all_ of them.

@wizzwizz4 That's a huge problem. CAs shouldn't be trusted, because they don't give a crap about security. They're only for profit.

More software need to support DANE, more admins need to learn how to configure DANE and HPKP properly.


1. Let's Encrypt.
2. It helps to prevent attackers from easily utilising a vulnerability in one layer of mitigation.

Yeah, it's not perfect. But yes, it's better than nothing. HTTPS + DANE is better than HTTPS + CAs, but HTTPS + DANE + CAs is even better. And @debian doesn't have DANE yet, anyway!

@wizzwizz4 @devnull @debian

As the goal is to trust debian, is it possible for debian to supply the needed certificate rather than let's encrypt?

@RussSharek @devnull That's what self-signing the certificate is, basically. It doesn't promise that the certificate is actually Debian's certificate, because you…

Oh, I see what you're saying. Debian is the CA, and bundles its own signature with Debian? Ehh… not sure how much security nuts would appreciate that. I certainly wouldn't appreciate the software distributor having the technical means to transparently intercept all of my traffic. But it's certainly a possible solution.

@wizzwizz4 > It doesn't promise that the certificate is actually Debian's certificate

CAs don't, they deliver forged certs to malicious third parties, either for profit (see what micro$oft did with ie certificates in Tunisia (and NOT only in Tunisia) years ago, with the help from malicious CA, to help the government to spy on people), or by mistake (even Let's Encrypt has been abused)

HPKP does, a certificate can't be valid if it hasn't been signed by the pinned keys.


@wizzwizz4 And the only persons that can pin a key are either the admins of the server you're trusting, or someone who succeeded to compromise the server and gain root access (or at least some privileged user), in which case you're screwed whether the certificate is CA-signed or not.


@wizzwizz4 > I certainly wouldn't appreciate the software distributor having the technical means to transparently intercept all of my traffic.

Not all traffic… just apt using a Debian CA, so it won't have to trust another CA/third party (The less entities you need to trust, the better. Less likely to be screwed over) . They wouldn't need to be a CA if they wanted to intercept your traffic, as you run code written by Debian, and third party software build and packaged ba Debian…


@wizzwizz4 So the risk you're reffering to, if Debian used it's own CA for APT, is basically non-existent. Plus, if Debian does something malicious, it will be noticed… as it Free software, and it's user base is mostly technical people.



@devnull @RussSharek You know that by "Debian" I really mean whoever can steal the… yeah, you're right. No additional risk.


It feels weird at first glance, but properly locked to only be applicable to apt it seems like a surprisingly workable solution.

Mind you, I'm sitting in the cheap seats making all kinds of half-witted assumptions. Please someone smarter than me find a better way.


@wizzwizz4 There's no perfect security. Of course, the more security there is the better.

But if the package servers and the signing keys (with their passphrases if there's one) get stolen, then I don't see any solution. We are all screwed.


Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.