8 règles d'or pour un bon déploiement de DNSSEC et DANE photo

8 règles d’or pour bien déployer DNSSEC et DANE

29 March 202207 décembre 2015 by Matt Biscay · Lecture: 4 minutes

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)

In lycée with Mister B. : roadrunner

29 March 202204 décembre 2015 by Matt Biscay · Lecture: 1 minute

Cette scène se passe à la fin d’un cours de seconde.

Alors qu’il ne reste que quelques secondes avant la sonnerie, une élève m’interpelle et m’annonce qu’elle m’a vu dans la rue.

Je souris, l’écoute, et obtiens ceci :

Hilarité générale de la classe. Ils aiment bien se moquer gentiment de leurs professeurs. J’ai bien ri avec eux. Et, je l’avoue, je n’ai rien eu d’intelligent à redire… juste rire !

They just pwned me ! :)

Serveur dédié : mise en place du protocole DANE

12 September 202102 décembre 2015 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, je vous montre comment mettre en place le protocole DANE sur votre serveur.

En pré-requis, votre domaine doit:

Cela prend environ 20 minutes à configurer, auxquelles s’ajouteront quelques heures afin que la résolution DNS avec les changements soit complète.

DANE : l’authentification TLS sans autorité de certification

DANE (DNS-based Authentication of Named Entities) est un protocole qui permet aux certificats X.509 – généralement utilisés pour TLS – d’être liés au DNS en s’appuyant sur DNSSEC.

L’IETF a défini DANE dans la RFC 6698 comme un moyen d’authentifier des clients TLS et des serveurs sans passer par une autorité de certification (AC).

Cette démarche s’enregistre dans une logique de sécurisation des accès clients-serveurs pour d’une part sécuriser les requêtes DNS effectuées depuis les postes clients au travers des protocoles/mécanismes DNSSEC et TLS, et d’autre part mieux sécuriser les accès chiffrés des clients vers le serveurs.

Le chiffrement TLS est actuellement basé sur des certificats qui sont délivrés par des Autorités de Certification (AC ou Certificate Authority, CA en anglais).

Or, ces dernières années ont vu un certain nombre d’AC qui ont souffert de sérieux problèmes d’intrusions et de failles de sécurité, ce qui a permis la délivrance de certificats pour des sites très connus à des personnes qui ne détenaient pas ces domaines.

Faire confiance à un large nombre d’Autorités de Certification peut être un problème, étant donné que n’importe laquelle d’entre elles, si elle est compromise, pourrait délivrer un certificat pour n’importe quel nom de domaine.

Le protocole DANE permet à l’administrateur d’un nom de domaine de certifier les clés utilisées dans les clients ou serveurs TLS de ce domaine en les insérant au niveau du DNS.

DANE a donc besoin que les enregistrements DNS soient signés avec DNSSEC pour que son modèle de sécurité fonctionne.

De surcroit, DANE permet à l’adminstrateur du domaine de spécifier quelle autorité de certification est autorisée à délivrer des certificats pour une ressource particulière, ce qui résoud le problème des autorités de certification qui sont capables de délivrer des certificats pour n’importe quel nom de domaine.

Serveur dédié : mise en place du protocole DANE photo 3

Les enregistrements TLSA

DANE utilise des enregistrements TLSA, qui incluent l’empreinte du certificats X.509 qui protège un nom de domaine.

Nous devons tout d’abord générer cet enregistrement TLSA en nous basant sur le certificat installé sur notre serveur. Ensuite, cet enregistrement TLSA sera ajouté à notre zone DNS.

← Précédent Suivant →