Est-ce que gmail-to-gmail n'est toujours pas sécurisé? Pourquoi?
J'ai toujours entendu dire que le courrier électronique est une méthode de communication non sécurisée; Je suppose que cela a quelque chose à voir avec le protocole de messagerie lui-même.
Mais lors de l'envoi d'un e-mail d'un compte Gmail à un autre, Google a un contrôle total sur la façon dont l'e-mail est transmis, et Google semble décemment préoccupé par la sécurité des informations. Il semble donc qu'ils pourraient, s'ils le voulaient, transformer les messages gmail en gmail en un canal de communication sécurisé, et que cela serait probablement dans leur meilleur intérêt.
Alors, l'ont-ils fait? Sinon, pourquoi pas? La communication gmail-à-gmail est-elle toujours non sécurisée (dans le but, par exemple, d'envoyer une carte de crédit ou un numéro de sécurité sociale à un destinataire de confiance)?
Le courrier électronique est historiquement considéré comme non sécurisé pour deux raisons:
- Le protocole réseau SMTP n'est pas chiffré sauf si STARTTLS est négocié, ce qui est effectivement facultatif
- Les messages électroniques restent non chiffrés sur le disque de la source, de la destination et de tout serveur de messagerie intermédiaire
Les serveurs de messagerie Google parlent tous STARTTLS si possible, donc pour gmail-to-gmail, l'étape de transmission ne devrait pas être un problème. Cependant, le serveur d'envoi stocke une copie non chiffrée de l'e-mail dans votre dossier Envoyé. Le serveur de réception stocke une copie non cryptée dans la boîte de réception du destinataire. Cela les expose à diverses menaces:
- Employés voyous de Google lisant cet e-mail
- Google a choisi de lire cet e-mail malgré ses assurances à l'effet contraire
- Les gouvernements obligent Google à remettre cet e-mail
- Des pirates informatiques s'introduisent dans Google et accèdent à cet e-mail
Si vous pouvez faire confiance à tout pour que ça marche, alors gmail-to-gmail est parfaitement sécurisé. Mais vous ne pouvez pas toujours vous attendre à ce que tout se passe bien.
Pour ces raisons, la communauté de la sécurité et de la confidentialité a depuis longtemps établi que seul le chiffrement des e-mails de bout en bout est sécurisé . Cela signifie que le courrier électronique reste chiffré sur les disques du serveur et est déchiffré lorsque vous le lisez, et jamais stocké déchiffré.
Il y a eu énormément de commentaires, alors permettez-moi de développer/clarifier certaines choses.
Cryptage de bout en bout - dans le contexte du courrier électronique, quand je dis le cryptage de bout en bout, je veux dire quelque chose comme PGP, où le message est chiffré jusqu'à ce qu'il atteigne le client de messagerie du destinataire, et seulement déchiffré pour être lu. Oui, cela signifie qu'il ne peut pas être recherché sur le serveur, et signifie souvent également qu'il ne reste pas "sauvegardé" sur le serveur. Il s'agit d'un cas où la sécurité et la fonctionnalité sont en contradiction; choisissez-en un.
Communauté de la sécurité et de la confidentialité - contrairement à de nombreux sujets sur la sécurité de l'information, la sécurité des e-mails s'étend à d'autres communautés. La question de savoir ce que signifie une inspection avec état dans un pare-feu n'est pas quelque chose qui s'étend souvent à l'intérêt des autres, par exemple. Mais la sécurité des e-mails présente un intérêt direct et
Oubliez les données de carte de crédit, il y a des gens qui essaient de communiquer avec le courrier électronique dont la vie et la vie de leur famille dépendent de la sécurité du courrier électronique. Donc, comme il y a des phrases dans les commentaires ci-dessous comme "dépend de ce que sont vos normes pour" sécurisé "", "adversaire suffisamment motivé", "il y a une illusion de sécurité au niveau du courrier électronique" - suis-je trop fort pour dire le serveur ne peut pas faire confiance? Pas pour les personnes dont la vie est en jeu. C'est pourquoi l'expression "le courrier électronique n'est pas sûr" est le mantra du mouvement pour la protection de la vie privée depuis 20 ans.
Faire confiance au serveur - Aux États-Unis, " votre plafond de responsabilité pour les frais non autorisés sur une carte de crédit est de 50 $ " donc vous peut être heureux de faire confiance au serveur avec votre carte de crédit. Si vous trichez, en revanche, vous risquez de perdre beaucoup plus à la suite de en laissant des e-mails non cryptés sur le serveur . Et votre fournisseur de services fermera-t-il ses portes pour protéger votre vie privée ? Probablement pas.
[~ # ~] starttls [~ # ~] - STARTTLS est SSL pour le courrier électronique; il utilise le même protocole cryptographique SSL/TLS pour crypter les e-mails en transit. Cependant, il est décidément moins sûr que HTTPS pour plusieurs raisons:
- STARTTLS est presque toujours "opportuniste", ce qui signifie que si le client le demande et que le serveur le prend en charge, il cryptera; si l'une de ces choses n'est pas vraie, l'e-mail passera discrètement par non crypté.
- Les certificats auto-signés, expirés et autrement faux sont généralement acceptés par les expéditeurs d'e-mails, donc STARTTLS assure la confidentialité mais presque aucune de l'authentification. C'est relativement banal pour les e-mails Man-In-The-Middle si vous pouvez entrer entre les serveurs du réseau.
Cela dépend en grande partie de ce que vous entendez par "non sécurisé".
Traditionnellement, le courrier électronique était considéré comme un transport non sécurisé car il était transféré via un protocole non chiffré (SMTP) et, en règle générale, vous disposiez d'un contrôle limité sur la façon dont le courrier électronique avait atteint sa destination, de sorte que vous ne connaissiez pas nécessairement la sécurité des systèmes. qu'il a traversé.
De nos jours, la plupart des grands fournisseurs de messagerie modernes utilisent des protocoles de transfert cryptés (généralement SMTP + SSL), ce qui supprime clairement le problème de l'envoi du courrier électronique sur Internet, mais pour le courrier électronique généralement Internet, le souci de ne pas savoir quoi les systèmes traiteront le courrier sur le chemin de sa destination.
Dans votre cas, vous semblez savoir que ce sera l'envoi et la réception de Google, il est donc peu probable qu'ils laissent leur contrôle.
Quelques préoccupations potentielles demeurent.
- faites-vous confiance à Google? Vraisemblablement, vous faites comme vous utilisez leur service de messagerie, mais il va sans dire qu'ils pourraient théoriquement avoir accès à votre courrier.
- Sécurité du courrier une fois qu'il a atteint sa destination. Vous ne pouvez pas avoir de contrôle sur la façon dont le destinataire stocke/traite le courrier et cela pourrait entraîner sa mauvaise conservation (par exemple, être téléchargé sur un client mobile non crypté, stocké sur un PC non crypté, etc.). Les e-mails ont également tendance à être transmis, il y a donc toujours le risque que quelqu'un les envoie à une autre partie qui n'est pas hébergée sur Google.
Si vous êtes satisfait à ces deux égards, alors généralement je dirais qu'il n'y a rien de mal à utiliser le courrier électronique pour le transfert général de données. Un autre point que je mentionnerais est que, spécifiquement pour des choses comme les données de carte de crédit, si vous êtes une entreprise, vous aurez des problèmes de conformité (par exemple PCI) et ils pourraient bien empêcher l'utilisation du courrier électronique.
Dans les révélations de Snowden , il a montré que le NSA s'était connecté aux câbles à fibres optiques reliant les centres de données de Google. Vous pouvez vous référer à l'image ci-dessous et faire vos propres déductions pour savoir si tout ce qui se trouve sur le réseau de Google est réellement sécurisé.
Ils ont peut-être amélioré la situation depuis lors, mais il serait difficile de prouver aux clients exactement ce qu'ils ont fait pour améliorer la sécurité de leur réseau et que le gouvernement n'a plus un accès complet. Vous devrez prendre leur parole pour cela. Si vous voulez une sécurité réelle , vous devez utiliser le cryptage open source de bout en bout où seul l'expéditeur et le destinataire ont les clés privées et tout le cryptage/décryptage est côté client fait. Il existe un certain nombre de nouveaux services de messagerie Web pour cela ou vous pouvez toujours utiliser le GnuPG classique.
En plus des autres excellentes réponses, il y a une autre préoccupation: le fait que l'expéditeur et la destination finale soient tous deux sur gmail ne signifie pas que l'e-mail reste dans Google.
Si le destinataire utilise son propre nom de domaine, il est tout à fait possible qu'il achemine ses e-mails via un serveur externe avant de le réinjecter dans Google. Gmail peut détecter cela et livrer directement l'e-mail, ou il peut suivre l'enregistrement MX vers le serveur externe avant de renvoyer l'e-mail à Google.
Toutes les autres réponses concernent une personne lisant votre e-mail. Cependant, ce n'est pas la seule préoccupation - vous vous souciez également de identité de l'expéditeur. Et c'est une autre grande faiblesse du courrier électronique - par défaut, il n'y a aucun moyen de vérifier l'identité. L'expéditeur est celui qui fournit l'adresse "De", et je peux facilement envoyer des e-mails "à partir de" [email protected]. Vous n'avez aucun moyen de savoir si je suis vraiment Bill Gates.
Heureusement, de nombreux fournisseurs de messagerie ont déjà mis en place des mesures pour y remédier. Par exemple, beaucoup marqueront l'e-mail comme spam si le domaine concerné n'a pas le serveur SMTP que vous avez utilisé pour envoyer l'e-mail dans ses enregistrements MX. La simulation d'une adresse IP Internet est beaucoup plus difficile que la simulation de l'en-tête From, et il en va de même pour la simulation des enregistrements DNS. Certains ne vous autoriseront pas à envoyer un e-mail avec From étant une adresse qui ne vous appartient pas (généralement, c'est soit carrément interdit, soit vous avez besoin d'une sorte de confirmation sur l'adresse e-mail) - cela inclut GMail, donc les e-mails GMail <-> GMail garantissent la bonne identité. Bien sûr, vous devez faire attention - par exemple, je pourrais toujours utiliser Bill Gates comme "From" nom, tout en conservant l'adresse [email protected], ou je pourrais essayer d'obtenir un domaine qui ne semble pas trop suspect à première vue (par exemple, [email protected]). Les noms de domaine Unicode vont probablement être très amusants à cet égard :)
De nombreux clients de messagerie vous permettront également de signer et crypter l'e-mail, ce qui garantit à la fois l'identité et la sécurité du contenu. Bien sûr, vous devez savoir à l'avance que vous pouvez faire confiance à ce certificat donné, et vous avez besoin de la clé appropriée pour déchiffrer l'e-mail. Il est particulièrement utile par exemple pour les entreprises, qui peuvent avoir des certificats racine approuvés, de sorte que tous les certificats enfants sont également implicitement approuvés. Cependant, même si vous n'avez que l'e-mail pour continuer, il est assez facile d'assurer l'échange de clés en toute sécurité - cela ne nécessite que quelques e-mails d'avant en arrière (bien qu'il existe encore des moyens de rompre cela avec MITM).