Pourquoi les transferts d'e-mails entre serveurs de messagerie ne sont-ils souvent pas cryptés?


19

Les utilisateurs peuvent souvent choisir s'ils souhaitent accéder à leur fournisseur de messagerie (tel que Gmail) en utilisant un canal sécurisé (par exemple en utilisant HTTPS).

Cependant, à ma connaissance, en ce qui concerne les communications de serveur de messagerie à serveur de messagerie, la plupart des e-mails sont toujours transférés en texte brut et non cryptés, ce qui permet à quiconque sur le réseau de lire leur contenu.

Existe-t-il des technologies qui donnent à l'utilisateur des garanties que ses e-mails sont envoyés en toute sécurité de bout en bout? Pourquoi ne pas informer l'utilisateur lorsque le cryptage n'est pas pris en charge et lui laisser le choix s'il souhaite que son e-mail soit toujours remis?

Réponses:


19

Cependant, à ma connaissance, en ce qui concerne les communications de serveur de messagerie à serveur de messagerie, la plupart des e-mails sont toujours transférés en texte brut et non cryptés, ce qui permet à quiconque sur le réseau de lire leur contenu.

Correct. SMTP, comme HTTP, est en texte brut par défaut.

De nos jours, de nombreux serveurs de messagerie prennent en charge TLS (anciennement SSL) pour SMTP. (Cela inclut Gmail.) Cependant, il présente les mêmes problèmes qu'avec HTTP [S]: les certificats émis par des autorités de certification bien connues coûtent de l'argent, et les certificats auto-signés sont sans valeur 1 pour la protection contre les attaques MitM . Si votre serveur de messagerie effectue une validation stricte du certificat du destinataire (comme le font les navigateurs Web), il peut ne pas remettre les messages aux serveurs qui utilisent des certificats auto-signés ou des autorités de certification internes. Si ce n'est pas le cas , alors il ne peut pas être sûr qu'il parle au bon serveur et non à un imposteur .

De plus, TLS est un ajout relativement récent à SMTP, donc même lorsque le serveur de messagerie du destinataire prend en charge TLS, l'expéditeur peut ne pas le faire, ou il peut être désactivé par défaut.

1 (Sauf si le serveur d'envoi prend en charge DANE (TLSA) et que l'administrateur du serveur de réception se soucie de publier les enregistrements TLSA dans DNS. Cela est rarement fait et quelque peu fastidieux.)

Existe-t-il des technologies qui donnent à l'utilisateur des garanties que ses e-mails sont envoyés en toute sécurité de bout en bout?

Deux normes de sécurité de messagerie les plus courantes:

  • OpenPGP , basé sur un réseau de confiance et gratuit à utiliser. L'implémentation open source est GnuPG ( pour Windows , pour Thunderbird ), et le PGP d'origine a évolué vers le PGP Desktop commercial .

    Pour les clients de messagerie Web, FireGPG est une possibilité - bon sang

  • S / MIME , basé sur l'infrastructure X.509. Mis en œuvre par la plupart des clients de bureau (y compris Outlook, Thunderbird, Mail.app). Cependant, relativement impopulaire en raison de la même structure basée sur l'autorité que TLS / SSL: les certificats signés coûtent de l'argent, et les certificats auto-signés ne peuvent pas être validés de manière fiable.

Dans les deux cas, le chiffrement nécessite que le destinataire utilise déjà le système et ait généré / obtenu une paire de clés. (Pour la signature , la paire de clés de l' expéditeur est utilisée. La pratique normale consiste à la fois à signer et à chiffrer les messages.)

Pourquoi ne pas informer l'utilisateur lorsque le cryptage n'est pas pris en charge et lui laisser le choix s'il souhaite que son e-mail soit toujours remis?

Habituellement, les messages soumis sont mis en file d'attente , et ni l'utilisateur ni le MTA ne peuvent savoir si le saut suivant prend en charge TLS ou non - jusqu'à ce que le message soit envoyé , auquel cas il n'existe aucun moyen fiable de demander à l'utilisateur une confirmation. (Ils peuvent être AFK, hors ligne, endormis ou un script / programme. Si j'ai envoyé le message, je veux qu'il soit remis dès que possible.)

De plus, avec SMTP, vous ne savez jamais si le prochain saut est final ou s'il ne fera que relayer le courrier ailleurs. Il n'est pas rare qu'une sauvegarde MX soit sur un réseau entièrement différent.

Donc. la sécurité de bout en bout n'est possible que lorsque les deux parties utilisent OpenPGP ou S / MIME.


2
Remarque: la question et ma réponse concernent l'échange de courrier entre deux serveurs SMTP sur le port 25. Peu importe s'il existe une prise en charge TLS sur les ports 587 ou 465; ce sont uniquement pour la soumission de messages par un utilisateur [distant].
user1686

2
J'ai cru comprendre que le plus souvent, la connexion SMTP n'était PAS cryptée. Vous pouvez cependant obtenir des certificats de messagerie gratuits (qui valident) ici: instantssl.com/ssl-certificate-products/…
Andee

Mise à jour: de nos jours, l'interface utilisateur de Gmail vous avertit lorsque le domaine d'un destinataire ne prend pas en charge le cryptage, et les instructions suggèrent de se garder d'envoyer des informations confidentielles.
Blaisorblade

4

Le trafic e-mail réel est souvent crypté (TLS) mais il existe plusieurs autres problèmes:

  • Certains clients de messagerie Web qui affichent des messages HTML peuvent être non sécurisés bien qu'ils utilisent HTTPS, il n'y a pas de séparation matérielle entre le code et les données en HTML par exemple (éléments visuels et javascript -> attaques par injection)

    • le webmail conserve également les e-mails sur le serveur au lieu de les télécharger et de les stocker sur l'ordinateur local
  • Vous n'avez aucun moyen de savoir si TLS / SSL a été utilisé entre chaque étape, les très petits serveurs N'ONT PAS de certificats appropriés

    • l'expéditeur doit être au moins en mesure de spécifier s'il accepte ou non l'envoi de l'e-mail via un canal non sécurisé
  • Les e-mails se trouvent sur des serveurs non cryptés ou cryptés par le serveur

    • vous devrez faire confiance à CHAQUE serveur entre vous et le destinataire
  • Les e-mails peuvent être transférés par n'importe quel itinéraire, vous ne pouvez pas spécifier les serveurs auxquels vous faites confiance (plages d'adresses IP, AS, pays, domaines ..)

  • Les grands serveurs de messagerie n'utilisent pas plusieurs certificats différents et ne les modifient pas assez souvent (?)

    • cela vaut peut-être la peine de les forcer (comme les États-Unis, le Royaume-Uni, etc. ont essayé?)
  • en suivant le trafic, ils savent quand un e-mail a été envoyé et quelque chose sur le destinataire (quels serveurs communiquent entre eux)

    • les darknets cachent ces corrélations
  • La mise en œuvre d'OpenSL était / est un gâchis

    • il y a peut-être des bugs
  • vous devez faire confiance aux autorités de certification qui signent les certificats


2

Elles sont. Ou très souvent.

Soit via SSL, soit TLS .

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

Ou si vous êtes vraiment paranoïaque, il y a PGP ou GPG.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.