L'application du cryptage pour SMTP est-elle une bonne idée (pour le moment)?

36

J'utilise un serveur de messagerie actuellement configuré pour utiliser TLS, si possible, lors de l'envoi et de la réception d'e-mails.

Lorsque vous lisez la documentation à ce sujet, vous avez également la possibilité d’appliquer TLS et de ne pas accepter la transmission de courriers électroniques en texte brut. Il vous avertit également que certains serveurs de messagerie risquent de ne pas encore prendre en charge le cryptage et que le cryptage peut bloquer ces serveurs.

Mais est-ce toujours un problème auquel on devrait penser ou faut-il dire en toute sécurité que l’application du cryptage ne sera plus un problème?

Existe-t-il un gros fournisseur qui le fait déjà ou que considérez-vous comme la meilleure pratique de nos jours?

encryption tls smtps

— comfreak
source

34

Le problème pratique est que tous les serveurs compatibles SMTP (le RFC est assez ancien) ne peuvent parler TLS à votre serveur, vous pouvez donc ne pas recevoir certains messages électroniques.

Le problème philosophique avec ceci est qu'il est impossible de dire comment l'e-mail est relayé après (ou avant) qu'il soit arrivé sur votre serveur.

Cela signifie que le courrier électronique a peut-être déjà été transmis en clair via un relais.

Toute personne soucieuse de protéger le contenu de son courrier électronique devrait en fait chiffrer le corps. Avec le cryptage en route, il est toujours plausible, il a déjà été transmis en clair.

Donc, répondre à votre question imposer le cryptage au niveau de la couche SMTP est probablement inutile, cela augmente vos chances de rater des courriels et il n'y a pas de rentabilité bénéficiaire garantie.

Modifier: il s’agit de l’application du protocole SMTP à des fins de relais, et non de soumission de courrier électronique. Dans les envois de courrier, le chiffrement doit être appliqué car la conversation SMTP (et non le courrier électronique réel) contient éventuellement des informations d'authentification.

— Matthew Ife
source

7

Je ne pense pas que ce soit la meilleure réponse. Cela aboutit à la bonne conclusion, mais pour les mauvaises raisons. C'est "laisser le parfait être l'ennemi du bon", ce genre de raisonnement. Je pense que la meilleure réponse est que si vous avez besoin d'un cryptage, vous empêcherez le passage de courriers électroniques légitimes (car certains serveurs SMTP ne peuvent pas crypter). Si ce n’était pas le cas, l’application du cryptage serait bénéfique, même si, pour toutes les raisons que vous citez, il n’est pas parfait - ce serait mieux que rien, même si ce n’est pas parfait.

— DW

J'ai tendance à être en désaccord sur la perfection par simple addition de sous-imperfections; j'ai quand même soumis une modification à la réponse pour mettre l'accent sur l'incompatibilité technique possible des serveurs conformes à la RFC mais ne prenant pas en charge TLS.

— Alex Mazzariol

Merci pour votre réponse! Au début, je ne pensais pas à ce qui se passait après que mon serveur ait envoyé le courrier au serveur suivant ou, comme vous l'avez dit, où le message "a déjà été" avant de me parvenir. Bien sûr, il n’est pas judicieux d’imposer le cryptage si le destinataire le transmet en texte clair (peut-être à un sous-serveur de la même société mais toujours sur Internet).

— Comfreak

J'ai choisi cette réponse comme étant acceptée car elle indique clairement que le cryptage sur mon serveur ne garantira pas un transfert sécurisé / crypté du message de l'expéditeur au destinataire, mais uniquement de mon serveur à l'autre.

— Comfreak

Je pense que cette réponse est bonne, mais omet de mentionner que le cryptage est toujours souhaité, car ce n'est que dans un nombre limité de cas que quelqu'un ferait tout son possible pour intercepter le message en texte clair de l'expéditeur afin de vous tromper. Si vous vous cachez de la CIA / NSA, assurez-vous que cela ne vous aidera pas. Mais quoi de mieux que de renforcer le cryptage de sorte que personne avec un intérêt explicite ne le lise / intercepte le message de l'expéditeur et le cache jusqu'à ce qu'un tiers décide d'essayer de vous surveiller ou de faire en sorte que tous vos messages soient stockés sur les serveurs de la NSA afin que un jour, ils peuvent non seulement commencer ...

— momomo

20

Non

Le RFC 821 a 33 ans. Vous y trouverez des courriels relayés par des programmes notsupporting STARTTLS. Parfois, ce sont des expéditeurs de courrier électronique (par exemple, des scripts internes), parfois des systèmes à part entière qui sont vieux, dont le protocole TLS est désactivé / non compilé, des systèmes sans assez d'entropie…

