Question:
Quelles sont les étapes de Gmail, Yahoo! Mail et Hotmail prennent-ils pour empêcher les écoutes clandestines sur les e-mails?
luben
2011-08-23 03:27:45 UTC
view on stackexchange narkive permalink

Je voudrais savoir ce qui se passe lorsqu'un e-mail est envoyé à partir des services de messagerie Web publics Gmail, Yahoo ou Hotmail?

Je ne comprends pas les protocoles de messagerie en détail, mais pour autant que je sache, les e-mails le trafic n'est pas chiffré et les messages sont transmis sur de nombreux serveurs de messagerie (en texte brut) avant d'atteindre leur serveur de destination. Cependant, cela a été récemment remis en question par d'autres personnes, et leur point de vue était que si l'un des grands fournisseurs est utilisé, les messages électroniques sont cryptés et il n'y a pas besoin de s'inquiéter de la sécurité.

Savez-vous si ils ont raison à ce sujet et les e-mails sont-ils moyennement sécurisés? Merci!

Pouvez-vous préciser que vous parlez de leurs services de messagerie publics et non de leur système de messagerie électronique?
Quatre réponses:
gowenfawr
2011-08-23 03:40:40 UTC
view on stackexchange narkive permalink

Une session SMTP entre deux serveurs de messagerie peut être chiffrée, mais seulement si les deux extrémités la prennent en charge et si les deux extrémités choisissent de l'utiliser . Donc, si vous envoyez des e-mails de Gmail à example.net, Google ne pourrait chiffrer que si example.net était prêt et disposé. Pour cette raison, vous ne pouvez pas faire confiance au courrier électronique, même modérément sécurisé au niveau de la couche de transport. (La seule méthode sûre de bout en bout consiste à crypter vos e-mails à l'aide de S / MIME ou PGP, mais les personnes avec lesquelles vous échangez des e-mails doivent également être à bord ... tout comme les serveurs de messagerie).

Quant à savoir si les trois grands exécutent des STARTTLS opportunistes, je n'en ai vu aucune preuve, mais je passe moins de temps à lire les journaux de mon serveur de messagerie qu'auparavant. Et s'ils le sont, ils ne représentent toujours que la moitié de chaque connexion SMTP qu'ils établissent, et ne peuvent pas garantir l'utilisation du chiffrement.

Mise à jour:

Je viens de tester les hôtes MX pour gmail .com, yahoo.com et hotmail.com. Seul gmail fait la publicité de STARTTLS, c'est-à-dire que seul gmail serait prêt à chiffrer la session SMTP si l'autre partie le souhaitait.

J'ai testé gmail sortant en envoyant du courrier à un serveur que je possède et en surveillant le fil; Google profite en effet de STARTTLS s'il est proposé et crypte la transaction SMTP lorsqu'un utilisateur gmail envoie du courrier. Props to Google.

En ce qui concerne le cryptage des e-mails: Google 1, Yahoo 0, Microsoft 0.


