La sécurité est l’une de nos principales priorités, avec la confidentialité. Nous nous efforçons de fournir à nos utilisateurs l’expérience la plus sûre et la plus confidentielle possible lorsqu’ils utilisent Mailfence. De nombreux utilisateurs, tels que des journalistes ou des dissidents, utilisent notre service pour des communications sensibles. Ils sont souvent la cible de menaces permanentes et sophistiquées. Au cours des dernières années, nous avons publié plusieurs nouvelles fonctionnalités pour améliorer la sécurité de tous les utilisateurs de Mailfence.
De la DANE à la MTA-STS, en passant par la WKD et la VKS, découvrez comment nous avons procédé pour améliorer la sécurité de vos données.
DANE et MTA-STS pour améliorer la sécurité
Pourquoi vous devez y avoir recours
DNS-based Authentication of Named Entities (DANE) et Mail Transport Agent Strict Transport Security (MTA-STS) sont deux protocoles distincts qui traitent principalement du même problème, communément appelé attaque par repli. En termes simples, un attaquant peut supprimer la couche de chiffrement pendant le transport des emails. Il est donc important de disposer d’un mécanisme qui garantit que le chiffrement du transport reste intact lorsque les emails passent d’un compte à un autre.
Au début de l’Internet, les serveurs d’email envoyaient et recevaient les emails en texte clair, sans chiffrement de la couche de transport. Cela signifie que toute personne surveillant le réseau pouvait lire ou modifier le message. Après l’arrivée de TLS, la norme d’email a été adaptée pour inclure le chiffrement de transport si les serveurs d’envoi et de réception le prennent en charge. Cependant, un attaquant peut toujours tromper le serveur d’envoi pour qu’il transmette l’email en texte clair en indiquant à tort que le serveur de réception ne prend pas en charge le chiffrement de la couche transport.
Comment ça marche ?
MTA-STS est un protocole qui assure la réception des emails en utilisant le chiffrement de transport (à ne pas confondre avec le chiffrement de bout en bout) si le serveur de réception le prend en charge. Le serveur d’envoi de messages recherche et met en cache la politique MTA-STS du serveur de réception de messages. En fonction de la politique MTA-STS du serveur récepteur, il refusera toute tentative de suppression de la couche de chiffrement du transport. Le serveur d’envoi se fie à un long temps de cache pour empêcher les attaques transitoires. L’inconvénient, cependant, est que chaque serveur de messagerie doit maintenir son propre cache. De plus, le propriétaire d’un domaine peut définir une politique MTA-STS mais ne peut pas imposer sa mise en œuvre .
DANE utilise des enregistrements DNS pour informer les autres serveurs de messagerie de la prise en charge du chiffrement TLS. De plus, il indique au serveur récepteur qu’il doit s’attendre à un certain certificat lorsqu’il se connecte au serveur d’envoi, ce qui le protège contre les attaquants en possession d’un certificat TLS valide du serveur d’envoi.
Cependant, il s’appuie sur la sécurité du système DNS, ce qui signifie qu’il nécessite des extensions de sécurité DNS (DNSSEC) – d’où une adoption limitée (cela est en train de changer, lien en anglais)
La prise en charge de DNSSEC (comme condition préalable à la prise en charge de DANE) apporte également des avantages supplémentaires en matière de sécurité. Parmi les exemples, citons la protection contre les attaques par empoisonnement du cache DNS et les domaines personnalisés qui utilisent les enregistrements MX de Mailfence, en particulier si le domaine personnalisé met en œuvre DNSSEC.
MTA-STS et DANE ont tous deux leurs avantages et leurs inconvénients. Chacun d’entre eux permet de se protéger contre les attaques par repli sur le chiffrement de la réception du courrier. Nous les avons donc mis en œuvre tous les deux pour améliorer la sécurité de mailfence.com.
Découverte et échange de clés OpenPGP (WKD et VKS)
Mailfence propose le chiffrement et la signature OpenPGP pour les emails. Nous sommes interopérables avec d’autres services conformes à OpenPGP depuis le début et offrons à nos utilisateurs un contrôle total sur leurs clés OpenPGP. Cependant, la découverte et l’échange de clés ont longtemps été un défi dans l’écosystème OpenPGP, car il est difficile de savoir si l’on peut faire confiance aux clés que vous recevez d’un serveur de clés publiques.
Répertoire de clés Web (WKD)
Mailfence prend désormais en charge une nouvelle approche, appelée Web Key Directory (WKD), qui utilise le Web pour permettre à un domaine de servir ses propres clés via HTTPS. Cela signifie que, lorsque vous générez une paire de clés OpenPGP ou que vous l’importez dans le magasin de clés de votre compte Mailfence, la clé publique respective (y compris l’adresse e-mail et le nom) sera publiquement disponible sur notre serveur Web Key Directory si :
- L’adresse email associée est basée sur le nom de domaine mailfence.com.
- Une association de l’adresse email de l’utilisateur est faite avec la clé User ID. Une icône de clé à côté de l’adresse From dans le compositeur de messages le représente.
- La clé est associée à l’adresse primaire ou à l’alias du compte Mailfence.
La clé publique n’est servie que pour, et avec, le paquet User ID interrogé afin de ne pas exposer les autres paquets User ID associés (pour des raisons de confidentialité et d’anti-spam). Nous ne prenons pas en charge le protocole Web Key Service (WKS).
Les utilisateurs peuvent également télécharger des clés publiques OpenPGP à partir de domaines externes (ou de services) qui prennent en charge WKD dans le magasin de clés de leur compte Mailfence. Le propriétaire du domaine personnalisé devra le configurer pour son propre domaine ou peut utiliser WKD en tant que service.
Serveur de clés de validation (VKS)
Par le passé, nous utilisions le pool de serveurs de clés de synchronisation (SKS). Suite à l’application du RGPD en 2018, nous avons cherché des alternatives en raison des problèmes connus de confidentialité des données avec le pool SKS (qui a finalement fermé le 21-06-2021). Nous avons envisagé un certain nombre de serveurs de clés publiques, et avons finalement opté pour keys.openpgp.org. Vous pouvez en découvrir davantage à leur sujet ici.
Ils autorisent la diffusion des informations d’identité (ID utilisateur : nom d’affichage et adresse email) uniquement avec le consentement de l’utilisateur et permettent également leur suppression. Consultez leur politique de confidentialité pour plus de détails.
Vous pouvez trouver des clés publiques en utilisant l’adresse email. Veuillez noter que les clés sans ID utilisateur (nom d’affichage et/ou adresse email) ne peuvent actuellement pas être traitées de notre côté. Nous prévoyons de régler ce problème à l’avenir.
Ordre de recherche des clés
Notre objectif était d’utiliser un mécanisme de découverte des clés qui fournisse :
- une confirmation positive de la propriété de la clé / une résistance au vandalisme
- une résistance au vandalisme
- la décentralisation
Nous n’avons pas trouvé de moyen qui permette de respecter les trois points ci-dessus, nous avons donc décidé de prendre en charge plusieurs mécanismes. Lorsqu’un utilisateur recherche une clé publique, la plateforme Mailfence utilise l’ordre de recherche des clés suivant :
- Web Key Directory (WKD) : Le propriétaire du domaine agit comme une ancre de confiance pour la confirmation positive de la propriété de la clé (via le modèle TOFU, lien en anglais). Si une clé publique est trouvée, le processus de recherche de clé s’arrête.
- Serveur de clés de validation (VKS) : La propriété de l’adresse email est assurée par une double validation opt-in. Le fait de ne pas être contrôlé/géré par le propriétaire d’un domaine à clé publique offre un niveau de résistance à la censure.
La validation de la signature et la mise à jour de l’état de la clé publique sont toujours effectuées à l’aide de VKS (aucun ordre de consultation n’est impliqué).on and public key status update is always done using VKS (no lookup order is involved).
Nous n’avons pas encore trouvé de mécanisme approprié qui offre le niveau de décentralisation souhaité (une des valeurs fondatrices d’OpenPGP) et continuons à surveiller les efforts menés dans ce sens.
Divers
- Nous avons commencé à appliquer la politique d’expéditeur DMARC. Vous pouvez en savoir plus ici.
- Nous avons commencé à utiliser l’enregistrement DNS CAA. Cela permet d’empêcher les autorités de certification de délivrer un certificat Mailfence illégitime.
- Pour garder un œil sur les problèmes de connectivité TLS pendant la livraison des emails, nous gardons un œil sur les rapports soumis via la norme TLSRPT.
- Afin de protéger nos utilisateurs des attaques par usurpation d’identité, et notre service des abus, nous avons décidé d’interdire la suppression des adresses alias basées sur le nom de domaine Mailfence. Ce changement s’appliquera le 01-Jan-2022. Plus d’informations ici.
Comme nous l’avons toujours fait, nous continuerons d’améliorer la sécurité de Mailfence pour offrir la meilleure expérience à nos utilisateurs. Nous ne cesserons jamais de travailler pour rendre Mailfence plus privé et plus sûr. Vous pouvez nous aider en contribuant à nos efforts. Pour en savoir plus sur Mailfence, consultez notre page de presse.
