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
attacks, but in some threat models is still not enough:
- It protects only the connection to the server, not integrity of the
machine itself (if someone manages to
exploit a hypothetical bug in the web server there, it's game
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,
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
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
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
- 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
worth it, the wildcard cert for the domain would need to not exists -
rather impractical thing. Maybe use separate domain then
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
server itself... BTW, I do hope that signing keys are stored somewhere
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.