Enregistrement DNS de type CAA

Introduction

Défini en 2013 par la RFC6844, le CAA est un type d’enregistrement DNS qui permet aux propriétaires de sites de préciser quelles autorités de certification (CA) sont autorisées à émettre des certificats contenant leurs noms de domaine.

Quel est l’intérêt

Par défaut, chaque autorité de certification publique est autorisée à émettre des certificats pour tout nom de domaine dans le DNS public, à condition qu’elle valide le contrôle de ce nom de domaine.

L’enregistrement CAA offre aux détenteurs de domaines un moyen de réduire ce risque d’une émission de certificat non souhaitée en intégrant une étape de confirmation/refus aux autorités de certification dans leurs processus d’émission de certificat.

L’intérêt d’un tel système prend tout son sens suite à l’essor des certificats générés « à la volée ». Ces types de certificat sont émis sans aucune vérification sur le titulaire du domaine. Il est aisé de demander un certificat pour n’importe quel domaine.

L’enregistrement CAA permet donc au propriétaire d’un nom de domaine de spécifier les autorités de certification qu’il autorise à émettre un certificat.

Notez que l’utilisation de DNSSEC pour authentifier les enregistrements CAA est fortement recommandée mais non requise (RFC 6844, section 4.1). Du point de vue sécurité, vous devez absolument utiliser le DNSSEC pour obtenir une requête/réponse authentique des CA à votre serveur DNS.

Enfin, cet enregistrement n’est pas encore obligatoire, mais je vous encourage à le mettre en oeuvre avant de personnes malveillantes n’utilisent cet oubli à leur avantage.

Principe de fonctionnement

Quand une autorité de certification reçoit une demande de certificat, elle vérifie le domaine afin de déterminer si un enregistrement de type CAA existe. Si un enregistrement existe et que la CA est bien autorisée, alors l’autorité de certification génère le certificat. Si l’enregistrement CAA spécifie une CA différente, alors la génération du certificat est refusée. A ce jour, si l’enregistrement CAA n’existe pas, alors la CA est autorisée à générer le certificat.

Structure d’un enregistrement CAA

Chaque enregistrement CAA est constitué d’un octet « flag » et d’une paire étiquette-valeur appelée une propriété.

Plusieurs propriétés peuvent être associées au même nom de domaine en publiant plusieurs enregistrements CAA à ce nom de domaine.

Un seul « flag » est défini: le « issuer critical » est représenté par le bit le plus significatif de l’octet. S’il est activé (c’est-à-dire que l’entier résultant est égal ou supérieur à 128) l’autorité de certification qui n’est pas à même de comprendre ou de mettre en œuvre l’étiquette de cet enregistrement doit refuser de délivrer un certificat pour le domaine.

Outre le « flag », trois mots clés sont définis:

  • issue : autorise une autorité (via son nom de domaine spécifié dans le champ « value ») à délivrer des certificats pour le domaine sur lequel l’enregistrement pointe
  • issuewild : est similaire à issue et vise les émissions de certificats wildcard
  • iodef : indique un moyen pour les autorités de signaler une demande de certificat ou un souci avec celle-ci

Pour interdire l’émission d’un certificat, il faut spécifier « ; » comme valeur pour le mot clé issue ou issuewild.

Exemple de mise en oeuvre

Qui prend en charge l’enregistrement CAA ?

Si vous voulez publier un enregistrement CAA, le logiciel (ou le fournisseur) de DNS de votre domaine doit prendre en charge le CAA.
Le site https://sslmate.com/caa/support vous indique quels logiciels et fournisseurs DNS prennent en charge la CAA. En France, les 2 principaux fournisseurs, Gandi et OVH, supportent le CAA.

Mise en oeuvre

Pour illustrer notre exemple, nous allons utiliser le domaine example.com et l’autorité de certification Let’s Encrypt.
Le nom de domaine d’identification de Let’s Encrypt pour la CAA est letsencrypt.org.

Si votre fournisseur est répertorié, vous pouvez utiliser le générateur d’enregistrements CAA de sslmate pour générer un ensemble d’enregistrements CAA répertoriant les CA que vous souhaitez autoriser.

Voici les captures :

Enfin, vous publiez votre politique CAA en ajoutez les enregistrements CAA suivants au DNS de votre domaine. Votre DNS doit être hébergé par un service qui prend en charge la CAA.

Plusieurs formats sont rencontrés :
– générique (utilisé par Google Cloud DNS, Route 53, DNSimple, et les autres services DNS hébergés) :

