DNSSec impose un roulement régulier de ta clef de signature.
En fait de tes 3 clefs de signature :
la signature de zone, renouvelée toutes les 2h
la ZSK, renouvelé tous les 90j, qui signe ta zone DNS
la KSK, renouvelé ×ばつ par an
Ces clefs ne doivent absolument pas sortir de ton parc et sont extrêmement critiques. Il est donc impossible de mettre ça sur ton serveur DNS primaire, qui est en DMZ et exposé sur le net, donc potentiellement attaquable.
Pour parvenir à tenir le renouvellement toutes les 2h de manière sécurisée, on utilise ce qu’on appelle un shadow master. Ton DNS primaire devient en réalité un secondaire, et tu montes un serveur DNS OpenDNSSec bien à l’abri dans ton parc derrière une tonne de firewall et isolé de l’Internet (air-gap, et potentiellement éteint 99% du temps).
À chaque signature de zone, le shadow master signale à ton DNS « primaire » qu’il y a eu un changement de zone, et ton primaire va alors télécharger la nouvelle zone via le mécanisme AXFR de DNS.
Si tu dois modifier ta zone DNS, tu dois alors intervenir sur le shadow master, demander la resignature de la zone, qui sera poussée sur ton primaire.
Le problème avec LE, c’est que ton frontal web va du coup se mettre à renouveller des certificats (peu importe la sécurité du token ou de la clef du certificat ici), et que le changement de ces certificats nécessitent de mettre à jour les entrées TLSA de ton DNS.
Sauf que pour faire ça, il faudrait qu’il ait accès à ton shadow master. Qui par définition ne doit jamais être mis en contact avec une machine de ta DMZ. Donc pas de ton frontal web. Donc impossible de mettre à jour TLSA. Donc impossible d’utiliser LE.
Pour l’idée des paquets Debian ou autres, ce n’est pas possible avec HTTPs, puisqu’il faudrait être capable de synchroniser l’installation des paquets sur X machines (dont des machines hors DMZ pour DNSSec) lors du renouvellement du certificat : déploiement du certificat sur tous les HTTPd (backend, reverse et HA proxy), modification des vhosts HTTPd concernés pour HPKP, changement des TLSA pour DANE (impossible car hors DMZ, sans connectivité, voire éteint).
Sans synchro, on pourrait se retrouver avec des certificats différents fonction du reverse sur lequel tu tombes après le HA proxy ou si tu passes par IPv4 (reverse) ou IPv6 (backend), avoir un certificat présenté différent de celui indiqué dans les entêtes HPKP ou les entrées TLSA, etc.
(Pour HPKP, c’est même encore plus problématique puisqu’il faut prévoir le rollover de l’empreinte au moins 60j avant la modification réelle. Donc déjà avoir le prochain certificat à dispo.)
NB: Pour les taquins qui signaleraient que DNSSec impose des rollovers de 2h alors que LE en impose des de 90j, le choix des 2h est une obligation technique et non un choix arbitraire.
DNS est basé sur UDP, et ne peut donc pas envoyer de paquets de plus de 548 octets, donc DNSSec est obligé d’utiliser des tailles de clefs volontairement faibles (1024 bits et moins) et des algos de hash faibles (SHA-1) pour pouvoir faire rentrer tout ça dans UDP.
On doit donc renouveller TRÈS fréquement les clefs et les hash pour éviter un bruteforce de la zone qui prendrait peu de temps vu les algos utilisés.
De plus, DNS embarque nativement un mécanisme de synchronisation (NOTIFY pour signaler un changement, AXFR pour récupérer les modifications), ce qui facilite le montage d’un shadow master hors DMZ, alors que LE/HTTPS/X.509 n’en possède pas.
Et enfin, DNSSec peut être fait totalement offline sur le shadow master (qui est du coup un vrai shadow master) alors que LE impose une connectivité internet et l’accès aux frontaux web (donc pas de shadow master hors DMZ possible).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 0.
C’est plus compliqué que juste le lien avec LE.
DNSSec impose un roulement régulier de ta clef de signature.
En fait de tes 3 clefs de signature :
Ces clefs ne doivent absolument pas sortir de ton parc et sont extrêmement critiques. Il est donc impossible de mettre ça sur ton serveur DNS primaire, qui est en DMZ et exposé sur le net, donc potentiellement attaquable.
Pour parvenir à tenir le renouvellement toutes les 2h de manière sécurisée, on utilise ce qu’on appelle un shadow master. Ton DNS primaire devient en réalité un secondaire, et tu montes un serveur DNS OpenDNSSec bien à l’abri dans ton parc derrière une tonne de firewall et isolé de l’Internet (air-gap, et potentiellement éteint 99% du temps).
À chaque signature de zone, le shadow master signale à ton DNS « primaire » qu’il y a eu un changement de zone, et ton primaire va alors télécharger la nouvelle zone via le mécanisme AXFR de DNS.
Si tu dois modifier ta zone DNS, tu dois alors intervenir sur le shadow master, demander la resignature de la zone, qui sera poussée sur ton primaire.
Le problème avec LE, c’est que ton frontal web va du coup se mettre à renouveller des certificats (peu importe la sécurité du token ou de la clef du certificat ici), et que le changement de ces certificats nécessitent de mettre à jour les entrées TLSA de ton DNS.
Sauf que pour faire ça, il faudrait qu’il ait accès à ton shadow master. Qui par définition ne doit jamais être mis en contact avec une machine de ta DMZ. Donc pas de ton frontal web. Donc impossible de mettre à jour TLSA. Donc impossible d’utiliser LE.
Pour l’idée des paquets Debian ou autres, ce n’est pas possible avec HTTPs, puisqu’il faudrait être capable de synchroniser l’installation des paquets sur X machines (dont des machines hors DMZ pour DNSSec) lors du renouvellement du certificat : déploiement du certificat sur tous les HTTPd (backend, reverse et HA proxy), modification des vhosts HTTPd concernés pour HPKP, changement des TLSA pour DANE (impossible car hors DMZ, sans connectivité, voire éteint).
Sans synchro, on pourrait se retrouver avec des certificats différents fonction du reverse sur lequel tu tombes après le HA proxy ou si tu passes par IPv4 (reverse) ou IPv6 (backend), avoir un certificat présenté différent de celui indiqué dans les entêtes HPKP ou les entrées TLSA, etc.
(Pour HPKP, c’est même encore plus problématique puisqu’il faut prévoir le rollover de l’empreinte au moins 60j avant la modification réelle. Donc déjà avoir le prochain certificat à dispo.)
NB: Pour les taquins qui signaleraient que DNSSec impose des rollovers de 2h alors que LE en impose des de 90j, le choix des 2h est une obligation technique et non un choix arbitraire.
DNS est basé sur UDP, et ne peut donc pas envoyer de paquets de plus de 548 octets, donc DNSSec est obligé d’utiliser des tailles de clefs volontairement faibles (1024 bits et moins) et des algos de hash faibles (SHA-1) pour pouvoir faire rentrer tout ça dans UDP.
On doit donc renouveller TRÈS fréquement les clefs et les hash pour éviter un bruteforce de la zone qui prendrait peu de temps vu les algos utilisés.
De plus, DNS embarque nativement un mécanisme de synchronisation (NOTIFY pour signaler un changement, AXFR pour récupérer les modifications), ce qui facilite le montage d’un shadow master hors DMZ, alors que LE/HTTPS/X.509 n’en possède pas.
Et enfin, DNSSec peut être fait totalement offline sur le shadow master (qui est du coup un vrai shadow master) alors que LE impose une connectivité internet et l’accès aux frontaux web (donc pas de shadow master hors DMZ possible).