0

Comme déjà discutéProton Mail utilise OpenPGP (RFC 4880).

OpenPGP puise ses racines dans l'original Pretty Good Privacy, écrit par Philip Zimmermann en 1991. À cette époque, même si le courrier électronique sur Internet (SMTP) était accessible, principalement via des instituts de recherche (l’accès général à Internet est devenu chose courante vers 1994-1996), l’accès à Internet était loin d’être courant parmi les utilisateurs. grand public.

Dans ces conditions, il n’est pas surprenant que la structure des messages et les formats de fichiers de PGP soient polyvalents. 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 chiffrer des blobs volumineux de données compressées avant de les télécharger vers un fournisseur de stockage en nuage à des fins de sauvegarde.)

Par conséquent, la norme OpenPGP ne peut pas imposer une structure de message en texte clair particulière. Cela irait à l'encontre de sa nature polyvalente.

Cependant, le courrier Internet (SMTP) a un format structuré. Il y a enveloppe données (qui sont techniquement en dehors du message), entête données et corps données (qui peuvent elles-mêmes être structurées, par exemple comme décrit dans le MIME la norme).

Les données d'enveloppe sont utilisées pour le routage des messages et consistent principalement en adresses de messagerie de l'expéditeur et du destinataire. Ceux-ci doivent être accessibles à n’importe quel serveur de messagerie le long du chemin du message, bien que l’adresse e-mail de l’expéditeur puisse être masquée (VERP est une variante de cela), 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 est actuellement protégée par SMTP. STARTTLS le cryptage, qui est opportuniste et généralement non vérifié, mais protège contre passif écoute indiscrète.

Les données d'en-tête contiennent des en-têtes de trace (Reçu:), sujet, expéditeur, destinataires (à l’exception du champ Cci), informations sur le filetage du message et autres données de diagnostic, informations techniques et autres métadonnées de message. Une partie de cela doit être non cryptée; par exemple, Reçu: 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 à tout conserver non crypté (dans le canal crypté de manière opportuniste) en transit. Sinon, il faudrait revoir les normes de base régissant le format de messagerie Internet, qui remonte au moins à RFC 822 de retour en 1982.

La distinction entre les données d'enveloppe et d'en-tête explique également pourquoi vous pouvez recevoir un courrier électronique qui n'affiche pas votre adresse électronique dans les champs du destinataire.

Les données de corps correspondent à ce que vous pouvez normalement qualifier de courrier électronique et contiennent tout ce que vous écrivez généralement dans le champ de texte de grande taille du client de messagerie. MIME peut prendre en charge le transport d'une charge chiffrée, signée ou des deux. d'habitude soit S / MIME ou PGP / MIME.

Il aurait Il est techniquement possible de moderniser le courrier électronique de 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 s'avérer relativement simple, car la charge MIME peut elle-même consister en un message électronique complet (en-têtes et corps, mais pas les données d'enveloppe). Toutefois, cela nécessiterait un support client de messagerie spécialisé (il ne s'agirait plus de messagerie Internet, mais plutôt de quelque chose qui utilise la messagerie Internet comme couche de transport et comme source d'inspiration pour sa structure), ainsi que de l'intégralité du message. être déchiffré avant que les champs d’en-tête protégés puissent être visualisés ou utilisés, y compris par exemple une recherche.

D'après ce que j'ai compris, cela n'a tout simplement pas été considéré comme une priorité, car il est relativement facile pour l'utilisateur (en supposant qu'il soit conscient de la nécessité) de restreindre son utilisation des champs qui se retrouvent dans la section d'en-tête non cryptée. Le déploiement récent et assez répandu de SMTP STARTTLS, ainsi que la quantité généralement faible de trafic de courrier électronique crypté de bout en bout (par opposition au transport), n’ont probablement que peu contribué à cette amélioration, mais l’ont renforcée.

Et c’est certainement pour cette raison que Proton Mail ne chiffre pas ces métadonnées lors de l’envoi de courrier électronique sur Internet.