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.
> 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.
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).
- 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.
- 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.
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)!
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)
- Add CAA record for the same purpose
- 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?)?
- 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
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.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
