La plateforme MECSA vérifie la sécurité et la confidentialité offertes par les fournisseurs d'email, en vérifiant s'ils supportent l'ensemble des standards identifiés dans une publication précédente.
La commande StartTLS [RFC3207, RFC7817] est une extension du Simple Mail Transfer Protocol [RFC5321] (SMTP) utilisé pour activer le chiffrement TLS (Transport Layer Security) [RFC5246] lors des communications entre le client et le serveur (expéditeur et destinataire). Suivant le protocole SMTP, le serveur annonce sa prise en charge de la commande StartTLS dans la réponse à une commande EHLO. Le client envoie la commande StartTLS pour indiquer son souhait d'initier une négociation TLS. Au cours de cette négociation, deux actions se produisent:
Exemple de communications SMTP extraites de RFC3207:
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.example.com
S: 250-mail.imc.org offers a warm hug of welcome
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: EHLO mail.example.com
S: 250-mail.imc.org touches your hand gently for a moment
S: 250-8BITMIME
S: 250 DSN
Les certificats X.509 sont utilisés pour valider l'identité et/ou la clé publique des serveurs (par exemple lors de la négociation TLS). Les certificats X.509 (parfois aussi appelés certificats SSL (Secure Socket Layer)) prennent leur nom du format de certificat adopté par Netscape lors de la conception de la première version du protocole SSL. Un certificat X.509 agit comme un conteneur pour certaines informations spécifiques concernant l'identité à laquelle le certificat a été délivré et l'identité de l'émetteur. Parmi les champs les plus importants stockés dans un certificat X.509, nous trouvons:
Version: version du format X.509 utilisé dans le certificat.
Numéro de série: numéro unique attribué par l'émetteur.
Information sur l'algorithme: description de l'algorithme utilisé pour signer électroniquement le certificat.
Nom distinctif de l'émetteur: nom de l'émetteur (typiquement une autorité de certification) du certificat.
Période de validité du certificat: début et fin de validité du certificat.
Nom distinctif du sujet: nom du sujet à qui le certificat a été délivré
Informations sur la clé publique du sujet: clé publique du propriétaire du certificat.
Le format du certificat est établi dans la norme RFC5280. Les moyens d'y accéder et de le traiter sont définis dans la norme RFC4210. RFC3739 définit le terme certificat qualifié, qui est lié à la directive européenne sur les signatures électroniques (Directive 1999/93/EC).
Sender Policy Framework [RFC7208, RFC7372] (SPF) est un protocole qui permet aux fournisseurs d'email d'annoncer une liste d'hôtes (adresses IP) autorisés à livrer des emails en son nom. Suivant le protocole SMTP, lorsqu'un client s'identifie lui-même (commandes HELO ou EHLO), il doit indiquer un nom d'hôte ou une adresse IP, et lorsqu'il initie la transmission d'un email, il doit envoyer la commande MAIL-FROM en indiquant l'adresse e-mail de l'expéditeur.
Ces deux champs, le nom d'hôte (ou l'adresse IP) contenu dans la commande HELO (ou EHLO) et l'email contenu dans la commande MAIL-FROM doivent être confrontés à l'enregistrement SPF publié par le fournisseur d'email correspondant afin de vérifier si le client est autorisé à envoyer des e-mails au nom de ce fournisseur d'email. Les enregistrements SPF sont publiés sous forme d'enregistrements TXT dans le domaine DNS du fournisseur d'email. Exemple: enregistrement SPF du domaine et.dcslab.eu:
v=spf1 a mx ip4:139.191.36.5 -all
v=spf1 version
a accepter l'IP si contenu dans un enregistrement A de et.dcslab.eu
mx accepter l'IP si contenu dans un enregistrement MX pour et.dcslab.eu
ip4:139.191.36.5 accepter l'IP si elle fait partie de l'intervalle donné
-all échec par défaut
DomainKeys Identified Mail [RFC6376] (DKIM) est un mécanisme d'authentification utilisé pour vérifier l'origine légitime d'un e-mail.
Ce mécanisme utilise des signatures numériques pour vérifier l'identité de l'hôte expéditeur. Un fournisseur d'email génère une paire de clés publique/privée pour un domaine et publie la clé publique en tant qu'enregistrement DNS. Chaque fois qu'il envoie un email, il le signe en utilisant sa clé privée. Une fois que le serveur destinataire reçoit le message, il peut valider la signature grâce à l'enregistrement publié. Ce faisant, le destinataire peut vérifier deux éléments :
Exemple d'en-tête DKIM dans un email reçu :
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=et.dcslab.eu; s=102016; t=1476792726; bh=HS0o/CkH/ZCpSrfolDyH8IR5hX6n8GxWLzY59OuvtWo=; h=Date:From:From:Subject; b=OOlOO/jae1cPF2pllIF2QiENPJdUvGL70FdPMkKa89qkhXdvr D89eZwK6OZzEdLYncAbYCrEVi58jFqFAjKBcASrRpjSQXTJX6hM cRNZ295/1xp8vR/J9CQl9baqGxhYWID8Z0OrN/tbwXNN2UiNTmk MIm90UDJHdQnw/rd9rX4=
Dans l'exemple précédent, pour retrouver la clé permettant de vérifier la signature DKIM, l'enregistrement DNS de type TXT doit être obtenu pour le domaine : 102016._domainkey.et.dcslab.eu.
Domain-based Message Authentication, Reporting and Conformance [RFC7489] (DMARC) est un mécanisme permettant aux fournisseurs de détailler les procédures à appliquer concernant SPF et DKIM.
En particulier, il permet aux fournisseurs d'email d'indiquer ce qu'ils doivent faire lorsqu'un message n'est pas conforme à SPF ou DKIM (rejeter, mettre en quarantaine, rien) et d'indiquer une adresse électronique où envoyer les rapports.
Il peut également être utilisé pour définir une politique d'acceptation/rejet d'un certain pourcentage de messages ayant échoués, permettant un déploiement progressif de ces technologies. Exemple, enregistrement DMARC du domaine et.dcslab.eu:
v=DMARC1; p=reject; rua=mailto:dmarc_reports@et.dcslab.eu
v=DMARC1 Version linguistique de DMARC
p=reject politique à appliquer par le destinataire: aucune/quarantaine/rejet
rua=mailto.. adresse où envoyer les rapports
DNS-based Authentication of Named Entities [RFC6698, RFC7218, RFC7671, RFC7672] (DANE) est un mécanisme qui lie les certificats X.509 (ou clés publiques) aux services, en spécifiant le port, le protocole et le domaine où le service est en cours d'exécution. La liaison du certificat et du service est publiée en tant qu'enregistrement DNS de type TLSA. DANE peut être appliqué à n'importe quel service. Dans le cas particulier des communications par courrier électronique, le RFC7672 décrit l'application de DANE et de DNSSEC aux communications (SMTP) entre les MTA. En particulier, le RFC7672 recommande d'utiliser DANE-TA ou DANE-EE avec DNSSEC.
Un enregistrement TLSA contient 4 valeurs: le champ d'utilisation, le champ de sélection, le champ de type de correspondance et les données associées. Les différents champs d'un enregistrement TLSA sont décrits ci-dessous.
Par exemple, l'enregistrement TLSA d'un serveur SMTP actif sur le port par défaut (25) pour l'hôte mx.example.com, utilisant DANE-EE et publiant le hash SHA2-256 de la clé publique (SPKI) du certificat en bout de chaine serait :
_25._tcp.mx.example.com TLSA 3 1 1 1cf...6ab
Usage-Field
Selector-Field: Spécifie le contenu du certificat X.509 à faire correspondre aux données associées
Matching-Type-field: Indique le format des données associées
Associated-Data:
Domain Name System Security Extensions [RFC4033, RFC6014, RFC6840] (DNSSEC) est un protocole utilisé pour authentifier les réponses des serveurs DNS. Ce mécanisme est utile pour empêcher les applications d'utiliser des enregistrements DNS altérés ou falsifiés. Le protocole est capable d'authentifier un ensemble d'enregistrements DNS grâce à la vérification d'une signature cryptographique associée. Pour atteindre son objectif, DNSSEC introduit des types d'enregistrements supplémentaires :
Pour activer DNSSEC, le serveur doit avoir deux paires de clés (publiques et privées). La première paire contient les clés de signature privée et publique de la zone (ZSK) et la deuxième paire contient les clés de signature de clé (KSK). Avec la ZSK privée, le serveur signe numériquement tous les RRSET sur le DNS (groupe d'enregistrements DNS du même type, par exemple MX, TXT, etc.) et stocke leurs signatures dans un enregistrement RRSIG. La ZSK publique est nécessaire pour vérifier leurs signatures et elle est publiée en tant qu'enregistrement DNSKEY. L'enregistrement DNSKEY du ZSK public est signé avec le KSK privé. Le KSK public est également publié en tant qu'enregistrement DNSKEY, et il est auto-signé, c'est-à-dire qu'il est signé avec le KSK privé. Cette séquence d'étapes établit la confiance dans la zone.
Puisque le DNS est un système hiérarchique, la confiance à l'intérieur d'une zone doit être liée à la zone parente. Pour ce faire, le serveur hache le KSK public et publie le hash en tant qu'enregistrement DS dans sa zone parente.