Name Type Value
example.com. CAA 0 issue ";"
0 issuewild "letsencrypt.org"
0 iodef "mailto:support@example.com"
  • standard (utilisé par BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0) :
Name Type Value
example.com. IN CAA 0 issue ";"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:support@example.com"
  • legacy RFC 3597 (utilisé par BIND <9.9.6, NSD <4.0.1, Windows Server 2016) :
Name Type Value
example.com. IN TYPE257 \# 8 000569737375653B
example.com. IN TYPE257 \# 26 0009697373756577696C646C657473656E63727970742E6F7267
example.com. IN TYPE257 \# 33 0005696F6465666D61696C746F3A737570706F7274406578616D706C652E636F6D

Résolution des problèmes

Comment vérifier

Commande DIG

Une requête de test avec dig montre les enregistrements :

$ dig @1.1.1.1 celea.org caa +dnssec +multi +noauthority +noadditional

; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 celea.org caa +dnssec +multi +noauthority +noadditional
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45743
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;celea.org. IN CAA

;; ANSWER SECTION:
celea.org. 1800 IN CAA 0 iodef "mailto:mathias@celea.org"
celea.org. 1800 IN CAA 0 issuewild "letsencrypt.org"
celea.org. 1800 IN CAA 128 issue "letsencrypt.org"
celea.org. 1800 IN RRSIG CAA 13 2 1800 (
20210520000000 20210429000000 7209 celea.org.
9CmiaEqazRE272NDI8SgfY4iaWFI+Du13j0bTDWAzsCn
H6Y4dI7VT2UfG/vWNuLdUPSpXGkhwee0MOSMoQJcFA== )

;; Query time: 96 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: ven. mai 07 17:43:20 CEST 2021
;; MSG SIZE rcvd: 258

Services en ligne

Vous pouvez aussi utiliser un service en ligne https://caatest.co.uk/ :

Erreur CAA liée au fournisseur DNS

Avant l’émission d’un certificat, l’autorité de certification vérifie les enregistrements CAA. Parfois des erreurs sont renvoyées même pour des domaines n’ayant pas défini d’enregistrements CAA. Lorsqu’une erreur est obtenue, la CA ne peut pas savoir si elle est autorisée à émettre un certificat pour le domaine concerné. En effet, des enregistrements CAA pourrait être présents interdisant l’émission, mais qui ne sont pas visibles à cause de l’erreur.

Certains fournisseurs DNS qui ne sont pas familiers avec la CAA répondent initialement aux rapports de problèmes par « Nous ne prenons pas en charge les enregistrements CAA ». Votre fournisseur DNS n’a pas besoin de prendre spécifiquement en charge les enregistrements CAA. Il doit seulement répondre par une réponse NOERROR pour les types de requêtes inconnus (y compris le CAA). Renvoyer d’autres opcodes, y compris NOTIMP, pour les types de requête inconnus est une violation de la RFC1035, et doit être corrigé.

SERVFAIL

L’erreur les plus courantes rencontrée est SERVFAIL. Le plus souvent, cela indique un échec de la validation DNSSEC.
Si vous obtenez une erreur SERVFAIL, votre première étape devrait être d’utiliser un débogueur DNSSEC comme dnsviz.net. Si cela ne fonctionne pas, il est possible que vos serveurs de noms génèrent des signatures incorrectes uniquement lorsque la réponse est vide. Et les réponses CAA sont le plus souvent vides.

Si vous n’avez pas activé DNSSEC et que vous obtenez un SERVFAIL, la deuxième raison la plus probable est que votre serveur de noms faisant autorité a renvoyé NOTIMP, ce qui est une violation de la RFC1035. Il devrait plutôt renvoyer NOERROR avec une réponse vide. Si tel est le cas, contactez de votre fournisseur DNS.

Enfin, les SERVFAILs peuvent être causés par des pannes au niveau de vos serveurs de noms faisant autorité. Vérifiez les enregistrements NS de vos serveurs de noms et assurez-vous que chaque serveur est disponible.

Timeout

Parfois, les requêtes CAA n’aboutissent pas. Même après plusieurs tentative, le serveur de noms faisant autorité ne répond pas. Le plus souvent, cela se produit lorsque votre serveur de noms est protégé par un pare-feu mal configuré qui rejette les requêtes DNS avec des QTYPES inconnus. Contactez alors votre fournisseur DNS.

