dkim Archives - DeliverNow

Gmail fait un pas de plus vers la généralisation de TLS

Gmail a toujours été à la pointe sur les questions d’authentification (SPF, DKIM, DMARC) et de cryptographie. Depuis la mise en place de Google Postmaster (lire notre article sur le sujet), il est par exemple possible de suivre le pourcentage d’email entrant et sortant de chez Gmail utilisant ou non TLS.

L’annonce qui a été faite par Google la semaine dernière concerne directement TLS. Pour rappel, TLS (Transport Layer Security) est le successeur de SSL (Secure Sockets Layer) et permet de garantir l’authenticité, la confidentialité et l’intégrité des données échangées sur les réseaux. Pour autant que deux serveurs emails puissent se parler dans ce langage, il est d’ailleurs possible d’utiliser cette technologie pour sécuriser les échanges d’email.

Des repères visuels pour les utilisateurs

Si Gmail supporte TLS depuis plusieurs années, la grande nouveauté vient du fait que la firme de Mountain View met maintenant en avant l’absence de cette technologie. En effet, lorsqu’un email arrive dans le webmail de Google sans avoir été chiffré par TLS, celui-ci présente un cadenas rouge à l’utilisateur.

cadenas

De la même manière, si un utilisateur est en train d’envoyer un email à un domaine ne supportant pas TLS, il sera averti par ce même cadenas rouge.

La volonté de booster l’utilisation du chiffrement TLS

En agissant de la sorte, Google veut clairement booster l’adoption de TLS pour l’ensemble des emails échangés. L’indication visuelle devrait inciter les annonceurs qui ne chiffrent pas encore leurs emails en sortie à le faire, par crainte d’une baisse de confiance de la part de leurs clients et prospects.

Continuer à mettre en avant l’authentification SPF et DKIM

L’autre changement mis en avant par Gmail est la modification de l’icône expéditeur lorsqu’il y a un problème avec l’authentification des emails (SPF et DKIM). Par contre, vu la sévérité de Gmail concernant les soucis d’authentification, nous risquons de rencontrer assez rarement cette icône en point d’interrogation, les emails mal authentifiés finissant rapidement en boîte spam.

auth

DeliverNow est en train de migrer tous ses clients vers TLS

Chez DeliverNow, nous avons pris acte de ces changements depuis plusieurs semaines et sommes en train de migrer nos clients PowerMTA afin que l’ensemble de leurs emails soient compatibles avec TLS. N’hésitez pas à nous contacter si vous désirez être accompagné sur le sujet.

SFR implémente DKIM pour authentifier les messages entrants

Depuis vendredi 30 novembre dernier, SFR authentifie les messages entrants grâce à la technologie DKIM. Pour le moment, les messages non-authentifié ou mal authentifié ne subissent pas de traitement particulier.

En regardant les en-têtes des messages envoyés à SFR, on constate l’apparition de l’en-tête Authentication-Results comprenant le résultat du test d’authentification ainsi que l’analyse de la politique ADSP publié par le propriétaire du domaine.

Je rappelle que l’authentification DKIM est basé sur une technologie de chiffrement des en-tête grâce à un système de clé privée / clé publique, la clé privé étant utilisée par le MTA de l’expediteur pour signer le message lors de l’envoi et la clé publique diffusée dans un enregistrement DNS et utilisée pour authentifier le message lors de sa réception.

Exemple d’enregistrement clé publique DKIM pour le domaine facebookmail.com :

dlnw$ dig s1024-2011-q2._domainkey.facebookmail.com TXT +short
"k=rsa; t=s; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLWnmo7aFBKfL4+mogTe/cXx6D4M
UF7VUM9O+nmXAcUP6jJh1RDgZuSJ/KKxo+KMpDiF5xnawr4p3N4eFruSZWFB1vtHgDiy3iPk
e/u0lmXB2PDQphFRJU4Raghm9e2duPfuSExbvSu9COWIoaz1vH/T+8zc0vuonClGuPfxoqhQID
AQAB"

ADSP est aussi un enregistrement DNS, placé sous l’enregistrement DKIM du domaine, et destiné à communiquer publiquement la politique de signature du domaine en question.

L’enregistrement ADSP peut prendre 3 valeurs :

  • all : tout les emails envoyés pour ce domaine sont signés.
  • discardable : tout les emails envoyés pour ce domaine sont signés, et si un message arrive non signés ou avec une signature non valide, le propriétaire du domaine encourage le destinataire à rejeter celui-ci.
  • unkown : tout ou partie des messages envoyés par ce domaine sont signés.

Etant donné l’actualité agité autour de DKIM, il est important de préciser que SFR authentifie tous les messages signés, quelque soit l’algorithme utilisé pour le cryptage et la longueur de la clé.

Pour le moment, l’authentification DKIM chez SFR est en mode écoute, cela signifie qu’aucune politique de filtrage n’est appliqué aux messages non-authentifié. Au début de l’année prochaine, SFR tiendra compte de la signature ADSP et appliquera ça propre politique aux messages non signés.

Mais concrètement, qu’est ce que cela apporte à l’écosystème email ?

Pour les marques, une signature DKIM valide et une politique ADSP stricte aura pour effet de protéger les domaines de la marque du phishing.

Pour les expéditeurs d’emails, cela signifie que DKIM prend une place un peu plus importante et qu’il est aujourd’hui indispensable de proposer à  ses clients d’authentifier ses emails grâce à cette norme.

Pour SFR, c’est une façon de rendre les boites aux lettres de leurs abonnés plus sûre, en utilisant les possibilités technologiques modernes tout en s’affichant comme un ISP responsable et coopératif dans l’écosystème email.

DMARC: un nouveau standard pour la protection des domaines

Le protocole SMTP est vieux et simple d’utilisation.
Il a été inventé avant 1980 pour permettre d’envoyer des courriers électroniques sur des réseaux privés.
Grâce au protocole SMTP natif, il est possible d’envoyer un email en utilisant l’adresse email expéditrice que l’on veut, cette possibilité a engendré des problèmes de fiabilité des communications électroniques avec notamment, l’apparition des campagnes de phishing. Pour remédier à cela, les opérateurs ont mis au point un concept permettant aux expéditeurs d’emails d’authentifier leurs messages.

L’authentification des emails a pour but  d’assurer aux destinataires que l’expéditeur est bien celui qu’il dit être.

Dans la pratique, cela a donné 4 normes :

  • SPF et SenderID, dont le principe est de placer un enregistrement TXT dans le DNS du domaine pour spécifier les IPs autorisées à émettre des emails depuis ce domaine. La norme SPF étant la norme commune basée sur le MAIL FROM du dialogue SMTP et dans le domaine des ReverseDNS des IPs expéditrices. Le SenderID est la déclinaison de Microsoft, qui elle est basée sur le domaine de l’adresse « PRA » dont Microsoft a breveté l’algorithme, ce qui limite donc son utilisation.
  • DomainKeys et DKIM, dont le principe est basé sur un système de cryptage clé publique / clé privée appliqué sur certains champs de l’entête du mail.  DomainKeys a été inventé par Yahoo et DKIM par la communauté internet, comme dans le cas précédent, c’est DKIM tend à s’imposer.

Mais il manquait une chose à ces dispositifs, une chose qui permettrait aux expéditeurs qui authentifient correctement leurs emails d’informer les destinataires afin que ceux-ci filtrent plus strictement les messages non-authentifiés qui, bien souvent, seraient du phishing. Un groupement d’acteurs importants tel que Google, Facebook, Microsoft, Yahoo et AOL se sont regroupés pour développer un nouveau dispositif qui permettrait de remédier à cela en créant la norme DMARC et en tentant de la standardiser auprès de l’IETF.

DMARC signifie littéralement « Domain-based Message Authentication, Reporting & Conformance » et permet aux annonceurs de protéger leur marque et leur domaine en spécifiant précisément aux FAI les traitements à réaliser aux messages non-authentifiés.


DMARC permet aux annonceurs de protéger leurs domaines en indiquant clairement aux FAI  la politique à adopter envers les emails dont les signatures SPF et/ou DKIM seraient en erreur. Ce qui, dans le cas, d’une implémentation parfaite, permet définitivement d’empêcher le phishing sur le domaine de l’annonceur. A mon sens, c’est une avancée considérable en terme de protection des domaines et de lutte contre le phishing. Une autre possibilités intéressante de DMARC pour un annonceur est la possibilité de recevoir des rapports de la part des FAI pour connaitre la proportion de messages authentifié et non-authentifié sur son domaine. Ce qui permet d’avoir une idée de phishing sur son domaine.

En tant qu’expéditeur, pour implémenter DMARC, il faut s’assurer d’abord d’avoir implémenter correctement SPF et DKIM puis publier un enregistrement DMARC dans le DNS en tant qu’enregistrement TXT pour la zone _dmarc.mondomain.com

Exemple pour le domaine delivernow.eu :

Domain                                  Type                       Record

_dmarc.delivernow.eu   TXT                         « v=DMARC1; p=none; sp=none; pct=100; rua=mailto:admin@delivernow.eu; ruf=mailto:failure@delivernow.eu; »

p= politique de traitement à appliquer aux emails dont l’authentification est en erreur, basé sur le domaine. valeurs possible : none, quarantaine ou reject

sp= politique de traitement à appliquer aux emails dont l’authentification est en erreur, basé sur les sous-domaine. valeurs possible : none, quarantaine ou reject

pct= pourcentage des mails à filtrer

rua= adresse qui recevra les rapports agrégés de la part du FAI

ruf= adresse qui recevra les rapports d’erreurs d’authentification au fil de l’eau (AFRF)

Il existe des attributs supplémentaire pour l’enregistrement DMARC, disponible dans les spécifications détaillé.

 

Aujourd’hui, seulement Gmail utilise DMARC pour protéger les messages entrant mais il faut s’attendre à d’autres implémentation dans l’année dont certainement Yahoo, AOL et Microsoft.

Visiter le site de DMARC :
http://dmarc.org/

Voir les specifications completes de DMARC :
http://www.dmarc.org/draft-dmarc-base-00-01.html

Voir un slide de présentation simplifié sur DMARC :
http://dmarc.org/presentations/DMARC_general_overview_20120130.pdf

 

Spamhaus lance un service de Whiteliste

La semaine dernière, le célèbre organisme de blackliste Spamhaus a lancé un service de whiteliste qui permettra aux opérateurs de messagerie de classifier les expéditeurs en 3 catégories : les bons, les mauvais et les inconnus.

Ceci permettra à ces opérateurs d’autoriser les messages émanant des serveurs connus comme bons, de bloquer les messages venant des expéditeurs connus comme mauvais et de continuer à filtrer les expéditeurs inconnus.

D’un point de vue technique, la whiteliste est dissocié en 2 catégories : une whiteliste d’IPs nommée SWL et une whiteliste pour les domaines nommée DWL basée sur une certification des domaines qui signent en DKIM.

La whiteliste est actuellement en version beta et il n’est pas possible de demander une inscription direct. Ne peuvent prétendre à un whitelistage pour le moment uniquement les personnes qui seraient invité par des acteurs déjà whitelisté.

Spamhaus indique cependant très clairement les catégories de société qui pourront prétendre à un whitelistage : les entreprises en direct, les banques, les cabinets d’avocats et financiers, les autorités, les gouvernements et les sevveurs d’emails transactionnel des compagnie aérienne, banque en ligne et site de commerce en ligne.

Ne serons pas éligible les expéditeurs d’emails en masse tel que les routeurs ou les sociétés de marketing en ligne, quelque soit leurs pratiques et leur politique antispam.

A mon sens, la popularité de Spamhaus dans le monde de l’antispam et leur rigueur légendaire donne à cette whiteliste une crédibilité importante.

Cliquez-ici pour vous rendre sur le site de la whiteliste Spamhaus