On Thu, Aug 12, 2021 at 12:00:16AM +0200, Marek Marczykowski-Górecki wrote: > On Wed, Aug 11, 2021 at 02:02:39PM -0700, Kevin Fenzi wrote: > > drpms work by downloading the delta, then using it + the version you > > have installed to recreate the signed rpm (just like you downloaded the > > full signed update) > > I'm worried about this process specifically. It does rather heavy > parsing on a drpm file, before having a chance to verify the signature. Sure, and it takes cpu and disk space vs download time. My understanding is that it's pretty simple, but I don't know if anyone has done any kind of security review of it. > > and then the gpg signature is checked of that full rpm, > > just like one you downloaded. If the drpm is tampered with it won't > > reassemble and it will fall back to the full signed rpm. > > > > Additionally, fedoraproject.org has dnssec enabled, so if you are > > worried, do enable that to avoid hyjacking. > > Ok, so there are several things here: > 1. DNSSEC protects against only some of the threats. It won't (on its > own) help if someone intercepts my TCP connection when I download > updates via wifi in a coffee shop. Sure. You can shift the threats and make yourself unsafe. ;( > 2. HTTPS provides _much_ better protection against various kind of MitM > attacks, but in some threat models is still not enough: > - It protects only the connection to the server, not integrity of the > mirrors.fedoraproject.org machine itself (if someone manages to > exploit a hypothetical bug in the web server there, it's game > over). Sure, but also: The machines that built the rpms, the machines that store them, the machines that store the source, the maintainers that upload the source, upstreams that create the source, etc > - Furthermore, there is a wildcard cert for *.fedoraproject.org, so > in practice it's enough to break into any of the servers (having > key for that cert), to make MitM attack feasible. True, although the number of servers that have that wildcard is limited. We specifically don't store it on just any machines, it's only on our proxies and most trusted machines. > - There are over hundred trusted CAs in the default setup. It takes > just one compromised/malicious to issue a duplicate cert. Both > scenarios has happened to some CAs in the past. Sure, but this is one of those "do it and it works, but everyone knows" sorts of attacks. Once you do that once you get untrusted... Transparency logs help out with this at least from a ecosystem angle. > 3. Finally, this is about just Fedora repositories. It doesn't help for > much for dozen other repositories that user is free to add. Some may > even use plain HTTP (and rely just on package signatures)! Sure, or packages downloaded from pkgs.org or curl foo.bar | bash. > While I still think disabling deltarpm by default is a good idea, in > absence of signed metadata there are a few things that could improve the > situation: > - Pin specific CA in the repo config (sslcacert option) This would be limiting in the event we moved to another registrar... > - Add CAA record for the same purpose This is I think doable from an infrastructure point of view. Of course dnf/librepo would need to know to check it. > - Avoid wildcard cert for such critical purpose, but to make it really > worth it, the wildcard cert for the domain would need to not exists - > rather impractical thing. Maybe use separate domain then > (getfedora.org?)? I don't think this is worth it. > - Some would propose to use own CA to avoid trusting the whole > DigiCert (or other single CA), but personally I think the downsides > overweights the benefits Yeah, thats been proposed before. Pinning the cert and having a backup version thats self-signed. I don't think thats worth it either. > And this is just about the connection part, not about integrity of the > server itself... BTW, I do hope that signing keys are stored somewhere > else. We use sigul for signing. So, the "keys" are on a sign vault machine (bare metal) that isn't running any listening services (it reaches out to the sign bridge). Also, it can't do anything with the keys itself, it needs at least one signer with their passphrase + the vaults passphrase to be able to decrypt the passphrase to sign things. Its pretty reasonable for a all software setup. https://pagure.io/sigul kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
