Voici un aperçu du projet STARTTLS Everywhere. Si votre serveur de messagerie est affecté par ces modifications, consultez notre formation technique approfondie pour sécuriser votre serveur de messagerie!
EFF a lancé notre projet STARTTLS Everywhere en 2014, à un moment post-Snowden où la communauté technologique s'est regroupée pour faire du chiffrement du transport une nécessité cruciale.
Grâce aux révélations de Snowden, nous avons pu entrevoir à quel point les gouvernements peuvent être agressifs pour intercepter les communications de dorsale Internet. Avec d'autres technologues de la sécurité, EFF a répondu en travaillant à chiffrer Internet. Nous avons lancé plusieurs projets, implorant les propriétaires de sites, les fournisseurs de messagerie et les fabricants d'applications à travers le monde de déployer le chiffrement de leurs services. Nous avons créé des outils et une infrastructure pour faciliter le chiffrement des sites Web et d'autres services, comme Let's Encrypt et Certbot . Pour compléter HTTPS Everywhere , nous avons lancé un effort parallèle pour chiffrer les e-mails lors de leur livraison entre les fournisseurs de messagerie: STARTTLS Everywhere.
Depuis lors, nous avons fait de grands progrès dans la sécurité du transport des e-mails grâce à la coopération des fournisseurs de messagerie, des auteurs de protocoles et des développeurs de serveurs de messagerie. Nous terminerons lentement notre travail sur la liste des politiques STARTTLS , bien que nous continuerons de plaider pour une meilleure sécurité des transports par courrier électronique et partout ailleurs sur Internet. Bien que le soutien au projet ait été encourageant, les données que nous publions ne sont pas largement utilisées par les fournisseurs de messagerie. Dans le même temps, nous avons vu d'autres approches fondées sur des normes mûrir et devenir plus simples à adopter. Le 29 avril, nous n'accepterons plus les soumissions à notre liste de politiques STARTTLS.
Chiffré, mais pas authentifié
Selon le rapport de transparence de Google, le pourcentage d'e-mails chiffrés en transit est passé d'environ 30% en 2013 et 2014 à plus de 90% aujourd'hui. Malgré ces succès, l'écosystème de messagerie est loin d'être totalement sécurisé contre la surveillance du réseau et les attaquants.
Le chiffrement du transport est incomplet sans authentification. Bien que cela empêche les personnes qui écoutent sur le réseau de lire le trafic de messagerie en transit, les tentatives intentionnelles de décrypter ce trafic peuvent toujours réussir. En effet, l' authentification n'est pas encore complètement résolue dans la sécurité du transport pour le courrier électronique.
Le chiffrement garantit que votre communication n'est lisible que par une partie particulière. L'authentification garantit que cette partie est celle que vous vouliez qu'elle soit.
Le courrier électronique est plus compliqué que le Web et s'appuie davantage sur DNS, un système à l'échelle d'Internet pour stocker des informations sur la façon d'atteindre certains ordinateurs. Par exemple, il existe deux recherches DNS impliquées dans l'identification du serveur pour un domaine de messagerie particulier, tandis que les serveurs Web ne nécessitent souvent qu'une seule recherche. Le DNS est utile, mais notoirement peu sûr – et dans la pratique, cela signifie que lors de l'envoi d'e-mails, les serveurs doivent en quelque sorte s'assurer que ces deux recherches sont correctes. Sinon, un fournisseur de services Internet majeur pourrait utiliser cette différence pour supprimer le cryptage des e-mails, ou même prétendre être le serveur de messagerie récepteur, interceptant, retardant, bloquant ou réécrivant ainsi les e-mails.
Sur le Web, les certificats TLS fournissent suffisamment d'informations pour que votre navigateur valide l'identité du site Web. Pour le courrier électronique, ces certificats ne suffisent pas, car ils ne sécurisent souvent que l'une des deux recherches DNS; Les serveurs de messagerie ont besoin d'un moyen supplémentaire pour recevoir et diffuser en toute sécurité les informations TLS et DNS, ce qui ne faisait pas traditionnellement partie des normes de messagerie Internet.
Authentification des e-mails
En bref, les serveurs de messagerie ont besoin d'un moyen de publier plus d'informations sur leur identité, et ils ont également besoin d'un moyen de récupérer ces informations afin de pouvoir vérifier l'identité des autres serveurs de messagerie. Actuellement, il existe quelques solutions de pointe: il y a DANE et MTA-STS.
DANE est un moyen de publier plus d'informations TLS pour un domaine de messagerie via DNS. Il s'appuie sur DNSSEC, une technologie utilisée pour sécuriser les recherches DNS. Étant donné que le déploiement DNSSEC est descendant (par exemple, votre registraire de domaine doit également le prendre en charge) et est quelque peu complexe, le déploiement reste relativement faible. Cependant, de nombreux efforts combinés augmentent son utilisation: de nombreux serveurs de messagerie open source fournissent un support DANE, davantage de fournisseurs DNS facilitent le déploiement de DNSSEC, et nous avons amélioré Certbot pour mieux coopérer avec DANE. À l'avenir, nous espérons aider Certbot à fonctionner encore mieux avec les déploiements DANE.
MTA-STS est une autre façon de publier des informations TLS pour un serveur de messagerie, cette fois sur le Web. Il a été normalisé à la fin de 2018 et a depuis été adopté par un certain nombre de grands fournisseurs de services de messagerie, notamment Gmail et des FAI comme Comcast. Le seul inconvénient de cette approche est que lorsque vous recherchez les informations TLS d'une personne à l'aide de MTA-STS pour la première fois, elles peuvent être bloquées par un FAI qui souhaite délibérément empêcher la livraison sécurisée d'e-mails.
Nous espérons que plus de serveurs de messagerie à l'avenir pourront adopter ces alternatives à l'authentification des e-mails.
L'avenir du courrier électronique sécurisé: il commence avec nous
L'une des préoccupations à l'avenir est la centralisation de l'écosystème de messagerie. Cette structure centralisée a été bénéfique pour le déploiement de nouveaux protocoles de sécurité tels que MTA-STS – il est plus facile de sécuriser de grandes parties de tous les e-mails en faisant pression sur ces grands fournisseurs de messagerie pour qu'ils adoptent des protocoles en masse.
Cependant, il peut être difficile pour les petits fournisseurs de messagerie de publier leurs informations TLS sur DNSSEC et DANE en raison de sa complexité, et en outre difficile pour eux de vérifier les informations TLS sur MTA-STS car très peu de serveurs de messagerie open source populaires fournissent cette prise en charge. Plutôt que de créer de nouveaux ensembles de solutions pour couvrir diverses failles de sécurité, les développeurs de serveurs de messagerie devraient continuer à intégrer la sécurité dans les serveurs de messagerie par défaut, et à réduire la barrière à l'entrée pour TLS authentifié dans les e-mails. Des projets comme Mail in a Box , un projet de serveur de messagerie «en un seul clic», sont particulièrement prometteurs.
Comme nous l'avons vu avec les progrès de l'adoption du HTTPS, si nous rendons la sécurité sans effort, nous pouvons la rendre universelle .
Cet article est une traduction automatique d’un post publié sur le site d’Electronic Frontier Foundation à l’URL https://www.eff.org/deeplinks/2020/04/winding-down-starttls-everywhere-project-and-future-secure-email le Tue, 21 Apr 2020 14:41:24 +0000.