Les champs QTYPE apparaissent dans la partie question d’une requête. Les QTYPES sont un sur-ensemble de TYPEs, donc tous les TYPEs sont des QTYPEs valides

Surveillez votre domaine

Même si vous publiez un enregistrement CAA, une autorité de certification non conforme peut ignorer vos enregistrements CAA. Utilisez Cert Spotter pour surveiller les journaux de Certificate Transparency afin d’être averti si cela se produit.

Navigateurs sécurisés et respectueux de la confidentialité

Un navigateur sécurisé et respectueux de la vie privée est essentielle. Il est notre point d’entrée sur la toile, et il se doit de protéger notre navigation. Mais un navigateur sécurisé est important car ils présentent une importante surface d’attaque et peuvent être compromis par différentes techniques. Les navigateurs disposent aussi de nombreuses informations privées (historique de navigation, identifiant / mot de passe, informations auto complétées …). Ils peuvent aussi transmettre vos informations de localisation géographique, vos paramètres (logiciels, matériels …). Le choix et la mise à jour régulière d’un navigateur est essentiel.

Je vous partage une liste non exhaustive de navigateur répondant aux critères de sécurité et de respect de la vie privée. Vous pouvez proposer d’autres (avec quelques informations) en commentaire.

Tor Browser

Le navigateur Tor est une version renforcée de Firefox qui utilise également le réseau Tor par défaut (mais cela peut être désactivé).

https://www.torproject.org/

Firefox (modifié)

Firefox est un excellent navigateur pour la confidentialité et la sécurité après avoir effectué quelques modifications. Sa personnalisation (paramètres et extensions) peut vous donner le niveau de sécurité et de confidentialité appréciable.

https://www.mozilla.org/fr/firefox

Iridium

Iridium est un navigateur basé sur Chromium configuré pour la confidentialité et la rapidité. Je vous encourage à lire le wiki qui détaille les différences en terme de sécurité et de confidentialité avec Chromium : https://github.com/iridium-browser/tracker/wiki

https://iridiumbrowser.de/

Brave

Brave est un navigateur basé sur chrome qui est très axé sur la confidentialité. Par défaut, il bloquera les publicités et les trackers. Il est également personnalisable, rapide et doté d’une protection intégrée contre le fingerprinting.

https://brave.com/

Gnu IceCat