Selon les commentaires ci-dessous, si vous le souhaitez pour les tester vous-même, c'est très simple:

  1. Déterminez les hôtes MX (Mail eXchangers) pour le domaine
  2. Telnet vers le port 25 sur l'un d'eux
  3. Tapez "ehlo yourhostname.domain.com"
  4. Si vous ne voyez pas "250-STARTTLS" comme l'une des réponses, ils ne prennent pas en charge le chiffrement opportuniste.
  5. ol>

    Comme ceci:

      $ host -t mx yahoo.comyahoo.com le courrier est traité par 1 mta5.am0.yahoodns.net.yahoo.com le courrier est traité par 1 mta7 Le courrier .am0.yahoodns.net.yahoo.com est géré par 1 mta6.am0.yahoodns.net.
    $ telnet mta5.am0.yahoodns.net 25Essai 66.196.118.35 ... Connecté à mta5.am0.yahoodns.net.Le caractère d'échappement est '^]'. 220 mta1315.mail.bf1.yahoo.com Le service ESMTP YSmtpProxy est prêt pour mon hôte. linode.com250-mta1315.mail.bf1.yahoo.com250-8BITMIME250-SIZE 41943040250 PIPELININGquit221 mta1315.mail.bf1.yahoo.comConnexion fermée par un hôte étranger. $  

    En remarque, Yahoo fermera la connexion si vous n'effectuez pas d'ehlo tout de suite. J'ai dû couper & coller mon ehlo car la saisie a pris trop de temps.

    PLUS DE MISE À JOUR:

    Depuis janvier 2014, Yahoo est en train de chiffrer - Je viens de tester (comme ci-dessus) et de vérifier. Cependant, The Register et Computerworld signalent que les subtilités de la configuration SSL (telles que Perfect Forward Secrecy) laissent beaucoup à désirer comme implémenté par Yahoo.

    MISE À JOUR ENCORE PLUS MORTE:

    Google inclut désormais les données de chiffrement SMTP dans sa section Transparency Report Safer Email. Ils partagent leurs données sur les autres personnes souhaitant chiffrer, et vous pouvez consulter les premiers chiffres et interroger des domaines individuels.

    Addendum:

    @SlashNetwork indique qu'il est possible de configurer un serveur de messagerie pour exiger que TLS soit négocié avant d'échanger du courrier. C'est vrai, mais pour citer la documentation de Postfix:

    Vous pouvez FAIRE APPLIQUER l'utilisation de TLS, de sorte que le serveur SMTP de Postfix annonce STARTTLS et n'accepte aucun courrier sans TLS chiffrement, en définissant "smtpd_tls_security_level = encrypt". Selon RFC 2487, cela NE DOIT PAS être appliqué dans le cas d'un serveur SMTP Postfix référencé publiquement. Cette option est désactivée par défaut et ne devrait être utilisée que rarement.

    Maintenant, le monde est plein d'implémentations qui violent les RFC, mais ce genre de chose - par exemple, quelque chose qui peut briser les fonctionnalités requises de routine comme l'acceptation des rebonds et du courrier pour le postmaster - est probablement plus susceptible d'avoir des conséquences négatives.

    Une meilleure solution que les passerelles de messagerie autorisent souvent est l'imposition de exigences TLS sur la base d'une politique par domaine. Par exemple, il est généralement possible de dire «Exiger TLS avec un certificat valide signé par Entrust lorsque vous parlez à example.com». Ceci est généralement mis en œuvre entre des organisations qui font partie de la même société mère mais qui ont une infrastructure différente (pensez: acquisitions) ou des organisations ayant une relation commerciale (pensez: ACME, Inc., et leur société de centre d'appels de support externalisé). Cela présente l'avantage de garantir que les sous-ensembles spécifiques de courrier qui vous intéressent soient chiffrés, mais ne rompt pas l'architecture ouverte (acceptée par n'importe qui par défaut) de la messagerie SMTP.

    Addendum ++

    Google a annoncé que gmail transmettra des informations sur la sécurité si le chemin de la messagerie vers le lecteur. Donc, ces étapes de cryptage en coulisses seront un peu plus portées à la connaissance de l'utilisateur.

    (Probablement ne se soucie toujours pas de la provenance du certificat; juste un indicateur de cryptage des bits) .

Merci pour la réponse, c'était un aperçu très utile des possibilités de cryptage!
Lorsque l'attaquant répond à STARTTLS qu'il n'est pas pris en charge, gmail continue d'être non chiffré.
Quelqu'un pourrait-il réexécuter ce test et voir si Yahoo ou MS s'est amélioré depuis 2011? Le service de messagerie Yahoo est si mauvais que je doute qu'ils aient changé.
Je viens de refaire le test (06/12/2013) et ni Yahoo ni Hotmail n'offrent STARTTLS. Le processus de test est simple; Je vais l'ajouter à la réponse ci-dessus pour que vous puissiez essayer vous-même.
Est-il possible de détecter si un e-mail a été transmis en toute sécurité (par exemple, si STARTTLS a été utilisé) en regardant les en-têtes d'e-mail?
@SimonEast, oui ça l'est. Voir [Comment déterminer si le courrier a été chiffré pendant le transport à l'aide des informations d'en-tête?] (Http://security.stackexchange.com/questions/92301/how-to-determine-if-mail-was-encrypted-during-transport- using-the-header-informa) et [Comment vérifier qu'un service de messagerie fournit un cryptage entre les serveurs de messagerie?] (http://security.stackexchange.com/questions/61824/how-to-check-that- un-service-de-messagerie-fournit-le-cryptage-entre-les-serveurs-de-messagerie / 61825 # 61825).
Je pense que nous ne pouvons forcer que TLS à être utilisé avec STARTTLS. Dans ce cas, la connexion reste sécurisée avec le serveur de messagerie.
@SlashNetwork oui, c'est possible, mais viole la RFC 2487 pour les serveurs de messagerie accessibles au public. J'ajouterai une note à ce sujet à la réponse car je pense que c'est intéressant :)
J'apprécie l'engagement à long terme pour la réponse.
tdammers
2011-08-23 13:28:28 UTC
view on stackexchange narkive permalink

Il y a trois points dans la chaîne que vous devez prendre en compte: le transport entre les serveurs de messagerie (par exemple entre Google et example.org), le transport entre les serveurs de messagerie et les clients, et les serveurs de messagerie eux-mêmes.

Trafic entre les serveurs de messagerie peuvent ou non être cryptés; vous ne devriez pas vous y fier, et AFAIK, il n'y a aucun moyen de l'appliquer à partir du client.

Le trafic entre les clients et les serveurs de messagerie peut ou non être chiffré; si vous vous connectez via SSL (soit via une interface Web ou SMTP), votre extrémité de chaîne est sécurisée, mais vous ne pouvez rien dire sur le destinataire. Inversement, si vous êtes le destinataire, vous pouvez récupérer le courrier en toute sécurité, mais si l'expéditeur (ou n'importe qui dans le CC / Cci) ne fait pas la même chose, alors il y a votre fuite.

