Replace Package signing key

[widhalmt]

Hi,

We talked already about how to and why to replace the current package signing key with a longer one using better cipher algorithms. This issue is mostly to remind us that this is a task we have to do.

What we talked about:

• A new key can exist in parallel to the already established key (there might be a problem with aptly, though)
• We can ship both keys with release packages but not every user is using these packages
• We have to promote the replacement via blog, etc. before making the switch
• After some time we'll retire the old key and only use the new key. This time should be long enough so we can be quite sure all users switched.
• The key's id is hardcoded in some of our tools and we'll have to make sure they will be fit to work with the new key.
• The old key should sign the new key and some of our team members volunteered to sign both keys with their personal keys. So users who need to verify keys will be able to do that. Although, to keep the key small and simple to handle we won't export the signatures to the webserver providing the key for repositories. If someone wants to verify the key they'll have to download it from public keyservers.

[lazyfrosch]

The issue regarding aptly is multi-signing: https://github.com/smira/aptly/issues/691

[dnsmichi]

Prior to changing anything with signing keys it is mandatory to check if this issue still persists: https://github.com/Icinga/icinga2/issues/936#issuecomment-273073882

Apparently SLES 11 doesn't support 4096-bit GPG keys for RPM signatures.

[lazyfrosch]

We can just keep the old (or another) key for that repository.

[dnsmichi]

Or we just wait until March 2019 where SLES 11 finally goes EOL.

[htriem]

I'm not too sure what to make of this. Needs investigation first if this is still an issue, which it probably is.

[steadfasterX]

oh well.. this is still not solved in 2024? I am not sure if you are aware about the security impact this has (since the initial reports).

EVERYONE is able to generate SHA1 signed icinga packages which are looking valid and so can be installed without a warning.

AlmaLinux / Rocky / RHEL 9 already have clearly deprecated SHA1 signatures and afaik Ubuntu Noble too. it really shouldn't be hard to gen a new key and sign new packages ASAP, really this is a security issue and icinga often has access to almost all systems of an internal network which makes it a great attack target anyways.

so if one can easily create "valid" icinga packages which contains whatever I like ..

related:

• https://www.schneier.com/blog/archives/2020/01/new_sha-1_attac.html
• https://www.redhat.com/en/blog/rhel-security-sha-1-package-signatures-distrusted-rhel-9
• https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
• https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html
• https://malicioussha1.github.io/

[Al2Klimov]

EVERYONE is able to generate SHA1 signed icinga packages which are looking valid and so can be installed without a warning.

Luckily our repos are protected by HTTPS! But yes, depending on luck was never an option. 😅

[steadfasterX]

well that's not enough tbh. the most common attack surface is (imho):

• hacking your server or any server mirroring your packages (hard - hopefully ;) )
• DNS poisoning, MITM "public internet", ... (hard)
• DNS poisoning, MITM "internally", ... ("easy")
• hacking or tricking an internal pkg mirror (easy to hard)
• getting the modded icinga pkg elsewhere to the target system so it gets installed by the maintainer or system on next run (depends)

The thing is that as soon as the package is accepted by the system that's it. and there are likely more options available than the above while those are the ones coming to my mind at first.