La plateforme MECSA a deux objectifs. D'une part, son objectif est d'obtenir une vision globale de la sécurité et de la protection de la vie privée appliquées par les fournisseurs de messagerie lorsqu'ils délivrent ou reçoivent des messages électroniques. La plateforme prête une attention plus particulière aux communications entre les serveurs email (MTAs).
Pour atteindre cet objectif, la plateforme MECSA évalue 7 critères différents (StartTLS, validation de certificats x509, SPF, DKIM, DMARC, DANE, DNSSEC), précédemment identifiés comme les standards visant à renforcer la sécurité et le respect de la vie privée des communications email entre MTA.
D'autre part, la plateforme MECSA vise à devenir un outil utilisé par les utilisateurs finaux ainsi que les administrateurs système pour les raisons suivantes. Elle vise à sensibiliser les utilisateurs finaux sur l'importance de la sécurité et de la protection de la vie privée des communications email entre les MTA. Pour cela, la plateforme permet aux utilisateurs finaux d'évaluer leur fournisseurs d'emails afin d'obtenir un rapport complet de cette évaluation. Dans le cas des administrateurs système, la plateforme a pour objectif d'être un outil aidant à améliorer les niveaux de sécurité et de protection de la vie privée offerts par leur(s) service(s).
Vous pouvez envoyer vos commentaires et vos questions à :
jrc-mecsa@ec.europa.eu
Le score Envoi Confidentiel évalue la capacité d'un fournisseur d'email à empêcher la lecture des messages (envoyés et reçus) par une tierce partie capable d'écouter le canal de communication ou d'usurper l'identité du destinataire.
Le score d'Hameçonnage et d'Usurpation d'Identité mesure la facilité d'un fournisseur d'email à identifier les messages email envoyés par des domaines non légitimes (ces messages sont très probablement contrefaits).
Le score d'Intégrité des Messages évalue la capacité d'un fournisseur d'email à détecter les messages modifiés (le contenu reçu est différent de celui envoyé), ainsi que la capacité de prouver que les messages n'ont pas été modifiés.
Plusieurs entités sont impliquées dans les communications email. Il y a au moins les entités suivantes: expéditeur, destinataire, client (User Agent) de l'expéditeur, client du destinataire, client de transfert d'email (Mail Transfer Agent - MTA) de l'expéditeur, client de transfet d'email du destinataire. Dans certains cas, d'autres clients de transfert d'email peuvent être utilisés pour atteindre la destination finale. Le client est l'application permettant aux utilisateurs d'envoyer/recevoir des emails (p.ex. Outlook, Thunderbird...), alors que le client de transfert d'email est le serveur de messagerie à proprement parler.
Les expéditeurs et destinataires contrôlent le client de messagerie dans la plupart des cas. Plusieurs options de configuration peuvent être définies affectant directement la sécurité et la protection de la vie privée des communications email. C'est le cas par exemple du chiffrement de bout en bout (end-to-end encryption), TLS implicite ou explicite... Toutefois, les utilisateurs finaux n'ont aucune information sur la sécurité et la protection de la vie privée assurées par le fournisseur d'email dans le cadre des communications email entre les serveurs MTA.
Plusieurs exemples d'attaques associées aux critères évalués par la plateforme MECSA sont décrits dans ce qui suit. Cette liste n'a pas pour objectif d'être complète mais simplement d'illustrer quelques situations dans lesquelles un adversaire peut prendre le dessus.
Le système de messagerie email suppose par défaut que tous les acteurs impliqués dans les communications ainsi que les canaux de communication sont fiables et sécurisés. En réalité, ce n'est guère le cas. Par exemple, les communications entre serveurs SMTP pour la distribution des emails sont transmises via Internet et sont par conséquent susceptibles d'être interceptées par des tiers.
En pratique, cela signifie qu'en l'absence de mesures de sécurité spécifiques, telles que StartTLS par exemple, les emails envoyés et reçus, y compris les fichiers joints, pourraient être lus et copiés par des tiers. Il n'y a aucune certitude que la confidentialité de la communication est assurée.
L'Hameçonnage et l'Usurpation d'Identité sont parmi les principales vulnérabilités inhérentes à la conception des systèmes de communication par email. Lors d'une usurpation d'identité, l'attaquant est capable de se faire passer pour un utilisateur légitime d'email et envoyer des emails au nom de la cible.
Dans la plupart des scénarios, l'utilisateur légitime ne réalisera jamais qu'une personne a usurpé son identité. Même une usurpation d'identité basique peut être extrêmement difficile à détecter pour un utilisateur lambda puisque l'email frauduleux est indistinguable d'un email légitime. Toutefois, les utilisateurs avancés et les professionnels de la sécurité peuvent déterminer que l'adresse email a été usurpée en analysant les en-têtes de messagerie insérés par les serveurs SMTP impliqués dans la communication.
À l'instar du scénario du vol d'identité, un attaquant peut également profiter du manque de protection de l'intégrité des données pour modifier le contenu des emails légitimes qui sont envoyés ou reçus par les utilisateurs.
Même si dans ce cas précis aucun vol d'identité n'est effectué et que l'email reçu par l'utilisateur a effectivement été envoyé par le destinataire, son contenu a pu être modifié par un attaquant. Cela est également vrai pour les éventuelles pièces jointes de l'email, tel un fichier PDF, en plus de son contenu.