Et enfin, il y a les serveurs de messagerie eux-mêmes. Si quelqu'un les pirate, ou si des ingénieurs sociaux s'y frayent un chemin, et que le serveur de messagerie stocke le contenu non chiffré, alors vous n'avez pas de chance.

TL; DR: À moins que vous ne contrôliez toute la chaîne (les deux clients, et tous les serveurs de messagerie impliqués), ce qui n'est pratiquement jamais le cas, la seule façon d'envoyer des e-mails avec une sécurité fiable est de crypter et de décrypter localement, en utilisant quelque chose comme PGP.

Mike Samuel
2011-08-23 03:52:02 UTC
view on stackexchange narkive permalink

Il y a deux questions différentes ici:

  1. Le système de messagerie autorise-t-il l'envoi d'e-mails via un canal crypté et l'envoi d'e-mails via un canal crypté lorsque le serveur de messagerie du destinataire le prend en charge.

    / li>

  2. Le système de messagerie crypte-t-il le contenu d'une boîte aux lettres lors de son affichage au propriétaire?

gownfawr addresses (1) bien.

Gmail crypte par défaut pour (2) donc lors de la visualisation de votre courrier, par défaut, cela se fait via HTTPS, donc un snooper ne pourra pas observer gmail envoyer le courrier à votre navigateur. Je crois que les autres n'ont pas encore suivi la suite. (Divulgation complète, je travaille pour Google).

Gmail est configuré pour utiliser le paramètre "Toujours utiliser https " par défaut, ...

"Rendre votre messagerie Web plus sécurisée" contient des instructions pour éviter les lectures en texte brut d'une boîte aux lettres pour un certain nombre de grands fournisseurs de messagerie Web, mais je ne peux pas garantir qu'il soit à la hauteur de - date.

+1 bonne séparation des deux aspects. Assez certain que la réponse à 1 est "Pas par défaut, mais les 3 le feront si nécessaire et les deux extrémités le prennent en charge, et (le cas échéant) les clés ont été échangées"
Merci pour la réponse! À propos de l'ecnryption - Je demandais les messages lorsqu'ils sont envoyés par le serveur de messagerie, pas l'interface utilisateur utilisée par les utilisateurs finaux pour vérifier leur boîte de réception. Il était intéressant pour moi de comprendre que seuls 2 serveurs de messagerie sont impliqués.
En fait, il est courant que plus de 2 serveurs soient impliqués. Je viens de passer en revue 56 messages dans ma boîte de réception: 7% avaient un «saut» (deux serveurs), 18% avaient deux sauts, 57% avaient trois sauts, 2% avaient quatre sauts, 4% avaient 5 sauts et 12% en avaient 6 du houblon. Un saut peut représenter un client à serveur SMTP, mais le reste sera de serveur à serveur. (Les 6 sont tous des courriers Yahoo, qui rebondissent dans Yahoo en utilisant NNFMP avant de sortir; je ne sais pas mais je soupçonne que NNFMP ne prend pas en charge le cryptage).
Merci @gowenfawr, pour l'explication. Le manque de cryptage au sein de Yahoo est moins inquiétant qu'à l'extérieur car il y a moins d'observateurs potentiels à l'intérieur du pare-feu de Yahoo.
Parmi les autres raisons potentielles de plusieurs sauts de messagerie, citons le routage de messagerie de division (par exemple, les grandes entreprises, un domaine, de nombreux sites et organisations), les services anti-SPAM (par exemple, Cloudmark, Postini), les passerelles anti-SPAM et antivirus (Barracuda). Pour voir où votre courrier a été, regardez les en-têtes; il y aura plusieurs en-têtes "Received:". Chaque fois qu'un serveur de messagerie accepte un message électronique, il ajoute son propre en-tête "Received", de sorte que chacun représente un saut, et vous pouvez voir quels serveurs (nom et / ou IP et parfois logiciel) ont touché votre courrier électronique. Certains noteront également s'ils ont utilisé SSL pour ce saut.
@gowenfawr, Ah. Dans une grande entreprise distribuée, cela peut impliquer plusieurs sauts à travers des nœuds en dehors de tout pare-feu d'entreprise, vous avez donc un problème de liaison la plus faible.
MrBrian
2014-06-07 18:54:19 UTC
view on stackexchange narkive permalink

Vous pouvez tester par vous-même en utilisant les sites Web mentionnés dans Tester la configuration STARTTLS du serveur SMTP. Assurez-vous de tester à la fois la réception et l'envoi.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...