Important APT security update - please read the instructions to upgrade APT safely https://www.debian.org/security/2019/dsa-4371
@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!
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 > 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 Debian even disabled SSLKEYLOGFILE variable on non-dev Firefox builds (current and ESR) "for security" while it's non really a security code. There's more easier and effective/permanent attacks, than
- using an HTTPS debug option
- which requires physical access, and launching firefox from the same shell as the one where SSLKEYLOGFILE
- is temporary
Debian won't be interested in spying on users. It's not google/micro$oft/facebook/****
@RussSharek Yeah, but if you don't, don't use Debian or any derivative, or any derivative of derivative… and so on. So you wouldn't by concerned about that all.
If you use Debian, then by definition you do trust Debian, unless you're drunk or high when you install anld use your OS(es) (or really stupid)
@RussSharek Indeed. Just like any other OS (or even other software like clients for proprietary communication protocols with their own CA stores, firewall bypassing mechanisms (see skype)…). So being a CA for it's own repos is far less risky than many commonly accepted practices (For example using "apps" for centralized and proprietary online services, where the service provide controls the client code as well. Or using google and gmail and try to block web trackers "for privacy")
Bienvenue dans le media fédéré de la Quadrature du Net association de défense des libertés. Les inscriptions sont ouvertes et libres.
Tout compte créé ici pourra a priori discuter avec l'ensemble des autres instances de Mastodon de la fédération, et sera visible sur les autres instances.
Nous maintiendrons cette instance sur le long terme.