Pourquoi certaines métadonnées ne sont-elles pas chiffrées dans Proton Mail?
Dans un autre Question , dans la première réponse est écrit que certaines métadonnées ne sont pas cryptées.
Ce que vous ne devez pas oublier à propos des e-mails cryptés, c'est que même si le corps du message est correctement crypté, certaines métadonnées comme l'objet, l'expéditeur ou le destinataire ne le sont pas.
Quelle est la raison pour laquelle Proton Mail n'a pas chiffré certaines métadonnées?
Proton Mail utilise un format de cryptage appelé OpenPGP . Il est uniquement conçu pour crypter le message. À moins que l'objet ne soit placé dans le message et que le champ d'objet soit laissé vide, l'objet sera conservé non chiffré. Les champs de l'expéditeur et du destinataire de l'e-mail, d'autre part, doivent être décryptés pour qu'un routage approprié se produise. Tout cela constitue une limitation dans la conception du courrier électronique, un système non chiffré par défaut.
Comme déjà discuté , Proton Mail utilise OpenPGP (RFC 4880).
OpenPGP trouve ses racines dans l'original Pretty Good Privacy , écrit par Philip Zimmermann en 1991. À cette époque, alors que le courrier électronique Internet (SMTP) était accessible, principalement via les institutions de recherche (l'accès général à Internet a commencé à devenu chose autour de 1994-1996), l'accès à Internet était loin d'être courant parmi le grand public.
Compte tenu de cela, il n'est pas surprenant que la structure des messages et les formats de fichiers de PGP soient de conception générale. Bien que le courrier électronique chiffré soit un cas d'utilisation majeur pour PGP, GnuPG et d'autres implémentations OpenPGP, ce n'est pas la seule façon de les utiliser. (Par exemple, j'utilise GnuPG pour crypter de gros objets de données compressées avant de les télécharger vers un fournisseur de stockage cloud à des fins de sauvegarde.)
Par conséquent, la norme OpenPGP ne peut pas imposer une structure de message en clair particulière. Cela irait à l'encontre de son caractère général.
Toutefois, le courrier électronique Internet (SMTP) a un format structuré. Il y a enveloppe données (qui est techniquement en dehors du message), en-tête données et corps données (qui elles-mêmes peuvent être structurées, par exemple comme décrit dans le MIME standard).
Les données d'enveloppe sont utilisées pour le routage des messages et se composent principalement des adresses de messagerie de l'expéditeur et du destinataire. Ceux-ci doivent être accessibles à tout serveur de messagerie le long du chemin du message, et bien que l'adresse e-mail de l'expéditeur puisse être masquée ( VERP en est une variante), il doit être valide. On ne peut pas les cacher aux serveurs de messagerie mais prétendre faire du courrier électronique SMTP. Cependant, une grande partie du courrier électronique Internet de nos jours est protégée par le cryptage SMTP STARTTLS , qui est opportuniste et généralement non vérifié, mais protège contre écoute passive . Selon votre modèle de menace, cela peut être suffisant ; la meilleure pratique actuelle dans la conception de protocoles Internet consiste à considérer la surveillance omniprésente est une attaque qui devrait être atténuée si possible dans les nouvelles conceptions.
Les données d'en-tête contiennent des en-têtes de trace (Received:), l'objet, l'expéditeur, les destinataires (à l'exception du champ Cci), les informations de filetage des messages et diverses autres données de diagnostic, informations techniques et autres métadonnées de message. Certains de ces éléments doivent être non chiffrés; par exemple, Received: les en-têtes sont ajoutés par les serveurs de messagerie, qui peuvent ne pas savoir qui est le destinataire final. Étant donné que tout est regroupé, l'approche courante consiste à simplement garder tout non chiffré (dans le canal chiffré de manière opportuniste) en transit. Dans le cas contraire, il faudrait revoir les normes de base régissant le format de courrier électronique Internet, qui remontent au moins à RFC 822 depuis 1982.
La distinction entre les données d'enveloppe et d'en-tête est également pourquoi vous pouvez recevoir un e-mail qui n'affiche pas votre adresse e-mail dans l'un des champs du destinataire.
Les données du corps sont ce que vous pourriez normalement penser comme l'e-mail et contiennent tout ce que vous écrivez généralement dans le grand champ de texte du client de messagerie. MIME peut prendre en charge le transport d'une charge utile chiffrée, signée ou les deux; généralement S/MIME ou PGP/MIME.
Il serait techniquement possible de moderniser le courrier électronique de telle sorte que certains champs de métadonnées soient déplacés dans les données MIME au lieu de la section d'en-tête du courrier électronique . Cela pourrait même être relativement facile, car la charge utile MIME peut elle-même être un message électronique entier (en-têtes et corps, mais pas des données d'enveloppe). Cependant, cela nécessiterait un support client de messagerie spécialisé (ce ne serait plus du courrier électronique Internet, mais plutôt quelque chose qui utilise le courrier électronique Internet comme couche de transport et comme source d'inspiration pour sa structure), et il faudrait également que le message entier soit envoyé à être déchiffré avant que les champs d'en-tête protégés puissent être visualisés ou autrement utilisés, y compris par exemple recherchés.
Je crois comprendre que cela n'a tout simplement pas été considéré comme une priorité, étant donné qu'il est relativement facile pour l'utilisateur (en supposant qu'il est conscient de la nécessité) de restreindre son utilisation des champs qui finissent dans le section d'en-tête non chiffrée. Le déploiement récent et assez répandu de SMTP STARTTLS, ainsi que la quantité généralement faible de trafic de messagerie crypté de bout en bout (par opposition au transport), ont probablement peu fait, mais ont renforcé cela.
Et c'est presque certainement la raison pour laquelle Proton Mail ne crypte pas ces métadonnées lors de l'envoi d'e-mails via Internet.