Il n'y a pas si longtemps, j'ai constaté l'échec des e-mails sortants, car le destinataire l'avait configurée pour autoriser uniquement le protocole SMTP sur TLS. C'était un problème dans l'expéditeur (il n'aurait pas dû utiliser cette configuration), mais cela montre que cela se produit.

Je limiterais uniquement les messages entrants à partir d'adresses IP configurées manuellement. Si votre processeur de carte de crédit ne parvient pas à démarrer STARTTLS, vous préférerez probablement interrompre la connexion (et contacter l'administrateur local afin qu'il puisse le prévenir!) Plutôt que de recevoir ces données (potentiellement sensibles) non chiffrées. Pour les messages sortants, si vous vous êtes déjà connecté à cet hôte à l'aide de STARTTLS, vous souhaiterez peut-être ne pas le faire de nouveau de manière non sécurisée, en le considérant comme un compromis potentiel. Vous pouvez également disposer d'une liste d'hôtes STARTTLS connus pour une utilisation constante, tels que gmail ou yahoo.

Il existe un projet https://www.eff.org/starttls-everywhere fournissant une liste de serveurs smtp pour lesquels vous pouvez (devriez?) Appliquer en toute confiance l'utilisation de starttls.

— Ange
source

3

Merci pour la réponse et pour poster ce lien! Cela semble être une bonne approche pour résoudre le problème d’une attaque de type "man-in-the-middle" qui rétrograde la connexion en une conversation non chiffrée.

— Comfreak

11

Il est totalement inutile, et probablement activement préjudiciable, de refuser le courrier électronique de pairs incapables de chiffrer.

Tant que votre serveur est configuré pour effectuer le chiffrement opportuniste avec tout pair qui le propose, vous bénéficiez du meilleur des deux mondes: le chiffrement lorsqu'il est disponible et le courrier électronique en texte clair lorsqu'il ne l'est pas.

Dans la mesure où certains serveurs ne prennent pas en charge le chiffrement, le rendre obligatoire signifie simplement qu'ils ne peuvent pas vous parler. c'est mauvais. Une fois que tout le monde le prend en charge, il n'y a plus aucune différence entre le cryptage opportuniste et le cryptage obligatoire.

Et comme d’autres l’ont souligné, le cryptage sur fil et le cryptage de bout en bout sont deux choses complètement différentes, qui traitent différents modèles de menaces. Ne confondez pas les deux.

— MadHatter soutient Monica
source

Je dirais que le meilleur des deux mondes vous permettrait également de voir la différence, semblable au "verrou" d'une page SSL sur le Web, afin que vous sachiez quels e-mails auraient été * bloqués si vous aviez forcé TLS

— utilisateur2813274

@ user2813274 Je suis d'accord, et c'est le cas. Vérifiez vos en-têtes; ils vous indiqueront si une étape donnée de la chaîne de transmission a été réalisée avec ou sans cryptage.

— MadHatter soutient Monica

@MadHatter, sauf si ces en-têtes ont été totalement forgés par le saut avant le vôtre.

— Thrig

8

Il existe une différence entre le cryptage opportuniste et le cryptage obligatoire. Il est souvent possible pour un MITM actif de perturber le cryptage opportuniste, ce qui empêche les ordinateurs d'extrémité de ne plus utiliser de cryptage, ce qui peut être surveillé. Avec un cryptage obligatoire, la connexion serait interrompue, ce qui causerait un déni de service mais pas une violation de la vie privée.

— cjm

4

@cjm d'où mon point sur les modèles de menace. Si vous essayez sérieusement de vous défendre contre les attaques MITM, seul un chiffrement de bout en bout peut vous aider. Se fier uniquement au cryptage SMTP n’a aucun sens; un MITM sophistiqué se contentera de se faire passer pour votre serveur, puis de relayer le courrier sur vous après l'avoir lu. Bien sûr, votre serveur peut avoir un certificat correctement signé (ce qui est étonnamment rare), mais vous ne pouvez pas contrôler si le système qui vous l’envoie en a besoin , donc une telle attaque réussira, malgré toutes les exigences que vous imposez sur une connexion chiffrée. .

— MadHatter soutient Monica

10

C'est une question de politique.

Généralement, lorsque TLS est appliqué pour les communications entrantes et sortantes, il s'applique à un nombre limité de domaines convenus par les parties pour répondre à un besoin (par exemple, les partenaires commerciaux peuvent avoir un accord pour crypter tous les messages entre leurs entreprises).

À moins qu'un tel accord ne soit en place, n'activez pas le mode application.

— MikeyB
source

2

Non, c'est une très mauvaise idée.

En fait, la plupart des serveurs / clients STARTTLS n’implémentent aucun algorithme de nouvelle tentative sans StartTLS en cas d’échec de la négociation d’une connexion TLS.

En tant que tel, même la publicité de STARTTLS en tant qu'option réduit déjà vos chances de recevoir (et d'envoyer) des courriels!

Effectuez une recherche et vous constaterez que de nombreuses personnes ne peuvent envoyer AUCUN courrier électronique à des domaines Microsoft Outlook gérés par le cluster * .protection.outlook.com:

Messages Sendmail rejetés par Microsoft lors de l'utilisation de TLS

raison: 403 4.7.0 La poignée de main TLS a échoué

Pour résumer les problèmes présentés dans les deux articles ci-dessus:

peut envoyer n'importe quel courrier à un hôte autre que ceux gérés par Outlook, avec ou sans STARTTLS,
peut envoyer un courrier sans certificat client et sans STARTTLS à Outlook,
ou avec un certificat client de longueur nulle,
mais pas avec un certificat que Microsoft n'aime pas, et en cas d'échec, les clients (ainsi que les serveurs agissant en mode client) n'essayent pas de renvoyer le message sans STARTTLS si le serveur du destinataire publie STARTTLS!

De même, lorsque votre hôte agit en tant que serveur, une situation similaire peut se produire en dehors de votre contrôle si vous décidez d'activer STARTTLS - lorsqu'un serveur client voit que votre serveur offre STARTTLS en mode serveur, il essaie de négocier TLS, mais en cas d'échec de la négociation , ils attendent simplement, et recommencez les mêmes étapes, échouez jusqu'à ce que le message soit renvoyé à l'expéditeur!

Et cela arrive assez souvent avec différents domaines du pays STARTTLS!

Malheureusement, bien que j’ai été un partisan de STARTTLS dans le passé, je suis maintenant très déshérité du fait que j’ai été induit en erreur par la publicité sans risque de ce que je pensais être un cryptage opportuniste.

Non seulement vous n’avez pas besoin de STARTTLS, mais il peut même être prudent de le désactiver complètement si vous voulez assurer l’interopérabilité.

— cnst
source

2

Je suis d'accord avec l'idée d'utiliser le TLS opportuniste. Bien que, j’en ai d’autres à ajouter à l’idée. Certains seront probablement dérangés par les suggestions, cependant, comme mes suggestions ici ne sont pas faites à la légère et sans considération suffisante, avant de porter un jugement, je vous prie de bien vouloir lire le texte intégral de la discussion à partir du lien ci-joint.

L'utilisation de TLS opportuniste est de loin la meilleure solution. L'argument MITM comme argument est un véritable fil rouge. Après tout, comme MH l’a mentionné dans un commentaire, même un «légitime» SMTP avec une connexion TLS peut être MITM et l’utilisateur final ne doit pas en être averti du fait que la grande majorité des clients de messagerie ne se soucient pas de valider les certificats couplés à la grande majorité. TLS utilise des certificats auto-signés (du moins si vous n'utilisez pas DNSSEC et TLSA / DANE.) En conséquence de cela et peut-être d'autres facteurs, on peut même soutenir que tant que vous et le reste du monde a implémenté DANE / TLSA et DNSSEC, qui, lorsqu’il utilise TLS opportuniste, vaut mieux que d’avoir également activé la fonction anonyme Diffie-Hellman (tout en utilisant également PFS). Dû au moins en partie sinon principalement au fait qu'il cryptera toujours le trafic en le protégeant de l'observateur occasionnel. Pour plus de détails sur cette configuration (avec une explication beaucoup plus élaborée que la mienne), veuillez consulter les commentaires de Viktor Dukhovni dans ce post sur un forum postfix:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

Pour ce qui est de savoir pourquoi on pourrait prendre les suggestions de Viktor avant les autres, eh bien, il a écrit le code TLS ainsi que le code DNSSEC, TLSA / DANE pour le MTA de Postfix en plus d'avoir été celui qui a écrit les brouillons de l'IETF sur les deux DNSSEC et TLSA / DANE. En tant que tel, je dirais que ses propos sur la question ont beaucoup de poids, probablement plus que ceux de la plupart.

J'espère que cela t'aides.

— Mce128
source

0

Du point de vue du marketing par e-mail, l'utilisation de TLS est une bonne pratique et est sécurisée lorsque vous savez qu'il est implémenté tout au long de la chaîne de diffusion. Toutefois, si la sécurité est votre principale exigence, le cryptage de l'e-mail lui-même avant de l'envoyer est l'option la plus sécurisée (par exemple avec PGP).

— ERM
source