La s\u00e9curit\u00e9 est l’une de nos principales priorit\u00e9s, avec la confidentialit\u00e9. Nous nous effor\u00e7ons de fournir \u00e0 nos utilisateurs l’exp\u00e9rience la plus s\u00fbre 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\u00e9es. Au cours des derni\u00e8res ann\u00e9es, nous avons publi\u00e9 plusieurs nouvelles fonctionnalit\u00e9s pour am\u00e9liorer la s\u00e9curit\u00e9 de tous les utilisateurs de Mailfence.<\/p>\n\n\n\n
De la DANE \u00e0 la MTA-STS, en passant par la WKD et la VKS, d\u00e9couvrez comment nous avons proc\u00e9d\u00e9 pour am\u00e9liorer la s\u00e9curit\u00e9 de vos donn\u00e9es.<\/p>\n\n\n\n\n\n\n
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\u00eame probl\u00e8me, commun\u00e9ment appel\u00e9 attaque par repli<\/a>. 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\u00e9canisme qui garantit que le chiffrement du transport reste intact lorsque les emails passent d’un compte \u00e0 un autre.<\/p>\n\n\n\n Au d\u00e9but 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\u00e9seau pouvait lire ou modifier le message. Apr\u00e8s l’arriv\u00e9e de TLS<\/a>, la norme d’email a \u00e9t\u00e9 adapt\u00e9e pour inclure le chiffrement de transport si les serveurs d’envoi et de r\u00e9ception 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 \u00e0 tort que le serveur de r\u00e9ception ne prend pas en charge le chiffrement de la couche transport.<\/p>\n\n\n\n MTA-STS est un protocole qui assure la r\u00e9ception des emails en utilisant le chiffrement de transport (\u00e0 ne pas confondre avec le chiffrement de bout en bout<\/a>) si le serveur de r\u00e9ception le prend en charge. Le serveur d’envoi de messages recherche et met en cache la politique MTA-STS du serveur de r\u00e9ception de messages. En fonction de la politique MTA-STS du serveur r\u00e9cepteur, il refusera toute tentative de suppression de la couche de chiffrement du transport. Le serveur d’envoi se fie \u00e0 un long temps de cache pour emp\u00eacher les attaques transitoires. L’inconv\u00e9nient, cependant, est que chaque serveur de messagerie doit maintenir son propre cache. De plus, le propri\u00e9taire d’un domaine peut d\u00e9finir une politique MTA-STS mais ne peut pas imposer sa mise en \u0153uvre .<\/p>\n\n\n\n DANE utilise des enregistrements DNS pour informer les autres serveurs de messagerie de la prise en charge du chiffrement TLS<\/a>. De plus, il indique au serveur r\u00e9cepteur qu’il doit s’attendre \u00e0 un certain certificat <\/a>lorsqu’il se connecte au serveur d’envoi, ce qui le prot\u00e8ge contre les attaquants en possession d’un certificat TLS valide du serveur d’envoi.<\/p>\n\n\n\n Cependant, il s’appuie sur la s\u00e9curit\u00e9 du syst\u00e8me DNS, ce qui signifie qu’il n\u00e9cessite des extensions de s\u00e9curit\u00e9 DNS (DNSSEC) – d’o\u00f9 une adoption limit\u00e9e (cela est en train de changer<\/a>, lien en anglais)<\/p>\n\n\n\n La prise en charge de DNSSEC (comme condition pr\u00e9alable \u00e0 la prise en charge de DANE) apporte \u00e9galement des avantages suppl\u00e9mentaires en mati\u00e8re de s\u00e9curit\u00e9. Parmi les exemples, citons la protection contre les attaques par empoisonnement du cache DNS<\/a> et les domaines personnalis\u00e9s qui utilisent les enregistrements MX de Mailfence, en particulier si le domaine personnalis\u00e9 met en \u0153uvre DNSSEC.<\/p>\n\n\n\n MTA-STS et DANE ont tous deux leurs avantages et leurs inconv\u00e9nients. Chacun d’entre eux permet de se prot\u00e9ger contre les attaques par repli sur le chiffrement de la r\u00e9ception du courrier. Nous les avons donc mis en \u0153uvre tous les deux pour am\u00e9liorer la s\u00e9curit\u00e9<\/strong> de mailfence.com<\/strong>.<\/p>\n\n\n\n Mailfence propose le chiffrement et la signature OpenPGP <\/a>pour les emails. Nous sommes interop\u00e9rables avec d’autres services conformes \u00e0 OpenPGP depuis le d\u00e9but et offrons \u00e0 nos utilisateurs un contr\u00f4le total sur leurs cl\u00e9s OpenPGP<\/a>. Cependant, la d\u00e9couverte et l’\u00e9change de cl\u00e9s ont longtemps \u00e9t\u00e9 un d\u00e9fi dans l’\u00e9cosyst\u00e8me OpenPGP, car il est difficile de savoir si l’on peut faire confiance aux cl\u00e9s que vous recevez d’un serveur de cl\u00e9s publiques.<\/p>\n\n\n\n Mailfence prend d\u00e9sormais en charge une nouvelle approche, appel\u00e9e Web Key Directory (WKD)<\/a>, qui utilise le Web pour permettre \u00e0 un domaine de servir ses propres cl\u00e9s via HTTPS. Cela signifie que, lorsque vous g\u00e9n\u00e9rez une paire de cl\u00e9s OpenPGP<\/a> ou que vous l’importez <\/a>dans le magasin de cl\u00e9s de votre compte Mailfence, la cl\u00e9 publique respective (y compris l’adresse e-mail et le nom) sera publiquement disponible sur notre serveur Web Key Directory si :<\/p>\n\n\n\n La cl\u00e9 publique n’est servie que pour, et avec, le paquet User ID interrog\u00e9 afin de ne pas exposer les autres paquets User ID associ\u00e9s (pour des raisons de confidentialit\u00e9 et d’anti-spam). Nous ne prenons pas en charge le protocole Web Key Service (WKS)<\/a>.<\/p>\n\n\n\n Les utilisateurs peuvent \u00e9galement t\u00e9l\u00e9charger des cl\u00e9s publiques OpenPGP \u00e0 partir de domaines externes (ou de services) qui prennent en charge WKD dans le magasin de cl\u00e9s de leur compte Mailfence. Le propri\u00e9taire du domaine personnalis\u00e9<\/a> devra le configurer<\/a> pour son propre domaine ou peut utiliser WKD en tant que service<\/a>.<\/p>\n\n\n\n Par le pass\u00e9, nous utilisions le pool de serveurs de cl\u00e9s de synchronisation (SKS)<\/a>. Suite \u00e0 l’application du RGPD<\/a> en 2018, nous avons cherch\u00e9 des alternatives en raison des probl\u00e8mes connus de confidentialit\u00e9 des donn\u00e9es avec le pool SKS (qui a finalement ferm\u00e9 le 21-06-2021<\/a>). Nous avons envisag\u00e9 un certain nombre de serveurs de cl\u00e9s publiques, et avons finalement opt\u00e9 pour keys.openpgp.org. Vous pouvez en d\u00e9couvrir davantage \u00e0 leur sujet ici<\/a>.<\/p>\n\n\n\n Ils autorisent la diffusion des informations d’identit\u00e9 (ID utilisateur : nom d’affichage et adresse email) uniquement avec le consentement de l’utilisateur et permettent \u00e9galement leur suppression. Consultez leur politique de confidentialit\u00e9<\/a> pour plus de d\u00e9tails.<\/p>\n\n\n\n Vous pouvez trouver des cl\u00e9s publiques en utilisant l’adresse email. Veuillez noter que les cl\u00e9s sans ID utilisateur (nom d’affichage et\/ou adresse email) ne peuvent actuellement pas \u00eatre trait\u00e9es de notre c\u00f4t\u00e9. Nous pr\u00e9voyons de r\u00e9gler ce probl\u00e8me \u00e0 l’avenir.<\/p>\n\n\n\n Notre objectif \u00e9tait d’utiliser un m\u00e9canisme de d\u00e9couverte des cl\u00e9s qui fournisse :<\/p>\n\n\n\n Nous n’avons pas trouv\u00e9 de moyen qui permette de respecter les trois points ci-dessus, nous avons donc d\u00e9cid\u00e9 de prendre en charge plusieurs m\u00e9canismes. Lorsqu’un utilisateur recherche une cl\u00e9 publique<\/a>, la plateforme Mailfence utilise l’ordre de recherche des cl\u00e9s suivant :<\/p>\n\n\n\n La validation de la signature et la mise \u00e0 jour de l’\u00e9tat de la cl\u00e9 publique sont toujours effectu\u00e9es \u00e0 l’aide de VKS (aucun ordre de consultation n’est impliqu\u00e9).on and public key status update is always done using VKS (no lookup order is involved).<\/p>\n\n\n\n Nous n’avons pas encore trouv\u00e9 de m\u00e9canisme appropri\u00e9 qui offre le niveau de d\u00e9centralisation souhait\u00e9 (une des valeurs fondatrices d’OpenPGP) et continuons \u00e0 surveiller les efforts men\u00e9s<\/a> dans ce sens.<\/p>\n\n\n\n Comme nous l’avons toujours fait, nous continuerons d’am\u00e9liorer la s\u00e9curit\u00e9 de Mailfence pour offrir la meilleure exp\u00e9rience \u00e0 nos utilisateurs. Nous ne cesserons jamais de travailler pour rendre Mailfence plus priv\u00e9 et plus s\u00fbr. Vous pouvez nous aider en contribuant <\/a>\u00e0 nos efforts. Pour en savoir plus sur Mailfence, consultez notre page de presse.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" La s\u00e9curit\u00e9 est l’une de nos principales priorit\u00e9s, avec la confidentialit\u00e9. Nous nous effor\u00e7ons de fournir \u00e0 nos utilisateurs l’exp\u00e9rience la plus s\u00fbre 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 […]<\/p>\n","protected":false},"author":4,"featured_media":85551,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18591,27],"tags":[],"class_list":["post-24424","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mailfence-news","category-securite"],"yoast_head":"\nComment \u00e7a marche ?<\/h3>\n\n\n\n
D\u00e9couverte et \u00e9change de cl\u00e9s OpenPGP (WKD et VKS)<\/h2>\n\n\n\n
R\u00e9pertoire de cl\u00e9s Web (WKD)<\/h3>\n\n\n\n
\n
Serveur de cl\u00e9s de validation (VKS)<\/h3>\n\n\n\n
Ordre de recherche des cl\u00e9s<\/h3>\n\n\n\n
\n
\n
Divers<\/h2>\n\n\n\n
\n