[doc, mail] DANE + changements mineurs
Arnaud Daby-Seesaram
parent
b534e7e561
commit
306ede8d8e
|
|
@ -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
|
émetteur car plus d'un service est souvent requis (/e.g./ un serveur DNS
|
||||||
autoritaire, un serveur Web, ...).
|
autoritaire, un serveur Web, ...).
|
||||||
|
|
||||||
* TODO SPF
|
* SPF
|
||||||
|
|
||||||
- [[https://www.rfc-editor.org/rfc/rfc7208][SPF]],
|
- [[https://www.rfc-editor.org/rfc/rfc7208][SPF]],
|
||||||
- [[https://en.wikipedia.org/wiki/Sender_Policy_Framework][Page Wikipédia]].
|
- [[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
|
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~.
|
service externe tourne sur la même VM et est ~postfix-policyd-spf-python~.
|
||||||
|
|
||||||
|
|
||||||
* TODO SRS
|
* TODO SRS
|
||||||
|
|
||||||
- [[https://www.libsrs2.org/srs/srs.pdf][Papier]],
|
- [[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
|
solution pour le moment (ni au Cr@ns, ni personnellement), nous ne pouvons pas
|
||||||
commenter sur le sujet.
|
commenter sur le sujet.
|
||||||
|
|
||||||
* TODO DANE
|
* DANE
|
||||||
|
|
||||||
- [[https://www.rfc-editor.org/rfc/rfc6698][RFC]],
|
- [[https://www.rfc-editor.org/rfc/rfc6698][RFC]],
|
||||||
- [[https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities][Page Wikipédia]].
|
- [[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.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue