6068 links
  • GuiGui's Show

  • Home
  • Login
  • RSS Feed
  • Tag cloud
  • Picture wall
  • Daily
Links per page: 20 50 100
page 1 / 1
  • Premier couac DANE TLSA dont je suis la cause

    Je mets en œuvre DANE TLSA depuis bientôt 10 ans, y compris pour mes serveurs de courriels personnels, en envoi comme en réception.

    Il y a six ans, j'ai rencontré un problème avec DANE TLSA : pour un destinataire, le certificat x509 présenté par le serveur de courriels différait de celui consigné dans l'enregistrement DNS TLSA, donc mon serveur emails ne parvenait pas à délivrer un courriel.



    En juin 2026, c'est moi qui ai bouleté et qui ne pouvais plus recevoir des courriels émis par des gens qui font correctement de l'email en 2026.

    Le 20 juin 2026, précisément. Jour du renouvellement de mon certificat x509 annuel autosigné qui expirerait le lendemain.

    Involontairement, j'ai ajouté un caractère dans l'enregistrement TLSA, le rendant invalide.



    Dans un bref premier temps, je me suis aperçu de rien puisque les courriels automatiques envoyés par plusieurs administrations (pour la 2FA, pour accuser réception, etc.) me sont parvenus.

    Cependant, le même jour, je constate que je ne reçois pas les bulletins de sécurité de Debian. (Je les consulte également par RSS, d'où j'ai pu constater un écart, alors que, usuellement, le courriel précède amplement la publication web.) Puce à l'oreille.

    Je consulte le journal de mon serveur emails : plusieurs émetteurs, dont Debian, initient une connexion, mais la poignée de main TLS échoue.

    Le comportement traditionnel est de réémettre sans TLS (= en clair). Or, là, je ne constate pas cela, les réémissions ont lieu en TLS.

    Cela signifie que les émetteurs recourent à MTA-STS ou à DANE TLSA.

    Je ne mets pas en œuvre MTA-STS, car la politique doit être diffusée via un serveur web (donc un serveur emails doit savoir causer HTTP, ce que je trouve ridicule), et que DANE prodigue en sus la validation d'un certificat x509.

    Donc, il y a un dysfonctionnement de DANE. Comme j'ai changé de certificat x509, je comprends immédiatement que j'ai dû foirer l'enregistrement DNS DANE TLSA, et je le corrige. À systématiser : vérifier la validité TLSA après un renouvellement de certif.

    Environ une heure après, je reçois les emails. Une heure, car c'est la durée de vie de mes enregistrements DNS. Hé, oui, le délai de 24 h que tout le monde rabâche n'est plus d'actualité depuis bien longtemps. Je rappelle également que le DNS ne propage pas.



    Donc Debian, Infomaniak, et une connaissance geek recourent à DANE TLSA. \o/ Donc attaque par repli (retrait de TLS par un attaquant) impossible.

    Je n'attendais pas ça d'Infomaniak, c'est bien. Un acteur de cette envergure qui fait avancer les choses, c'est bien.

    Infomaniak et Debian publient également un enregistrement DANE TLSA (pour les courriels entrants chez eux) \o/ :
    _25._tcp.mta-gw.infomaniak.ch. 300 IN TLSA 3 1 1 01BBBC3A65E5F2067AA43DBAB107583E1A14567ED2569C63445D21E1 DE556926

    _25._tcp.bendel.debian.org. 600 IN TLSA 3 1 1 9E8248347B06C8F8F7D24800207525642F5E5DA2CE52F08B22298010 A4389875
    _25._tcp.bendel.debian.org. 600 IN TLSA 3 1 1 7D8AC6B95A22EFBE727768523798BC914AFA9F22A10F7847023E2D8A B982D23

    Les administrations, notamment celle chargée de la protection des données à caractère personnel, qui ne mettent pas en œuvre DANE TLSA et dont le serveur de courriels n'implémente pas TLS 1.3 (de 2018 !), je vous juge très fort, à défaut d'être surpris.

    29/07/2026 10:24:02 - permalink -
    - http://shaarli.guiguishow.info/?AjOEOQ
Links per page: 20 50 100
page 1 / 1
Mentions légales identiques à celles de mon blog | CC BY-SA 3.0

Shaarli - The personal, minimalist, super-fast, database free, bookmarking service by the Shaarli community