Comment (en) sécurité est POP / IMAP / SMTP
Je fais quelques hypothèses sur la sécurité de base des e-mails, et je veux confirmer ou clarifier certains de ces points pour m'assurer de bien comprendre la situation dans son ensemble. Veuillez me corriger là où je me trompe:
La réponse à cette question donne un aperçu, mais ne couvre pas tout ce que je recherche.
Tout cela suppose un service de messagerie traditionnel, accessible à l'aide d'un client de bureau ou mobile, via POP ou IMAP et SMTP (en ignorant le webmail).
Supposons que je récupère des messages - mon application cliente transmet mon nom d'utilisateur et mon mot de passe au serveur POP, qui m'authentifie et renvoie les messages. Si je n'utilise pas SSL/TLS, toute la conversation, y compris le message et les informations d'identification, est en texte clair. Et quiconque regarde le trafic réseau peut intercepter le tout. Et si j'utilise SSL, toute la conversation est sécurisée, même sur un réseau public. Ai-je ce droit?
Ma compréhension est que les messages traditionnels ne sont pas sécurisés lorsque mon serveur parle au serveur de quelqu'un d'autre - donc le message lui-même est probablement vulnérable pendant le transit entre les serveurs, mais au moins avec SSL, mon mot de passe de messagerie serait sûr.
Si je comprends bien, PGP ou similaire signifierait que le message lui-même est crypté, de sorte que tant que mes clés privées et celles du destinataire sont en sécurité, personne d'autre ne pourrait lire le message. Mais c'est juste le message, non? Pas la connexion IMAP/SMTP/POP? Ce qui signifie que si j'utilisais PGP pour le message, mais une connexion non SSL à SMTP, j'enverrais toujours un nom d'utilisateur et un mot de passe en texte brut pour l'authentification.
Fondamentalement, j'essaie de comprendre pourquoi un fournisseur de messagerie refuserait d'offrir SSL/TLS pour les connexions POP/IMAP/SMTP - un fournisseur particulier dit qu'il ne le fait pas parce que le courrier électronique est intrinsèquement non sécurisé, donc SSL ne fait pas réellement faites n'importe quoi pour vous protéger, et ils suggèrent PGP pour un courrier électronique vraiment sécurisé. Je voudrais faire valoir que, bien que SSL ne soit pas une protection de bout en bout des messages, il protégerait au moins mes informations d'identification et protégerait mon message pendant une partie importante de son parcours (moi vers le serveur SMTP et le serveur POP vers le destinataire en supposant ils se connectent avec SSL).
Dois-je tout droit avec ça?
Pour répondre à ta question:
Si vous utilisez SSL/TLS pour accéder à vos e-mails, que ce soit POP ou IMAP, il serait très difficile pour quiconque de déchiffrer le texte des e-mails en analysant le trafic seul. Cela dit, certaines grandes entreprises, par exemple un cabinet d'avocats pour lequel je travaillais, ont un serveur qui se trouvait entre nous et Internet, supprimant le SSL, donc la réponse est un oui qualifié en disant que vous êtes en sécurité.
De plus, si le message se trouve toujours sur le serveur de messagerie après y avoir accédé, il est possible que votre fournisseur de messagerie soit soudoyé/contraint à le remettre. Bien sûr, GPG résout ce problème. Vous pouvez également demander à votre fournisseur de messagerie de supprimer les messages que vous téléchargez via POP, mais vous devez être sûr qu'ils sont à la fois capables et désireux de supprimer les messages en toute sécurité.
Avec SSL, lorsque vous vous connectez en utilisant votre mot de passe de messagerie, votre mot de passe ne peut pas être lu facilement en interceptant le trafic entre votre ordinateur et le serveur de messagerie sous réserve de la condition que j'ai mentionnée au point un.
Votre compréhension de PGP est largement correcte. Si un message vous est envoyé codé avec votre clé publique, seul vous, notre personne qui a brisé votre clé privée, pouvez le lire. La clé privée de l'expéditeur n'est pas pertinente car il ne peut pas l'utiliser pour décoder un message qui vous est destiné. Si votre mot de passe e-mail a été envoyé en texte brut, vous avez tout à fait raison de penser qu'il pourrait être intercepté et que quelqu'un pourrait accéder à vos e-mails ou les envoyer en votre nom en se faisant passer pour vous. Si vous avez utilisé PGP à tout moment pour crypter et signer tous les messages et que d'autres ont fait de même pour vous, cela protégerait le contenu de vos messages.
Je ne peux pas imaginer pourquoi un fournisseur de messagerie ne voudrait pas offrir SSL au-delà de la pure paresse. Vous pouvez même obtenir des certificats gratuits de nos jours! La plupart des fournisseurs de messagerie Web gratuits proposent SSL, par exemple Gmail, avez-vous pensé à les utiliser?
Supposons que je récupère des messages - mon application cliente transmet mon nom d'utilisateur et mon mot de passe au serveur POP, qui m'authentifie et renvoie les messages. Si je n'utilise pas SSL/TLS, toute la conversation, y compris le message et les informations d'identification, est en texte clair.
Pas nécessairement . SMTP, POP et IMAP peuvent tous prendre en charge plusieurs mécanismes d'authentification, dont certains sont cryptés (par exemple, CRAM-MD5, GSSAPI). Voir une bonne liste ici sous Authentification non en clair . De cette manière, vos informations d'identification pourraient être en sécurité sur le fil même si le courrier réel ne l'est pas.
Et si j'utilise SSL, toute la conversation est sécurisée, même sur un réseau public. Ai-je ce droit?
Oui. Cependant, comme cela a été souligné dans le fil que vous avez cité, le courrier implique de nombreux sauts. Vous pouvez sécuriser le client sur le serveur du magasin de messagerie, mais le chemin emprunté par le courrier du client de l'expéditeur vers votre magasin de messagerie n'est pas prouvé de manière sûre, sauf si vous utilisez un mécanisme de chiffrement de bout en bout.
Fondamentalement, j'essaie de comprendre pourquoi un fournisseur de messagerie refuserait d'offrir SSL/TLS pour les connexions POP/IMAP/SMTP
Parce qu'ils sont bon marché, paresseux et que personne ne devait porter de casque sur les vélos quand ils étaient enfants.
Je voudrais faire valoir que, bien que SSL ne soit pas une protection de bout en bout des messages, il protégerait au moins mes informations d'identification et protégerait mon message pendant une partie importante de son parcours (moi vers le serveur SMTP et le serveur POP vers le destinataire en supposant ils se connectent avec SSL).
Oui, en particulier lorsque ces informations d'identification sont probablement bonnes pour autre chose, comme la gestion de votre compte avec ce fournisseur.
Dois-je tout droit avec ça?
Essentiellement, oui.
Je dirais, cependant, que vous perdez votre temps à discuter avec votre fournisseur à ce sujet. S'ils ne veulent pas fournir SSL, alors trouvez un autre fournisseur. C'est probablement le seul vote que vous pourriez voter qu'ils écouteraient réellement.
Cette question a été assez bien répondu. Mais, il vaut la peine de jeter un œil à la livraison du serveur SMTP sortant de l'expéditeur au serveur MX entrant du destinataire. Cette livraison est souvent effectuée en utilisant STARTTLS pour crypter la connexion SMTP. Avec STARTTLS, la connexion démarre en texte brut, puis la connexion est mise à niveau vers une connexion SSL/TLS si les deux côtés la prennent en charge. Cependant, il existe des problèmes inhérents à SMTP et à STARTTLS qui permettent à un attaquant actif d'effectuer une attaque MITM. Voir cet article pour plus d'informations.
Comme abordé dans ce fil, SSL sécurise les e-mails que vous avez reçus uniquement en transit entre le serveur pop et votre machine, ainsi que ceux que vous avez envoyés uniquement en transit entre votre machine et le serveur smtp.
comme indiqué par Stryfe, une fois le courriel envoyé arrive sur le serveur SMTP, il n'y a aucune preuve que le reste du transit est sécurisé jusqu'au serveur POP du destinataire. Même chose du côté du destinataire, où le chemin entre votre machine destinataire et le serveur de messagerie n'est pas sécurisé; par exemple. considérons le cas où le serveur pop/imap est interne et qu'une équipe informatique peut y jeter un œil.
comme pour PGP mentionné quelques fois; pour l'avoir essayé, PGP n'est pas du tout facile à configurer en entreprise avec les utilisateurs d'Outlook, Thunderbird, gmail et smartphone. Il existe de solides alternatives comme CryptoMailer ( http://www.thegreenbow.com/cryptomailer ), bien que celle-ci soit extrêmement facile à configurer et à utiliser.