GNU IceCat est un autre fork de Firefox, créé par les personnes du projet de logiciel libre GNU. IceCat répond à la définition de «logiciel libre» et inclut également certains modules complémentaires (notamment GNU LibreJS. Plus d’infos https://www.gnu.org/philosophy/javascript-trap.html ) et des paramètres par défaut afin de renforcer la vie privée (Https-Everywhere et SpyBlock).

https://www.gnu.org/software/gnuzilla/

Cette liste n’est pas exhaustive. Par exemple, j’aime bien le navigateur Vivaldi, mais sans extensions et réglages appropriés, il ne peut répondre aux critères et son code n’est pas disponible.

Firefox : le chant du cygne

Les statistiques d’utilisation de Firefox ne sont pas bonnes. Des choix contestables, des performances parfois juste acceptables et une stratégie pour le moins incompréhensible.

Mais une dernière partie de ses soutiens risque de quitter le navire. Ces utilisateurs utilisent Firefox pour améliorer le respect de la vie privée et disposer d’une certaine garantie concernant la neutralité du net.

Hors voilà que Firefox prône la censure. De quel droit un éditeur ou même un acteur privé se permet de censurer qui que ce soit. Le fait de bloquer une personne une organisation ne doit-être le fait que d’une décision de justice. J’ai perdu confiance dans Firefox. Adieu Firefox !

Quelles informations les entreprises technologiques géantes collectent-elles auprès de vous?

quelles informations les entreprises technologiques géantes collectent-elles auprès de vous?

Jean-Baptiste Kempf, Videolan, parle de startup nation – à écouter

Comment envoyer des SMS à partir d’un Raspberry ?

Une carte Raspberry peut-être utilisée pour de nombreux cas d’usage et nous allons l’utiliser pour envoyer des SMS.

Philippe vous a préparé un article détaillé expliquant la mise en oeuvre avec une carte GSM Nadhat et une Rapsberry 3B+ sous Debian : Raspberry et SMS

Et un autre article sur ce même sujet mettant en jeu Node-RED pour ajouter un peu de programmabilité : Envoyer un SMS sur changement d’état d’une GPIO

Bonne lecture et bon développement

OpNSense : configurer WireGuard VPN en vidéo

Une vidéo très bien faite expliquant l’installation et la configuration pas à pas du VPN Wireguard sur le firewall OPNSense.

SIP – PFSense : Comment résoudre une perte d’enregistrement

Les postes sont localisés sur un site et passe par internet pour accéder au serveur de téléphonie VoIP SIP qui est situé derrière un PFSense.

Vous constatez un défaut d’enregistrement de vos téléphones SIP pendant plusieurs minutes, ceux-ci affichant un message « No service » ou « prov. server failed ».

Vous devez surement faire face à un timeout d’état de la table NAT du firewall PFSense. En effet, ce timeout doit-être inférieur à la fréquence de ré-enregistrement des postes SIP !

Les délais d’expiration UDP par défaut dans PFSense sont trop faibles pour certains services VoIP. Si les téléphones fonctionnent principalement, mais se déconnectent de manière aléatoire, il faut modifier les options d’optimisation du pare-feu sur les mettant sur « Conservateur » sous Système> Avancé, onglet Pare-feu / NAT.

Un système de keep-alive (ou autrement un ping SIP avec un message OPTION) ou une réinscription sur le poste téléphonique pendant une durée plus faible, environ 20 à 30 secondes, peut également aider, et est souvent une meilleure solution.

Fermeture des commentaires

La gestion des commentaires étant une activité demandant du temps du fait du nombre trop important de spammer, j’ai pris la décision de supprimer les commentaires de mon blog.

Je souhaite aussi migrer le blog en pages statiques pour réduire mon empreinte carbone (et plein de petits trucs sympas, une meilleure sécurité …) et les commentaires devaient être externalisés ou supprimés. Je les ai supprimé n’étant pas un fan de système de type Disqus.

Par contre, certains échanges étant intéressant, j’ai ouvert une communauté reddit pour cela : https://www.reddit.com/r/blog_des_telecoms

Sparrow : Wazo PBX sur Raspberry Pi

Le jeune projet Sparrow propose un build non officiel de l’architecture armhf de plateforme Wazo. Il vous permet d’héberger un système téléphonique VoIP Open Source complet et programmable sur un Raspberry Pi. Un autre projet qui semble maintenant peu maintenu permettait d’installer un système Xivo ou Wazo (mais en 18.03) sur Raspberry, Raspvivo.

J’apprécie particulièrement cette architecture, car elle permet de manière efficace et avec une faible consommation de faire fonctionner des services performants. Dans la même veine, mais j’en parlerai dans un autre article, j’ai fait fonctionner la plateforme de class 4 de Wazo sur un cluster Kubernetes à base de cartes Raspberry.

J’aime bien la définition de Wazo :

Wazo Platform is an Open Source project writen in python who gets the best from Asterisk and Kamailio to build a telecom platform.

Sparrow peut fonctionner sur n’importe quel système avec une architecture armhf. Il est néanmoins recommandé 2 Go de RAM et une carte SD rapide industrielle d’une taille d’au moins 16 Go. Attention au volume des messages de logs, des backups et surtout des messages vocaux, le chiffre annoncé étant un minimum !

La dernière version est basée sur Wazo 20.01. C’est la seconde version de Sparrow, la première release datant du 3 janvier 2020.

L’ensemble des fonctionnalités de Wazo Platform sont disponibles sous Sparrow  sauf le codec OPUS qui n’est pas fonctionnel. Mais cela n’impactera que les applications WebRTC. De plus, du fait des faibles ressources d’une carte raspberry PI, les capacités de transcodage sont fortement limitées. Veillez bien à correctement configurer vos paramètres SIP.

Le process d’installation est assez simple. Après avoir installé la distribution Raspbian en version minimale (basée sur debian Buster, les dernières releases de Wazo ne supportant plus Jessie mais uniquement Buster), l’installation se déroule en quelques simples lignes de commandes. Le process prend du temps, profitez en pour prendre un bon café et marcher un peu !

Je n’ai pas eu le temps de faire des tests de performances, mais on peut facilement estimer que pour une petite entreprise équipée de 1 ou 2 T0 (2 à 4 appels simultannés) ou une utilisation en homelab, le Raspberry sera suffisament performant.

La documentation est accessible ici : https://sparrow.b5.pm/docs

et le repo github : https://github.com/benasse/sparrow

Merci Benoit Stahl pour ce superbe travail qui met en valeur la force d’une communauté Open Source.