Vous avez sécurisé votre domaine avec DNSSEC et DANE ? Très bien ! Il a cependant quelques petites choses à garder à l’esprit pour anticiper les difficultés et bien gérer la maintenance.
De la rigueur dans la gestion des enregistrements DS (DNSSEC) et TLSA (DANE)
Les enregistrements au niveau du DNS sont à manipuler avec précaution, ce ne sont pas le genre de choses que l’on peut configurer une bonne fois pour toute. On ne publie pas des enregistrements DS (DNSSEC) et TLSA (DANE) par effet de mode.
Les zones DNSSEC doivent être signées régulièrement et les enregistrements TLSA mis à jour en cas de changement de certificats TLS. Si la maintenance n’est pas assurée correctement, le domaine risque d’être injoignable.
Automatiser la signature de la zone DNS
Vous devez absolument mettre en place un crontab qui signe votre zone DNS automatiquement et vous informe du bon fonctionnement de votre zone.
Mettre à jour les enregistrements TLSA avant la chaine de certificat du serveur
Vous devez absolument mettre à jour les enregistrements TLSA avant de mettre à jour la chaine de certificat du serveur (déploiement de nouvelles clés ou utilisation d’un nouveau certificat TLS issu par une autorité de certification).
Lorsque vous mettez à jour votre certificat, vous devez garder les anciens enregistrements TLSA dans votre fichier de zone et ajouter les nouveaux enregistrements TLSA.
Les anciens et les nouveaux doivent donc coexister, le temps que les enregistrements DNS soient mis à jour, après quelques TTLS (quelques jours seulement).
Par exemple, la key1 est déployée initialement sur le serveur :
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)On ajoute la nouvelle clé key2 pendant quelques jours, juste derrière la key1 :
_25._tcp.mail.example.com. IN TLSA 3 0 1
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)Après le déploiement de la key2, on supprime la key1 :
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)SMTP : choisir le bon type d’enregistrement TLSA
Pour le SMTP, l’usage du certificat pour l’enregistrement TLSA doit être soit DANE-TA(2) or DANE-EE(3). Les usages PKIX-TA(0) et PKIX-EE(1) ne sont pas supportés.
Un sélecteur et un hash TLSA valides
Attention à bien vérifier que le sélecteur TLSA est bien valide et que le hash de l’enregistrement TLSA est bien celui du certificat. Il vaut mieux extraire ce hash depuis le certificat TLS en ligne de commande.
Le hash TLSA doit être généré uniquement à partir de la forme binaire ASN.1 DER du certificat ou de la clé publique (au format SPKI) et non dans un autre format.
La disponibilité sélective de STARTTLS
La disponibilité sélective de STARTTLS n’est pas compatible avec DANE. Il faut donc s’assurer que STARTTLS est toujours activé ou que les enregistrements TLSA pour DANE ne sont pas publiés pour ce domaine.
Autoriser les requêtes TLSA dans le parefeu
Si le domaine est validé par DNSSEC, il faut s’assurer que le parefeu autorise les requêtes TLSA à joindre le serveur de nom de domaine, sur tous les types d’adresses, en IPv4 comme IPv6.
Implémentation partielle
DANE ne protège votre domaine que si le domaine est validé par DNSSEC, si tous les hôtes MX sont également dans des zones validées par DNSSEC (leurs enregistrements A/AAAA sont « sécurisés »), et tous les hôtes MX possèdent des enregistrements TLSA "_25._tcp".
La publication d’enregistrements TLSA pour DANE pour vos serveurs SMTP ne fait sens que si vous prévoyez à long terme de publier des enregistrements TLSA pour tous vos hôtes MX.
C’est comme cela que vous limiterez le nombre et l’impact d’attaques au niveau du transport SMTP (STARTTLS downgrade ou autres attaques).
Inspiré des Common Mistakes de Dane SMTP Validator.
Besoin d’un partenaire fiable pour votre projet WordPress/WooCommerce ? Je mets mon expertise à votre service pour des résultats concrets.
