diff --git a/critical/mail/normes.org b/critical/mail/normes.org index 7928149..1c5bede 100644 --- a/critical/mail/normes.org +++ b/critical/mail/normes.org @@ -54,7 +54,7 @@ Tous ce qui est discuté ci-dessous fonctionne de la manière suivante : émetteur car plus d'un service est souvent requis (/e.g./ un serveur DNS autoritaire, un serveur Web, ...). -* TODO SPF +* SPF - [[https://www.rfc-editor.org/rfc/rfc7208][SPF]], - [[https://en.wikipedia.org/wiki/Sender_Policy_Framework][Page Wikipédia]]. @@ -94,6 +94,7 @@ Lorsque ~redisdead~ (~MX~ du Cr@ns) reçoit un mail, nous demandons à un servic externe de vérifier le SPF (via la variable ~smtpd_recipient_restrictions~). Le service externe tourne sur la même VM et est ~postfix-policyd-spf-python~. + * TODO SRS - [[https://www.libsrs2.org/srs/srs.pdf][Papier]], @@ -216,7 +217,122 @@ protocole solution pour le moment (ni au Cr@ns, ni personnellement), nous ne pouvons pas commenter sur le sujet. -* TODO DANE +* DANE - [[https://www.rfc-editor.org/rfc/rfc6698][RFC]], - [[https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities][Page Wikipédia]]. + +Actuellement, pour vérifier un certificat ~C~ proposé par un serveur mail, il faut +faire confiance à un certificat racine, lequel est utilisé pour signer un autre +certificat (dit /certificat intermédiaire/), lequel est utilisé pour signer le +certificat ~C~. Pour vérifier ~C~, il faut (1) faire confiance au certificat racine +et (2) vérifier les deux signatures sus-mentionnées. + +DANE est une norme permettant aux propriétaires de domaines de déclarer quels +cetificats doivent être acceptés pour quels services. + +/Note/ : Cela n'est pas spécifique aux mails. + +** Implémentation (côté infrastructure émettrice) + +Pour mettre en place DANE, il suffit d'ajouter un champ DNS à sa zone : + +- Il faut que la zone soit signée DNSSEC. + +- Le champ à ajouter est : + + de type TLSA (TLS Authentiction?), + + de clef ~_port._protoL4.domain.tld~. + + de valeur ~x y z t~, où : + * ~x~ est appelé /certificatie usage/, + * ~y~ est appelé /selector/, + * ~z~ est appelé /matching type/, + * ~t~ est appelé /certificate associated data/. + +*** Format du champ TLSA. + +**** /Certificate usage/ + +L'objectif de ce champ est d'indiquer comment vérifier le certificat. + +| *Valeur* | *Signification* | +|--------+----------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0 | Le certificat doit être valide (root -> intermediate -> "cert"), et /associated data/ décrit l'un des certificats parents de "cert" | +| 1 | /associated data/ décrit "cert", et le certificat doit aussi être valide /wrt/. un certificat racine de confiance. | +| 2 | /associated data/ décrit un parent de "cert". Ce parent est supposé de confiance, et "cert" doit bien être son descendant. | +| 3 | /associated data/ décrit "cert". Le certificat n'a pas besoin d'être valide /wrt/. un certificat racine. Il a simplement besoin de correspondre à /associated data/. | + +**** /Selector/ + +Ce champ décrit ce qui est décrit par /associated data/. + +| *Valeur* | *Signification* | +|--------+-----------------------------| +| 0 | Tout le certificat. | +| 1 | Seulement la clef publique. | + +**** /Matching type/ + +Ce champ indique comment vérifier /associated data/ contre la donnée du certificat +(ou de la clef publique). + +| *Valeur* | *Signification* | +|--------+--------------------------------------------------------| +| 0 | /associated data/ doit être égal à la donnée. | +| 1 | /associated data/ doit être égal au sha256 de la donnée. | +| 2 | /associated data/ doit être égal au sha512 de la donnée. | +où "la donnée" est décrite par le /selector/ et le choix de certificat décrit par +le /certificate usage/. + +**** /Certificate associated data/ + +Chaîne de caractère au format hexadécimal. + + +*** Recommandation pour le Cr@ns + +À titre personnel, j'utilise des champs TLSA en ~3 0 1~. Je pense que le Cr@ns +peut faire la même chose (ou du ~3 0 2~). + +*** Mise en place + +Hypothèses : +- le serveur DNS accepte des mises à jour DNS dynamiques de la part du serveur + mail, +- le renouvellement du certificat utilise ~certbot~. + + +Mise en place : +- Dans la confguration ~certbot~, + + passer en challenge DNS-01 et : + * ~manual_auth_hook~ : un script mettant en place le challenge, + * ~renew_hook~ : script de déploiement du certificat, lequel *ajoute* un champ + TLSA et place le certificat à déployer dans un dossier "staging", + * ~manual_cleanup_hook~ : un script retirant le challenge ~acme~. +- Roll-over scheme : Un champ DNS a une durée de vie (TTL), généralement 1h. De + ce fait, les requêtes de chalmp TLSA peuvent être en retard d'une heure (au + plus). Il est done conseillé d'avoir le nouveau champ TLSA en place pendant + deux TTL avant de (1) mettre en place le nouveau certificat et (2) retirer le + vieux champ TLSA. + + Je propose de mettre en place un timer systemd qui serait activé "après + l'arrêt de certbot pour plus de 2 TTLs". Ce timer lancerait un service, lequel + aurait une condition d'activation "un certificat existe dans le dossier + staging". + + +*** Exemple + +#+begin_src dig + dig +short TLSA _25._tcp.nanein.fr + => 3 0 1 50E9221F066DCD1991ED9D3BA0AD10159F3585780F6FABBAE2942E43 37789FC8 +#+end_src + +** Implémentation (côté serveur mail destinataire) + +Côté serveur mail destinataire, la configuration est très simple (car nous +utilisons Postfix). Cela se fait principalement via les options suivantes : +- ~smtp_dns_supoprt_level~ (valeur ~dnssec~) +- ~smtp_tls_dane_insecure_mx_policy~ (valeur ~dane~) + +D'autres options de Postfix peuvent être utilisées pour permettre un contrôle +plus fin sur le comportement du service.