Le plus gros obstacle à votre proposition est l'adoption par les utilisateurs et le changement de comportement. Imaginez devoir expliquer à tout le monde ce qu'est une clé publique et à quel point elle est géniale. Cela n'arrivera tout simplement pas.

Au lieu de cela, la sécurité des e-mails est passée du côté du serveur de messagerie, avec plusieurs objectifs:

• le chiffrement du transport. Ceci est déjà assez largement déployé
• l'authentification de l'expéditeur (pour l'authentification du domaine d'envoi, pas de l'utilisateur individuel), ce qui est un peu plus fastidieux et repose sur une connaissance considérable du serveur de messagerie individuel administrateurs (en tant que personne qui a dû configurer SPF / DKIM / DMARC, je peux vous dire que ce n'est pas très amusant).

Votre proposition moins le téléchargement de votre clé personnelle (au lieu de la générer automatiquement) est plus ou moins de sécurité de transport, mais sans authentification. La partie authentification est la plus délicate et c'est ce que les acronymes mentionnés essaient de faire, quoique fastidieusement.

En guise de remarque: un cryptage de bout en bout approprié des e-mails vous obligerait à 1) faire confiance au Web fournisseur de messagerie basé sur vos clés, ou 2) utilisez un client local qui connaît votre clé privée. Le premier est indésirable pour beaucoup, le second est peu pratique pour la plupart des gens.

Autre remarque: HTTPS a été largement adopté car il est (principalement) invisible pour la plupart des utilisateurs, à l'exception des avertissements du navigateur. Le cryptage / authentification moderne des e-mails en est l'équivalent. Mais l'équivalent de tout le monde ayant une paire de clés pour le courrier électronique serait de demander aux gens d'utiliser des certificats clients pour se connecter à des sites Web. euh!

Cela peut sembler simple, mais ce n'est pas le cas. C'est en fait très compliqué.

Il y a quelques pièces mobiles qui sont difficiles à réparer:

• éducation des utilisateurs: ne comptez pas sur les gens qui savent ce qu'est une paire de clés est, comment en créer un, comment protéger leurs clés.

• clés oubliées / perdues: si un certificat TLS est perdu, le propriétaire en demande simplement un autre. Aucun trafic n'est perdu. Mais si un utilisateur perd sa clé, tous ses e-mails précédents sont illisibles. Pour toujours.

• MiTM: si votre fournisseur stocke à la fois vos e-mails et votre paire de clés, il peut lire et modifier n'importe quel e-mail. S'ils ne disposent que de votre clé publique, ils peuvent MitM vos e-mails en fournissant à vos amis une clé qui leur appartient et en rechiffrant avec votre clé avant de vous les transmettre. À moins que vous ne leur envoyiez la clé hors bande (SMS, e-mail d'un autre serveur, en personne), ils ne sauront pas que votre clé n'est pas vraiment votre clé.

Étant donné que même TLS est transparent et les gens cliquent toujours sur les erreurs et chargent des sites dangereux avec des certificats falsifiés, et utilisent password comme mot de passe, je doute que cela obtienne une utilisation généralisée et que les utilisateurs soient en sécurité.

Cela a été évoqué dans d'autres réponses et commentaires, mais je pense que la différence fondamentale entre le trafic Web et e-mail est de savoir quelles sont les parties impliquées.

Le HTTPS fait en fait deux choses:

• Il chiffre la communication afin qu'elle ne puisse pas être lue par un attaquant. Ceci est réalisé à l'aide d'une session avec état négociée directement entre le navigateur de l'utilisateur et le serveur Web. Cela se produit sur la même connexion TCP (ou QUIC) que les messages réels seront envoyés.
• Il authentifie la communication afin qu'elle ne puisse pas être falsifiée par un attaquant. Ceci est réalisé en utilisant une hiérarchie d'autorités de confiance, avec à une extrémité une liste statique que chaque client doit maintenir, et à l'autre extrémité un certificat unique que chaque serveur doit obtenir.

Les deux de ceux-ci profitent de la topologie particulière du Web: de nombreux clients se connectent directement à un nombre beaucoup plus restreint de serveurs. Les intermédiaires qui ont besoin de lire le trafic en texte brut pour le transmettre sont relativement rares.

Pour les e-mails, les deux sont problématiques:

• Pour le chiffrement , l'expéditeur réel d'un message ne se connecte généralement pas directement à son destinataire, de sorte qu'une session avec état entre eux ne peut pas exister de la même manière. Les connexions individuelles où le message est transmis peuvent être cryptées (et le sont maintenant fréquemment) - par ex. de votre client de messagerie de bureau à GMail, et de GMail à FastMail - mais il n'y a pas d'équivalent à la connexion TCP de bout en bout où HTTPS est négocié.
• Pour l'authentification, les entités qui doivent être authentifiées sont les millions d'utilisateurs individuels, et non un petit nombre de serveurs. Cela signifie que nous avons besoin d'une hiérarchie de confiance qui peut aller de chaque client de messagerie (qui va choisir une paire de clés authentifiée) à chaque adresse individuelle. Faire confiance à Fastmail pour fournir des clés pour chaque adresse @ fastmail.com ne résout vraiment rien - vous revenez à chiffrer le transport du message, plutôt que de prouver quoi que ce soit sur la personne qui l'a reçu. Ceci est encore compliqué par l'authentification que vous souhaitez pour les e-mails étant en fait l'inverse : pour éviter le spam et l'emprunt d'identité, vous voulez authentifier l ' expéditeur de chaque message non le destinataire.

Tout cela conduit comme d'autres l'ont dit à l'état actuel des choses:

• Chiffrement au niveau du transport dans POP3, IMAP et SMTP sont courants et généralement totalement transparents.
• Les expéditeurs qui négocient un chiffrement authentifié avec des destinataires particuliers sont rares en dehors des réseaux fermés.
• Il existe différents protocoles permettant aux destinataires authentifier les expéditeurs (par exemple DKIM, etc.), compliqué par le manque de connexion directe pour négocier et les manières complexes dont les utilisateurs interagissent avec le réseau. Si vous regardez les adresses se terminant par @ gmail.com , cela semble simple; mais imaginez combien de clients et de services sont autorisés à envoyer et à recevoir des e-mails pour des adresses se terminant par @apple.com.

Le sujet est très complexe et difficile à expliquer en une réponse unique . Je crois comprendre que vous avez révélé votre manque d’éducation en CS, alors nous devons vous expliquer.

Transport vs bout en bout

Il y a une énorme différence entre le chiffrement de transport > et chiffrement de bout en bout . Il ne faut pas les confondre.

Https est né en tant que cryptage de transport (couche de sécurité transport ), de sorte que la communication entre le navigateur et le serveur reste protégée. Si vous vous connectez à votre banque à domicile, le transport se déroule de bout en bout, car votre banque est l’autre extrémité de la communication. Si vous vous connectez à la messagerie Web, ce n'est que du transport car votre fournisseur peut lire vos e-mails afin de les afficher.

Les e-mails sont déjà (principalement) cryptés pour le transport

Ce que vous ne sait peut-être pas que les e-mails sont déjà envoyés via TLS (le protocole sous https). À l'exception de certains réseaux de petites entreprises, des plus petits FAI, des serveurs homebrew, etc., tous les e-mails sont transférés cryptés entre FAI. Seuls eux connaissent le contenu des e-mails.

Ainsi, la portée de votre question pourrait être un peu déroutante. Pour simplifier, les emails sont déjà transférés avec l'équivalent de https. Vous avez dit "https est populaire", je dis que TLS est également populaire pour les e-mails.

Le fardeau du chiffrement de bout en bout

Https est facile à déployer. Seul le serveur doit déployer un certificat, chaque connexion est sans état et oublie tout ce qui concerne l'historique.

Les e-mails cryptés de bout en bout sont une énorme douleur pour les consommateurs.

• Besoin de configurer des certificats. Tout le monde n'a pas suffisamment d'expertise
• Que faire si l'utilisateur perd la clé / l'appareil? Ils perdent tout l'historique des e-mails
• Aujourd'hui, il vous suffit de saisir un nom d'utilisateur / mot de passe. Quelles étapes de configuration supplémentaires les e-mails protégés par e2e nécessitent-ils? Ma grand-mère accepte-t-elle toutes sortes de configurations de sécurité?
• Qu'en est-il de plusieurs appareils? Comment gérer plusieurs appareils? Outlook + mobile par exemple. Oh, et le webmail lorsque vous êtes en itinérance

Prenons un exemple: Whatsapp. Il n'a jamais eu de fonction pour partager l'historique des conversations sur plusieurs appareils (la version de bureau de Whatsapp télécharge les messages de votre téléphone qui doivent être connectés). Si vous perdez ou formatez votre téléphone et que vous n'avez pas de sauvegarde non chiffrée , votre historique est perdu.

Il y a une différence importante entre les deux.

Dans la théorie de la décision, il y a l'idée d ' Utilité , c'est-à-dire la valeur que quelqu'un attribue aux différentes options dans une décision . Pour un réseau d'infrastructure tel qu'un réseau routier, ferroviaire, Internet ou e-mail, la valeur pour un individu est dans le nombre de connexions potentielles / d'autres individus faisant partie du réseau, la valeur pour l'opérateur du réseau en tant que tout est le nombre de connexions, qui est de l'ordre du carré des membres.

Le problème avec ceci est que tant pour le membre individuel que pour l'opérateur, au départ, le coût est très élevé, alors que dans tournez la valeur est faible. Il faut franchir un certain seuil (appelé masse critique ) jusqu'à ce que la valeur l'emporte réellement sur le coût. Pour l'opérateur, cela signifie généralement que seuls les grands opérateurs peuvent réellement se permettre de construire un tel réseau. Historiquement, cela a signifié les organisations gouvernementales. Cela signifie également que cela n'a aucun sens d'avoir plusieurs réseaux: plus le réseau est grand, plus la valeur est élevée, et une fois dépassée la masse critique, la valeur augmente plus vite que le coût. La combinaison de ces deux conduit à ce que l’on appelle un monopole naturel où un seul opérateur «gagne» et déplace tous les autres sans même travailler vers cet objectif. L'opérateur devient un monopole non pas par l'action, mais simplement en raison de la façon dont le marché de ce bien particulier fonctionne.

En bref: pour le courrier électronique crypté, aucune entité n'est prête à investir le coût du réseau, et les individus n'investiront pas le coût, parce que… eh bien… pourquoi le feraient-ils? Pourquoi devrais-je passer par tous les tracas liés à la configuration des e-mails chiffrés s'il n'y a personne à qui je peux les envoyer?

La situation est très différente pour HTTPS: ici, il y a un avantage pour chaque opérateur de serveur individuel. Protéger leurs utilisateurs protège leur entreprise. La valeur est de l'ordre du nombre d'utilisateurs, alors que le coût est quasiment constant (et plutôt faible, quasiment inexistant avec des services comme Let's Encrypt) avec seulement un léger coût linéaire en consommation électrique par utilisateur. Vous n'avez pas besoin d'ajouter TLS à un grand nombre de serveurs du réseau pour voir un avantage, et aucun investissement initial massif n'est nécessaire. Cela peut être fait serveur par serveur par chaque opérateur de serveur individuel avec un faible coût initial et de fonctionnement, et une valeur immédiate.

(Je passe sous silence l'infrastructure de certificat nécessaire ici, ce qui est encore un exemple d'un réseau d'infrastructure avec un monopole naturel, mais c'est un problème beaucoup plus petit, car les participants ne sont essentiellement que les autorités de certification, pas "tous les utilisateurs Web", ce qui serait un problème complètement insoluble.)

C'est la distribution des clés.

Je n'entrerai pas dans tous les détails sanglants, mais lorsque vous vous connectez à un site HTTPS, certaines choses se produisent. Votre ordinateur échange des clés avec le site et, surtout, valide que le site (par exemple votre banque) est bien votre banque. S'il ne le faisait pas, quelque chose pourrait prétendre être votre banque, décoder votre trafic, lire vos mots de passe et envoyer le trafic vers la banque (c'est ce qu'on appelle une attaque Man In the Middle (MITM)).

Pour arrêter cela, lorsque vous configurez un site SSL, vous devez obtenir un certificat qui est garanti par une partie de confiance qui a vérifié votre propriété du nom de domaine. Auparavant, c'était assez difficile et coûteux (des centaines de dollars), mais comme cela n'était nécessaire que pour les sites, plutôt que pour l'utilisateur final, cela était toléré. (Récemment, c'est devenu moins cher et plus facile, mais ce n'est toujours pas trivial.)

Pour qu'un système similaire puisse être utilisé pour le courrier électronique, les utilisateurs finaux doivent passer par un processus de vérification similaire. Étant donné que les utilisateurs s'attendent à ce que les e-mails soient gratuits, ils ont hésité à le faire.

(L'autre moyen est que vous avez un système distribué plutôt qu'un modèle d'organisation de confiance - c'est moins cher, populaire en tant que question politique, mais gênant dans la pratique).

Pour répondre à la question principale:

Pour de nombreux sites HTTPS, vous n'avez même pas le choix. Ils vous redirigent vers HTTPS et utilisent souvent HSTS ce qui vous empêche de revenir à HTTP.

Lorsqu'un site ne vous redirige pas, il y a toujours des utilisateurs qui utilisent simplement HTTP sans TLS, car ils ne se soucient pas de indicateurs de sécurité dans la barre d'adresse.Lorsque HTTP (sans TLS) était plus populaire, les sites appliquaient souvent TLS sur les pages de connexion, de sorte que vos mots de passe sont protégés, vous offrant donc pas le choix non plus.

Donc, lorsque l'utilisateur ne le fait pas attention, la décision est du côté de l'administrateur du site / e-mail. L'ajout de TLS est facile et fonctionne sur tous les navigateurs modernes et si vous le souhaitez vraiment, vous pouvez prendre en charge les (très) vieux navigateurs en proposant HTTP sans TLS. Comme cela est généralement transparent pour l'utilisateur, comme mentionné ci-dessus, vous pouvez décider librement et l'ajout de cryptage ne peut améliorer votre classement que par les utilisateurs (puissants).

Pour le courrier électronique, cela semble complètement différent. Lorsque vous souhaitez communiquer avec l'utilisateur de manière cryptée, l'utilisateur doit installer un programme de messagerie ou des modules complémentaires de navigateur, créer une clé, gérer la clé, s'assurer que la clé est disponible sur tous les appareils qu'il utilise et éventuellement entrer une phrase de passe à partir de de temps en temps.

C'est un fardeau pour l'utilisateur et quand il ne comprend pas de quoi il s'agit, cela le fera penser à de l'ennui. Le déploiement du chiffrement n’est donc pas du tout transparent, mais nécessite que l’utilisateur apprenne un nouveau flux de travail et utilise un flux de travail plus compliqué. Pour un utilisateur qui ne connaît pas la différence ou ne se soucie pas de cela, c'est une raison contre votre service.

Tout comme HTTPS, il existe une sécurité de la couche de transport pour les e-mails et parce que c'est tout aussi transparent pour l'utilisateur comme HTTPS est, il est largement déployé. Il y a quelques inconvénients (comme les solutions de secours aux connexions non chiffrées), mais en général, de nombreux courriers sont transmis chiffrés entre les serveurs de messagerie et entre le premier / dernier serveur de messagerie et le client expéditeurs / destinataires.