Hey Russ. On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote: > Packages appearing on mirrors is not how we notify Debian users of > security updates. We do that by issuing a security advisory. Aha,... well... sounds like nitpicking,... I guess the least of the users have subscribed the respective mailing list or look regularly at https://www.debian.org/security/. And apart from that: with respect to mail: - the mails seem to often lag behind the actual release of a fix, so there is the same problem that users may not be notified as fast as they could be - while mails can be secured, there is no guarantee at all that mails arrive the subscribers with respect to web: - that uses GANDI CA certs, so this is not really a secure way to be informed about that either. > Yes, it's > nice to protect against archive downgrade attacks, but validity periods > are not our primary defense against that. Our primary defense is that we > send out a DSA telling people exactly what package versions they need. If > those package versions aren't available, that should raise red flags. See above, both means of distributing DSAs seem not to protect against downgard/blocking attacks. > Teams that run Debian servers in production should be checking that all > packages on their hosts are upgraded to the necessary versions. Even apart from the above problems, I doubt that mail is the appropriate mean for many admins to get notified about security upgrades. People may deploy security upgrades automated or at least check for them via Nagios and friends, rather than reading mails, which they get for *all* DSAs and not just the packages they actually use. To be honest, it's really awkward to see how much all this is apparently fought against. In many cases, our security teams (and all the other security teams) do such a wonderful job,... make great efforts to synchronise the deployment of upgrades between distros when they're reported secretly to the right channels, and then in a concentrated effort, all the different organisations try to release upgrades and information, so that people can update before attackers found out what the hole is and start exploiting it. And it's already reality that MitM is not only possible to governments or network operators... we see highly sophisticated attacks of criminals directly targeting single persons over multiple paths (like e.g. when smsTAN and the repsective computer is attacked). So one should generally assume that Mallory sits around, waiting. > I've run such production system clusters for many years now, and the > machinery and tools that you need to have in place to ensure that you > actually pushed out the security update to all systems will also trivially > catch downgrade attacks of the type that you're describing. I really wonder how you can do that with the above means. > But we shouldn't confuse that with the > right way to check for security updates for Debian systems. People who > care about security updates need to be subscribed to > debian-security-announce and reading the DSAs. Well, for the reasons laid out above, I disagree that this is a safe mean. Any attacker that is able to do a downgrade attack is likely also able to block your mails, ideally only such mail of packages that you run, so you'll even continue to get some DSAs, just not the ones that apply to you. > > Conceptually, the "trust" lies in the server. Even when the client > > reduces his validity times, than a server could still simply distribute > > old packages, just newly signed. > > But the MITM attacker who is launching a downgrade attack can't do this. Sure... I wasn't talking about Mallory here... I referred to whether placing the validity check mainly in the client (instead of the server) would help anything against a rogue (signing) server, which it of course does not. > It seems to me that if you want to lower the chances of a downgrade attack > for your systems, setting the validity period on your systems is exactly > the tool that you need. There's no need for anything to change on the > server side for you to get that protection. Well I don't think it would work, would it? The Release file contains e.g.: Date: Thu, 30 Oct 2014 02:54:04 UTC Valid-Until: Thu, 06 Nov 2014 02:54:04 UTC When I now lower the validity to something very small, e.g. 4 hours, than beginning with 30 Oct 2014 06:54:04 UTC everything will fail for me unless a resigning mechanism was in place like such that was discussed in #752450. So AFAIU, on can only enlarge the validity. Apart from that, there is no need that other people shouldn't benefit. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature