spf 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.

Authentification des emails entrants chez SFR

Avec la montée en puissance des campagnes de phishing, l’authentification des messages entrants pour un FAI est un enjeu important pour protéger ces utilisateurs.

Comme évoqué précédemment, il existe différentes normes pour authentifier les messages sortant. Depuis septembre 2011, SFR a décidé de vérifier l’authenticité des emails entrants grâce à la norme SPF et étudierai l’implémentation prochaine de DKIM.

La norme SPF permet aux propriétaires de domaine d’indiquer, grâce à un enregistrement DNS, quelles sont les serveurs autorisés à utiliser ce domaine pour expédier des emails.

Voyons, grâce à deux exemples concrets, comment SFR traite et filtre les emails entrants grâce à SPF :

  • Dans un premier temps, essayons d’envoyer un email à SFR à partir de l’IP 82.165.131.171 avec le domaine dlnw01.com pour lequel on aurait paramétré l’enregistrement SPF strict suivant v=spf1  ip4:82.165.131.172  -all

    Le résultat est un refus de livraison a cause du SPF hardfailed : 

    HELO dlnw01.com
    250 msfrf2207.sfr.fr
    MAIL FROM:<dlnw@dlnw01.com>
    554 5.7.1 <dlnw@dlnw01.com>:  Sender address rejected: Please%see%http://spf.pobox.com/why.html?sender=dlnw%40dlnw01.com&ip=82.165.131.171&receiver=msfrf2207 : Reason: mechanism
  • Maintenant, voyons une tentative d’envoi d’un email à SFR à partir de l’IP 82.165.131.171 avec le domaine dlnw01.com pour lequel on aurait paramétré l’enregistrement SPF souple suivant v=spf1  ip4:82.165.131.172  ~all

    Le résultats est la livraison du mail en boite spam avec dans l’entête le header suivant : 

    X-tag-spam: SPF SoftFail

Pour protéger son identité, il est important pour un annonceur d’authentifier ces domaines, mais l’exemple si dessus montre qu’il est nécessaire de le faire correctement pour éviter un rejet de connexion ou une livraison en boite spam.

De plus, l’authentification a pour but d’assurer l’authenticité de l’expéditeur et même authentifier correctement, les emails ne sont pas assurés d’arriver en boite de réception principale.

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