Des e-mails qui arrivent : tous les contrôles d'internet.nl et leur raison

LE SCORE

Comment vérifier la configuration

internet.nl est un test gratuit de l'État néerlandais et d'organisations de l'internet. Deux volets nous concernent : site web et domaine de messagerie. Chaque contrôle donne un résultat public de réussite ou d'échec.

Vous pouvez effectuer vous-même les tests sur ave17.com ; la feuille de route décrit la publication prévue de résultats datés.

Le score mesure la configuration, pas le comportement. Un résultat parfait démontre qu'un domaine est difficile à usurper et que ses messages circulent chiffrés. Il ne dit rien de la réponse des personnes à leurs e-mails.

QUI L'A ENVOYÉ

SPF, DKIM et DMARC dans l'ordre utile

Ces trois dispositifs répondent ensemble à une question : le message provient-il vraiment du domaine ? Souvent déployés dans le mauvais ordre, ils équipent de nombreux domaines qui restent usurpables.

SPF

Liste les machines autorisées à envoyer pour le domaine. Simple mais insuffisant seul : le transfert fait échouer le contrôle, car le serveur de transfert n'est pas dans la liste.

DKIM

Signe le message lui-même et résiste au transfert. Nous signons avec deux clés, RSA et Ed25519, car certains destinataires ne comprennent pas encore la seconde et nous préférons ne pas choisir.

DMARC

Indique au destinataire quoi faire si les deux premiers échouent et demande un rapport. Notre réglage est p=reject : rejeter. Toute option moins stricte reste une demande polie ignorée par la plupart des expéditeurs.

L'ordre efficace est DKIM, puis SPF, puis DMARC en observation jusqu'à ce que les rapports soient calmes, enfin reject. Passer directement à reject révèle publiquement les systèmes de l'organisation qui envoyaient des e-mails à son insu.

COMMENT ELLE A CIRCULÉ

Un chiffrement impossible à retirer

Les serveurs de messagerie proposent le chiffrement opportuniste depuis vingt ans. Un attaquant intermédiaire peut retirer l'offre et faire revenir les deux serveurs au texte clair sans qu'ils le remarquent. Deux mécanismes ferment cette faille ; la plupart des domaines ne les ont pas.

MTA-STS

Une politique publiée en HTTPS disant : "Toujours utiliser TLS avec ces noms d'hôte ; sinon ne pas livrer." Nous la publions en mode enforce, le seul mode qui agisse.

DANE

Le certificat attendu du destinataire est publié dans le DNS et signé par DNSSEC. L'expéditeur peut ainsi le vérifier contre le domaine plutôt que contre une liste d'autorités de certification. Nous publions des enregistrements TLSA pour submission, submissions, IMAPS et le serveur d'échange lui-même.

DNSSEC

Des signatures sur les réponses DNS elles-mêmes. Sans elles, un attaquant peut réécrire en transit tous les enregistrements précédents. DANE les exige donc, et toutes nos zones sont signées.

MTA-STS et DANE se recoupent volontairement. Le premier est simple à déployer et fait confiance aux certificats web ; le second est plus difficile et fait confiance à DNSSEC. Un domaine équipé des deux reste protégé quel que soit le système atteint par l'attaquant.

LA PARTIE WEB

Ce que demande le test du site

Le volet web vérifie surtout la même idée : empêcher la dégradation d'une connexion et le remplacement de son certificat.

• IPv6 sur le site et ses serveurs de noms, accessibles avec le même contenu qu'en IPv4
• DNSSEC sur la zone, pour empêcher la réécriture de l'adresse elle-même
• HTTPS avec chiffrements modernes, HSTS et aucune possibilité de dégradation
• DANE aussi sur le certificat web, ce que presque personne ne fait
• CAA fermé, pour que seule l'autorité nommée puisse émettre pour le domaine
• En-têtes de sécurité empêchant l'intégration dans un cadre ou le détournement par détection du contenu

LES DEUX POINTS À COMPRENDRE

Là où le score peut tromper

Premièrement : DMARC en p=reject sur un domaine n'envoyant jamais de messages est trivial. Un domaine actif n'y arrive qu'après des semaines d'analyse des rapports. Même score, travail entièrement différent. Demandez aux prestataires lequel ils ont réalisé.

Deuxièmement : DANE exige une vérification par le destinataire, ce que beaucoup ne font pas. Le publier protège auprès de ceux qui vérifient, sans coût auprès des autres. Il ne garantit pas qu'un message donné ait circulé chiffré. Personne ne peut le garantir.

Autre limite, inconfortable : rien de cela n'empêche un message convaincant provenant d'un domaine ressemblant au vôtre. Ce problème se résout par les personnes plutôt que les enregistrements.

CE QUE CELA A COÛTÉ

Honnêtement

Un jour pour les bons enregistrements du premier domaine, puis environ vingt minutes par domaine grâce au modèle obtenu. La configuration ne prend pas le plus de temps : il faut deux semaines de rapports DMARC avant de passer sûrement à reject, et ce délai ne s'achète ni ne se presse.

Nous l'exploitons nous-mêmes plutôt que via un prestataire de messagerie, d'où cette description. Choisir un prestataire est tout à fait raisonnable ; demandez-lui néanmoins les enregistrements cités.