Remplacement de KSK et changement d'algorithme avec OpenDNSSEC
Publié le 03/01/2024, dans informatique, infrastructure, dns, dnssec, security
Dans un précédent article j'expliquai comment mettre en place DNSSEC sur ses zones DNS. Je disai aussi dans la conclusion que les KSK rollover et changements d'algorithmes feraient peut-être l'objet d'un futur article, eh bien le voici.
Nous allons voir comment faire ça avec OpenDNSSEC, sur des zones déjà configurées. Je l'ai fait ces derniers jours sur ma zone lithio.fr : je signai jusqu'à présent cette zone avec une KSK et une ZSK (regardez mon article précédent sur le sujet si un rappel des termes est nécessaire) utilisant l'algorithme 8 (RSA-SHA256). J'ai décidé de passer à l'algorithme 13 (ECDSAP256SHA256) qui est recommandé dans la section 3.1 de la RFC 8624.
Mini-introduction au roulement des clés
Le remplacement des clés utilisées pour signer cryptographiquement une zone DNS peut être fait pour plusieurs raisons :
- En cas de compromission des clés privées (suspecté ou avéré)
- En cas de changement d'algorithme de signature
- De temps en temps, car on peut considérer ça comme une bonne chose (et ça permet de ne pas perdre la main)
- Surement d'autres cas…
Ce remplacement se fait en 3 temps :
- Génération des nouvelles KSK et ZSK
- Publication des nouvelles clés dans la zone DNS
- Attente
- Publication du DS de la nouvelle KSK dans la zone parente
- Attente
- Suppression du DS de l'ancienne KSK de la zone parente
- Attente
Les temps d'attente dépendent des TTL de la zone DNS et de la zone parente. En effet, il faut patienter pour être sûr que nos nouvelles clés ou DS soient bien visibles par tous les résolveurs qui peuvent avoir d'anciennes informations en cache. Une fois que le TTL voulu est dépassé une ou deux fois on peut estimer que la réjuvénation des données a eu lieu pour tous les résolveurs.
Petite note
Concernant cette dernière affirmation comme quoi « on peut estimer que la réjuvénation des données a eu lieu pour tous les résolveurs » c'est en réalité un peu plus compliqué que ça.
Dans un monde où tout le monde respecte les standards ça serait vrai… Mais nous ne sommes pas dans ce monde. Ainsi on peut parfois croiser des résolveurs DNS qui forcent un TTL minimal, ce n'est pas bien mais ça existe. J'ai plusieurs fois été confronté à ça et dans ce genre de cas le plus commun est un TTL forcé à 1h ou 24h.
Il faut donc prendre ça en compte quand on fait nos rotations.
Allons-y !
Étape 1 : Modification de la politique, génération et publication des nouvelles clés
La première chose à faire est de modifier notre politique dans la configuration KASP /etc/opendnssec/kasp.xml pour y apporter les changements d'algorithmes.
Ce fichier dans mon cas contient une politique faite pour l'AFNIC qui gère les zones comme fr. Jusqu'à présent voici à quoi ressemblait la partie Keys :
<Keys>
<TTL>PT12H</TTL>
<RetireSafety>PT3H</RetireSafety>
<PublishSafety>PT3H</PublishSafety>
<Purge>P14D</Purge>
<KSK>
<Algorithm length="2048">8</Algorithm>
<Lifetime>P1Y</Lifetime>
<Repository>SoftHSM</Repository>
<ManualRollover/>
</KSK>
<ZSK>
<Algorithm length="1024">8</Algorithm>
<Lifetime>P60D</Lifetime>
<Repository>SoftHSM</Repository>
</ZSK>
</Keys>
Et voici ce à quoi elle ressemble à présent :
<Keys>
<TTL>PT12H</TTL>
<RetireSafety>PT3H</RetireSafety>
<PublishSafety>PT3H</PublishSafety>
<Purge>P14D</Purge>
<KSK>
<Algorithm length="512">13</Algorithm>
<Lifetime>P1Y</Lifetime>
<Repository>SoftHSM</Repository>
<ManualRollover/>
</KSK>
<ZSK>
<Algorithm length="512">13</Algorithm>
<Lifetime>P60D</Lifetime>
<Repository>SoftHSM</Repository>
</ZSK>
</Keys>
J'ai remplacé le numéro d'algorithme ainsi que la taille des clés pour les KSK et ZSK.
À présent il ne nous reste plus qu'à, comme le dit la documentation, réimporter les politiques et dire à l'enforcer de regarder s'il y a des choses à faire.
Avant ça on peut vérifier l'état de notre zone :
# ods-enforcer key list --verbose --all --zone lithio.fr
Keys:
Zone: Keytype: State: Date of next transition: Size: Algorithm: CKA_ID: Repository: KeyTag:
lithio.fr KSK active 2024-01-04 21:26:19 2048 8 f88116e010c6c1dd671df83048f877f8 SoftHSM 65035
lithio.fr ZSK active 2024-01-04 21:26:19 1024 8 52b72c5dca75405d283fec212376cd21 SoftHSM 35184
Et les clés présentent dans mon HSM étaient celle-ci :
# ods-hsmutil list
Listing keys in all repositories.
4 keys found.
Repository ID Type
---------- -- ----
SoftHSM b6acd66cb4f4fd36c2782accf58783cc RSA/1024
SoftHSM 52b72c5dca75405d283fec212376cd21 RSA/1024
SoftHSM f88116e010c6c1dd671df83048f877f8 RSA/2048
SoftHSM a3b0a0a3e94b902d112bf7ca073b93a4 RSA/2048
Ainsi qu'avec DNSViz :
Schéma DNSSEC de lithio.fr au 2023-12-29 12h29 UTC
À noter que je fais tout ceci via Ansible mais c'est pareil manuellement (je lance ceci le 29 décembre 2023 à 16h08 UTC) :
# ods-enforcer policy import
# ods-enforcer enforce
À noter que si j'avais voulu faire un KSK rollover sans changer d'algorithme il aurait suffi de lancer la commande ods-enforcer key rollover --zone lithio.fr --keytype KSK.
Après le lancement de l'enforcer on peut voir que les nouvelles clés ont bien été générées :
# ods-hsmutil list
Listing keys in all repositories.
8 keys found.
Repository ID Type
---------- -- ----
SoftHSM b6acd66cb4f4fd36c2782accf58783cc RSA/1024
SoftHSM 5ffbb6208c612c0a0d93982fe4c536ea ECDSA/256
SoftHSM e2c00c50ee72dbb255ae9034237c7f06 ECDSA/256
SoftHSM 52b72c5dca75405d283fec212376cd21 RSA/1024
SoftHSM e61e15b4db88538005e07caf4ce3c16f ECDSA/256
SoftHSM f88116e010c6c1dd671df83048f877f8 RSA/2048
SoftHSM a3b0a0a3e94b902d112bf7ca073b93a4 RSA/2048
SoftHSM efd09e930678c120c32785dd3ad1e6df ECDSA/256
Et que OpenDNSSEC vois bien les nouvelles KSK et ZSK :
# ods-enforcer key list --verbose --all --zone lithio.fr
Keys:
Zone: Keytype: State: Date of next transition: Size: Algorithm: CKA_ID: Repository: KeyTag:
lithio.fr KSK active 2023-12-30 09:07:32 2048 8 f88116e010c6c1dd671df83048f877f8 SoftHSM 65035
lithio.fr ZSK active 2023-12-30 09:07:32 1024 8 52b72c5dca75405d283fec212376cd21 SoftHSM 35184
lithio.fr ZSK ready 2023-12-30 09:07:32 512 13 e2c00c50ee72dbb255ae9034237c7f06 SoftHSM 52332
lithio.fr KSK publish 2023-12-30 09:07:32 512 13 5ffbb6208c612c0a0d93982fe4c536ea SoftHSM 39514
La nouvelle ZSK (portant le keytag 52332) est en état ready, ce qui signifie qu'elle est publiée et "visible" par tous les résolveurs.
La nouvelle KSK (portant le keytag 39514) est en état publish, ce qui signifie qu'elle est publiée mais qu'il faut attendre le TTL pour qu'elle soit "vue" par tous les résolveurs.
On peut vérifier avec DNSViz qui nous permet de voir que à 16h13 UTC toutes nos clés sont là. La nouvelle ZSK signe les enregistrements DNS au même titre que l'ancienne et la nouvelle KSK attend sagement son heure dans son coin :
Schéma DNSSEC de lithio.fr au 2023-12-29 16h13 UTC
Maintenant il nous faut attendre.
Étape 2 : Publication du DS de la nouvelle KSK dans la zone parente
Le lendemain, 30 décembre 2023 vers 14h50 UTC, on voit que plusieurs choses ont changé :
# ods-enforcer key list --verbose --all --zone lithio.fr
Keys:
Zone: Keytype: State: Date of next transition: Size: Algorithm: CKA_ID: Repository: KeyTag:
lithio.fr KSK retire waiting for ds-gone 2048 8 f88116e010c6c1dd671df83048f877f8 SoftHSM 65035
lithio.fr ZSK active 2024-02-27 17:07:32 1024 8 52b72c5dca75405d283fec212376cd21 SoftHSM 35184
lithio.fr ZSK active 2024-02-27 17:07:32 512 13 e2c00c50ee72dbb255ae9034237c7f06 SoftHSM 52332
lithio.fr KSK ready waiting for ds-seen 512 13 5ffbb6208c612c0a0d93982fe4c536ea SoftHSM 39514
La nouvelle ZSK est en état active, signifiant qu'elle signe bien les enregistrements DNS.
La nouvelle KSK est en état ready, signifiant qu'elle est "visible" par tous les résolveurs. Elle indique waiting for ds-seen car elle attend qu'on lui indique avoir bien publié son enregistrement DS dans la zone parente avant de passer à la suite.
L'ancienne KSK est en état retire, signifiant qu'elle ne signe plus de ZSK mais est toujours publié, car il reste peut-être des signatures faites par elle dans la zone. Elle indique waiting for ds-gone car elle attend qu'on lui indique avoir bien retiré son enregistrement DS de la zone parente avant de passer à la suite.
Du coup il est l'heure d'envoyer l'enregistrement DS de la nouvelle KSK à la zone parente, on l'exporte via cette commande :
# ods-enforcer key export --zone lithio.fr --ds
;retire KSK DS record (SHA256):
lithio.fr. 3600 IN DS 65035 8 2 4c802e413e7b093caff490689e71473c9f3ee28588e321c712c2049fb2e5c643
;ready KSK DS record (SHA256):
lithio.fr. 3600 IN DS 39514 13 2 c4b686b30885167f7235bfb15ddde14c8fde379cd53f95e0b37bf33fbaeecf14
Il nous a exporté les 2 DS : celui de l'ancienne KSK et de la nouvelle. On prend celui de la nouvelle et on le transmet à la zone parente, fr dans mon cas, via son bureau d'enregistrement par exemple. Pour le moment on conserve bien l'ancien DS dans la zone parente, il ne faut pas encore le supprimer.
Et on attend encore (oui avec DNSSEC il faut surtout être patient·e).
Interlude Infomaniak
Normalement ce type de rollover aurait dû me prendre moins de 3 jours, mais comme le démontre les dates dans l'article cela m'a en réalité pris un peu plus de 5 jours.
Quand j'ai voulu transmettre le DS de la nouvelle KSK à la zone parente, l'API d'Infomaniak qui est mon bureau d'enregistrement m'a répondu « Incorrect values, the zone can not be signed with the registry. ». Pourtant tout était bon dans le formulaire sur l'interface web.
J'ai donc dû ouvrir un ticket auprès d'Infomaniak pour signaler le problème. Leur solution : désactiver DNSSEC sur ma zone (sans me consulter avant) et me dire de recommencer ! Heureusement que ce n'est pas une zone sensible dont dépendent des tests pour lesquels DNSSEC est important en production. Donc j'ai recommencé en remettant en place mes deux DS (ancienne et nouvelle KSK), super ça fonctionne.
Mais plus tard, au moment de supprimer le DS de l'ancienne KSK, rebelote : impossible de le supprimer de la zone parente, avec le même message d'erreur. Il disparait bien de l'interface d'Infomaniak mais pas de la zone parente.
Je commente donc le ticket pour indiquer que le souci n'est pas résolu. Leur solution : une personne chez eux a manuellement supprimé l'ancien DS de la zone fr. Bon c'est sympa, mais je leur ai tout de même demandé s'iels comptent régler réellement le souci de manière durable et si cette bogue est spécifique à la zone fr. Car si cela perdure ça voudrait dire qu'à chaque roulement de KSK je devrais ouvrir un ticket pour qu'un humain fasse le boulot de l'API.
Mise à jour du 4 janvier 2024 : Infomaniak m'a répondu "The developers should have fixed the problem definitely." donc normalement tout est rentré dans l'ordre.
Étape 3 : Suppression du DS de l'ancienne KSK de la zone parente
Nous revoilà donc le 2 janvier 2024 vers 13h26 UTC. On peut voir grâce à DNSViz que les 2 DS sont bien présents dans la zone parente et indique chacun une KSK. Un magnifique plat de spaghetti !
Schéma DNSSEC de lithio.fr au 2024-01-02 13h26 UTC
On peut donc indiquer à OpenDNSSEC que le DS de la nouvelle KSK est bien visible en lui indiquant le keytag de la clé :
# ods-enforcer key ds-seen --zone lithio.fr --keytag 39514
1 KSK matches found.
1 KSKs changed.
On obtient alors l'état suivant :
# ods-enforcer key list --verbose --all --zone lithio.fr
Keys:
Zone: Keytype: State: Date of next transition: Size: Algorithm: CKA_ID: Repository: KeyTag:
lithio.fr KSK retire waiting for ds-gone 2048 8 f88116e010c6c1dd671df83048f877f8 SoftHSM 65035
lithio.fr ZSK active 2024-01-02 16:31:01 1024 8 52b72c5dca75405d283fec212376cd21 SoftHSM 35184
lithio.fr ZSK active 2024-01-02 16:31:01 512 13 e2c00c50ee72dbb255ae9034237c7f06 SoftHSM 52332
lithio.fr KSK active 2024-01-02 16:31:01 512 13 5ffbb6208c612c0a0d93982fe4c536ea SoftHSM 39514
Notre nouvelle KSK est à présent en état active, signifiant qu'elle est bien utilisée pour signer.
On peut donc supprimer l'ancien enregistrement DS de la zone parente, attendre le TTL de la zone parente et l'indiquer à OpenDNSSEC avec le keytag de la clé :
# ods-enforcer key ds-gone --zone lithio.fr --keytag 65035
1 KSK matches found.
1 KSKs changed.
On obtient alors l'état suivant :
# ods-enforcer key list --verbose --all --zone lithio.fr
Keys:
Zone: Keytype: State: Date of next transition: Size: Algorithm: CKA_ID: Repository: KeyTag:
lithio.fr KSK retire 2024-01-03 14:50:39 2048 8 f88116e010c6c1dd671df83048f877f8 SoftHSM 65035
lithio.fr ZSK active 2024-01-03 14:50:39 1024 8 52b72c5dca75405d283fec212376cd21 SoftHSM 35184
lithio.fr ZSK active 2024-01-03 14:50:39 512 13 e2c00c50ee72dbb255ae9034237c7f06 SoftHSM 52332
lithio.fr KSK active 2024-01-03 14:50:39 512 13 5ffbb6208c612c0a0d93982fe4c536ea SoftHSM 39514
L'ancienne KSK est toujours en état retire. On peut voir via DNSViz que seul le nouveau DS est dans la zone parente et qu'il pointe vers la nouvelle KSK.
Schéma DNSSEC de lithio.fr au 2024-01-03 11h58 UTC
Puis vers 13h50 UTC le même jour, l'ancienne ZSK passe également en état retire :
# ods-enforcer key list --verbose --all --zone lithio.fr
Keys:
Zone: Keytype: State: Date of next transition: Size: Algorithm: CKA_ID: Repository: KeyTag:
lithio.fr KSK retire 2024-01-04 06:50:39 2048 8 f88116e010c6c1dd671df83048f877f8 SoftHSM 65035
lithio.fr ZSK retire 2024-01-04 06:50:39 1024 8 52b72c5dca75405d283fec212376cd21 SoftHSM 35184
lithio.fr ZSK active 2024-01-04 06:50:39 512 13 e2c00c50ee72dbb255ae9034237c7f06 SoftHSM 52332
lithio.fr KSK active 2024-01-04 06:50:39 512 13 5ffbb6208c612c0a0d93982fe4c536ea SoftHSM 39514
Elle n'est plus utilisée pour signer les enregistrements DNS de notre zone, on peut voir via DNSViz que nous avons atteint l'état final. Notre rotation des clés est terminée.
Schéma DNSSEC de lithio.fr au 2024-01-03 13h52 UTC
Conclusion
Finalement tout ceci est facile à comprendre malgré l'apparente complexité de DNSSEC.
Faire ça régulièrement permet de ne pas perdre la main et de mettre à jour ses connaissances sur les algorithmes de signature et sur DNSSEC en général.
Vous pouvez commenter en envoyant un mail via ce bouton (votre adresse ne sera pas publié).
Commenter par mail