298 private links
Article très détaillé et très bien expliqué sur la mise en place d'un service DoT et DoH (respectivement DNS over TLS et DNS over HTTPS) et sur son fonctionnement, avec en prime des outils pour vérifications, analyse, suivi de l'état du système.
Merci encore à Bortzmeyer.
Puisque j’oublie souvent, voilà une méthode simple pour générer un champ SSHFP :
ssh-keygen -r <fqdn> -f <file>
en remplaçant "<fqdn>" par votre nom de domaine avec le nom de votre machine, comme "foo.example.com", et "<file>" par le chemin vers le fichier.
Pour recréer à partir d’OpenSSL https://unix.stackexchange.com/questions/121880/how-do-i-generate-sshfp-records#133957
Voici un document au format PDF pour aider à la mise en place et configuration du système DNSSEC avec le logiciel BIND9.
Copie : https://thican.net/~thican/bind_dnssec-guide.pdf
Voir aussi le manuel de référence d'administration de BIND9 (version 9.10.2) : ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.pdf
(copie : https://thican.net/~thican/bind_Bv9ARM.pdf)
Ce petit billet me sert principalement de garde-mémoire, je ne vais donc pas détailler ce qu'est le champ TLSA et son but ; ceci est détaillé dans la RFC6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” (https://tools.ietf.org/html/rfc6698)
Principalement, ce qui nous intéresse, c’est de fournir soit l’empreinte de la clef, soit l’empreinte du certificat ; c’est ce que définit le champ "Selector" (section 2.1.2).
Remarque : j’ai considéré par défaut que nous sommes dans le cas d’un "DANE-EE: Domain Issued Certificate", valeur "3" du champ "Certificate Usage" (section 2.1.1).
-
Si vous souhaitez uniquement donner l’empreinte de votre clef (valeur "1" dans le "Selector Field"), utilisez les valeurs "3 1 1" et "3 1 2" respectivement pour les hashs SHA256 et SHA512 ;
Ensuite, vous pouvez au choix déterminer les hashs (SHA256 et SHA512) à partir de la clef privée (n’oubliez pas l’option -pubout, voir openssl pkey(1))
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha256
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha512
OU, en alternative, déterminer les hashs (SHA256 et SHA512) à partir d'un certificat (c’est ainsi de cette façon qu’un tiers peut vérifier)
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha256
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha512 -
Par contre, si vous souhaitez fournir l’empreinte complète du certificat, utilisez les valeurs "3 0 1" et "3 0 2" respectivement, et exécutez :
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha256
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha512
Ensuite, créer une entrée DNS dans votre zone, en suivant la sémantique suivante :
<port>.<protocole>.<nomdedomaine> IN TLSA <X Y Z> <hash>
Par exemple, pour avoir le hash du certificat pour le service HTTPS, donc le protocole TCP qui répond au port 443, sur la machine foo.example.com, le résultat est "_443._tcp.foo.example.com." (ne pas oublier le dernier point à la fin).
Et pour les valeurs <X Y Z> :
X → https://tools.ietf.org/html/rfc6698#section-2.1.1 : la valeur "3" indique que ce sont des informations avec le certificat le plus proche.
Y → https://tools.ietf.org/html/rfc6698#section-2.1.2 : exporter la clef est plus simple, de ce que j’ai compris.
Z → https://tools.ietf.org/html/rfc6698#section-2.1.3 : "1" pour le hash SHA256, "2" pour le hash SHA512.
Concernant le hash, n'oubliez pas de supprimer les doubles-points (par exemple : echo $hash | tr -d ':')
Sources :
Autre outil (mais en anglais) concernant les noms de domaine, en particulier pour la mise en place du DNSSEC.
Très pratique pour détecter les erreurs.
Un outil du site web de l'AFNIC (registar français pour les TLD en .fr) pour analyser les erreurs possibles contenu dans une zone. Très pratique, car il permet aussi de vérifier les plages de temps de l'entrée SOA.
Pour info concernant le SOA, voici les règles de l'AFNIC :
- Le numéro de série suit la forme AAAAMMJJnn.
- Le champ 'refresh' du SOA est entre 1H et 2D.
- Le champ 'retry' du SOA est entre 15M et 1D.
- Le champ 'expire' du SOA est entre 1W et 100W.
- Le champ 'minimum' du SOA est entre 3M et 1W.
tout en vérifiant : - Le champ 'retry' du SOA inférieur à celui du 'refresh'.
- Le champ 'expire' est au moins 7 fois celui du 'refresh'.
Ce tutoriel permet de connaître et de mettre en place d'autres moyens pour déployer sa clef publique, en plus des traditionnelles méthodes avec les serveurs de clefs, ou le fichier sur votre serveur HTTP.
Ainsi, j'ai pu mettre en place ce système, en utilisant la méthode de téléchargement par URL.
Il suffit donc de rajouter l'option "auto-key-locate pka" dans votre fichier de configuration (~/.gnupg/gpg.conf), et ainsi, en m'écrivant un courriel (si votre client courriels le permet), ma clef publique sera téléchargée.
Knot, une alternative dans le monde des serveurs DNS, comme BIND.
Rapide et performant.