Pourquoi le chiffrement de bout en bout n'est-il toujours pas par défaut dans les e-mails?
Je ne suis pas cryptographe. C'est peut-être pourquoi je ne vois pas les problèmes d'intégration de PGP dans SMTP.
Dans ma tête: Lea demande au serveur du domaine de Luke jedi.com de lui dire la clé publique de [email protected] (La demande comprend peut-être une méthode de cryptage). Elle récupère la clé PUBLIC. Puis elle crypte le message et Luke peut le décrypter facilement.
Ce n'est pas si difficile, pourquoi n'est-ce pas standard depuis des années?
Ce n'est pas si difficile, pourquoi n'est-ce pas standard depuis des années?
Parce que cela n'aurait pas résolu le problème que PGP essaie de résoudre.
PGP est un chiffrement de bout en bout, donc s'il existe un moyen pour le serveur SMTP de subvertir le chiffrement, le schéma échoue.
Dans le cas du schéma que vous avez proposé, supposons qu'Alice ([email protected]) souhaite envoyer un message privé à Bob ([email protected]). En utilisant le schéma que vous avez proposé, le client de messagerie d'Alice ou le serveur SMTP d'Alice récupère la clé publique de Bob en établissant une connexion TLS avec dave.com. C'est très bien tant que dave.com est honnête et retourne réellement la clé publique de Bob. Mais dave.com aurait pu être configuré par l'opérateur de dave.com pour renvoyer une clé publique falsifiée créée par Eve, ou Eve pourrait pirater dave.com et la configurer. Maintenant, le client de messagerie/serveur de messagerie d'Alice accepterait volontiers le certificat d'Eve, pensant que la clé publique est celle de Bob. Dans ce modèle, l'opérateur de dave.com peut intercepter n'importe quel e-mail de Bob.
Maintenant, tant que dave.com est honnête, cela protège toujours contre l'usurpation d'identité par des tiers. Pourquoi ne le faisons-nous pas de toute façon si cela protège au moins contre l'espionnage par des tiers? Principalement parce que SMTPS fournit également le même niveau de protection, tout en étant beaucoup plus simple. Si MITM par l'opérateur du serveur de messagerie ne vous concerne pas, vous pouvez déjà très bien sécuriser vos e-mails en vous assurant que vous utilisez tous les deux SMTPS.
Notez que la difficulté du chiffrement de bout en bout ne consiste pas à récupérer des clés publiques. La plupart des clients de messagerie prenant en charge PGP prennent également en charge la récupération automatique des clés publiques depuis LDAP ou HPKP. La difficulté du chiffrement de bout en bout consiste à vérifier les clés publiques.
Il n'existe aucune méthode connue de vérification des clés publiques qui soit totalement transparente pour les utilisateurs et entièrement sécurisée. Le modèle Web of Trust ou Certificate Authority est le plus proche, mais Web of Trust est livré avec de nombreuses mises en garde et le modèle Certificate Authority s'appuie sur un tiers pour effectuer la vérification.
l'intégration de PGP dans SMTP.
PGP est un format de conteneur pour les données (comme les e-mails mais non limité aux e-mails), qui ajoute un chiffrement et/ou une signature aux données. SMTP est un protocole de transport.
Vous n'intégrez pas les formats de conteneur dans les protocoles de transport. Cela reviendrait à dire que vous devez intégrer Office (conteneur pour texte, images ...) avec SMTP (transport) pour envoyer un document Office à quelqu'un.
PGP est également utilisé en dehors de SMTP, car il ne s'agit que d'un conteneur. Et SMTP est également utilisé pour transporter des choses différentes des conteneurs PGP, car ce n'est qu'un protocole de transport.
Si vous demandez plutôt d'intégrer le chiffrement de bout en bout comme PGP ou S/MIME dans SMTP, cela ne fonctionnera pas non plus, car SMTP est une livraison bond par bond et non de bout en bout. En dehors de cela, SMTP ne couvre même pas le dernier bond, c'est-à-dire la livraison du dernier serveur de messagerie au client. Cela se fait avec des protocoles comme POP ou IMAP.
Lea demande au serveur du domaine de Luke jedi.com de lui dire la clé publique de [email protected] ...
C'est pour cela que vous avez des serveurs clés ou d'autres types de répertoires centraux. Mais comment Lea sait-elle que c'est en fait la clé de Luke et non la clé de quelqu'un qui prétend être Luke? Ainsi, vous devez avoir une certaine propagation de confiance, par exemple sous la forme d'un réseau de confiance (PGP) ou d'une structure plus centralisée (S/MIME) ou en faisant confiance à tout dans un répertoire central spécifique.
Ainsi, la tâche n'est pas d'intégrer PGP avec SMTP mais d'avoir un meilleur support pour PGP dans les clients de messagerie, afin qu'ils récupèrent automatiquement les clés PGP des destinataires. Mais bien sûr, il doit d'abord y avoir une clé PGP vérifiable pour le destinataire quelque part sur un serveur de clés ou un autre répertoire, donc l'autre tâche consiste à faciliter la création, la publication et la gestion des clés (renouvellement, révocation ...). Ce sont toutes des choses en dehors de la livraison du courrier (SMTP) elle-même.
Le chiffrement est déjà en place pendant le transit du courrier (STARTTLS dans SMTP), mais pas assez sophistiqué pour se protéger contre MITM.
Je crois que PGP est plus une expérience d'utilisateur final entre les clients de messagerie, ce qui est utile si vous n'avez pas une confiance totale dans les serveurs impliqués.
(PGP est parfois sensible à MITM pour l'utilisateur peu prudent, cependant, comme dans SSH, si vous vérifiez la signature de clé correcte, ce problème est résolu)
Cependant, dans le cas des services de messagerie basés sur le cloud comme Gmail, ils devraient de toute façon être disponibles sur le serveur pour une bonne expérience utilisateur, donc PGP ne ferait que gêner.
J'espère qu'un jour nous obtiendrons un cryptage MITM proof en SMTP, mais c'est moins un problème parce que les serveurs de messagerie sont sur des réseaux contrôlés.
Écrire une norme est facile. J'ai pensé à ce même problème il y a environ dix ans. Cela revient au facteur humain/coût. Comment convaincre un milliard de personnes analphabètes sur le plan technologique de mettre à jour leur logiciel sans aucun avantage apparent, et convaincre des milliers de développeurs à travers une multitude de plateformes de mettre en œuvre ce protocole, et des millions d'organisations de passer à un nouveau protocole, même si vous - donnez-le. Nous avons épuisé nos adresses IPv4 dans certaines parties du monde dès 2011, et pourtant Internet n'utilise toujours pas IPv6 à l'échelle mondiale. Nous ne pouvons même pas convaincre les gens de passer à IPv6 malgré le fait que nous étouffons littéralement la croissance d'Internet. Même si vous pouviez élaborer une norme aujourd'hui et la soumettre à l'IETF pour être officialisée et distribuée, ce serait 2030 avant qu'elle ne soit suffisamment répandue pour arrêter les innombrables serveurs de messagerie "classiques" qui fonctionnent aujourd'hui.
Eh bien, comme vous pouvez le lire ci-dessus, vous pouvez utiliser SMTPS et STARTTLS pour renforcer la sécurité des serveurs SMTP lors de l'envoi de messages. MITM peut être atténué avec DKIM.
DomainKeys Identified Mail (DKIM) permet à une organisation de prendre la responsabilité d'un message en transit. L'organisation est un gestionnaire du message, soit en tant que son expéditeur, soit en tant qu'intermédiaire. Leur réputation est la base pour évaluer s'il faut faire confiance au message pour une manipulation ultérieure, telle que la livraison. Techniquement, DKIM fournit une méthode pour valider une identité de nom de domaine associée à un message via l'authentification cryptographique.
En bref, DKIM vous permet d'identifier si les e-mails proviennent de l'origine dont l'en-tête indique qu'ils proviennent. Où le serveur peut alors décider de manière fiable si le message peut être approuvé (si l'authentification DKIM échoue, vous pouvez supprimer le courrier et ne vous inquiétez pas si un faux message obtient le serveur SMTP sur une liste de maisons de spam).
Et ce genre de tour du cercle. Avec l'authentification sécurisée STARTTLS, vous pouvez vous connecter de manière fiable à un serveur SMTP et envoyer votre courrier à un serveur de messagerie. DKIM peut identifier si un serveur SMTP donné est autorisé à envoyer des e-mails à partir d'une certaine adresse. TLS pour la remise du courrier du serveur SMTP au serveur de messagerie pour crypter la connexion. STARTTLS entre le client de messagerie et le serveur de messagerie (sauf s'il s'agit d'un client de messagerie Web, une connexion socket sécurisée via POP ou IMAP peut suffire)