La messagerie électronique est historiquement considérée comme non sécurisée pour deux raisons:

• Le protocole réseau SMTP n'est pas chiffré à moins que STARTTLS ne soit négocié, ce qui est effectivement facultatif
• Les messages électroniques sont non chiffrés sur le disque de la source, de la destination et de tout serveur de messagerie intermédiaire

Les serveurs de messagerie de 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 chiffrée dans la boîte de réception du destinataire. Cela les expose à diverses menaces:

• Les employés malhonnêtes de Google lisant cet e-mail
• Google choisit de lire cet e-mail malgré leurs assurances du contraire
• Les gouvernements forcent Google à transmettre cet e-mail
• Des pirates informatiques pénètrent dans Google et accèdent à cet e-mail

Si vous pouvez faire confiance à tout pour que tout se passe bien, 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 adopté la position selon laquelle seul le chiffrement des e-mails de bout en bout est sécurisé . Cela signifie que l'e-mail reste chiffré sur les disques du serveur et est déchiffré lorsque vous le lisez, et jamais stocké déchiffré.

Il y a eu un nombre énorme de commentaires, alors laissez-moi développer / clarifier un peu de choses.

Chiffrement de bout en bout - dans le contexte du courrier électronique, quand je dis chiffrement 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 uniquement décrypté pour être lu. Oui, cela signifie qu'il ne peut pas être recherché sur le serveur, et souvent aussi qu'il ne reste pas "sauvegardé" sur le serveur non plus. C'est un cas où la sécurité et la fonctionnalité sont en désaccord; choisissez-en un.

Communauté de sécurité et de confidentialité - contrairement à de nombreux sujets relatifs à la sécurité de l'information, la sécurité des e-mails en est une qui s'étend à d'autres communautés. La question de savoir ce que signifie l'inspection avec état dans un pare-feu n'est pas quelque chose qui intéresse souvent les autres, par exemple. Mais la sécurité des e-mails présente un intérêt direct et important pour

• les défenseurs des droits de l'homme
• les lanceurs d'alerte
• Insurgés

Oubliez les données de carte de crédit, il y a des gens qui essaient de communiquer par e-mail dont la vie et la vie de leur famille dépendent de la sécurité des le courriel. Donc, comme il y a des phrases dans les commentaires ci-dessous comme "dépend de ce que vos standards sont pour" sécurisé "", "adversaire suffisamment motivé", "il y a une illusion de sécurité au niveau des e-mails" - suis-je trop fort pour le dire on ne peut pas faire confiance au serveur? Pas pour les personnes dont la vie est en jeu. C'est pourquoi l'expression "e-mail n'est pas sécurisée" est le mantra du mouvement pour la protection de la vie privée depuis 20 ans.

Faire confiance au serveur - Aux États-Unis, " votre limite pour la responsabilité pour les frais non autorisés sur une carte de crédit est de 50 $ ". Vous pourriez donc être heureux de faire confiance au serveur avec votre carte de crédit. Si vous trichez, en revanche, vous risquez de perdre beaucoup plus si vous laissez des e-mails non chiffré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 les e-mails; il utilise le même protocole cryptographique SSL / TLS pour crypter les e-mails en transit. Cependant, il est décidément moins sécurisé que HTTPS pour plusieurs raisons:

1. STARTTLS est presque toujours "opportuniste", ce qui signifie que si le client le demande et que le serveur le prend en charge, ils chiffreront; si l'une ou l'autre de ces choses n'est pas vraie, l'e-mail passera discrètement en clair.
2. Les certificats auto-signés, expirés ou faux sont généralement acceptés par les expéditeurs d'e-mails, donc STARTTLS assure la confidentialité, mais presque aucune authentification. C'est relativement simple pour les e-mails Man-In-The-Middle si vous pouvez vous connecter entre les serveurs du réseau.

Cela dépend en grande partie de ce que vous entendez par "non sécurisé".

Traditionnellement, l'e-mail était considéré comme un transport non sécurisé car il était transféré via un protocole non chiffré (SMTP) et généralement vous n'aviez qu'un contrôle limité sur la manière dont l'e-mail atteignait réellement sa destination, donc vous ne seriez pas nécessairement connaître la sécurité des systèmes qu'il traversait.

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 les inquiétudes concernant l'envoi des e-mails via le Internet en clair, mais pour les e-mails en général sur Internet, le souci de ne pas savoir quels systèmes traiteront le courrier sur le chemin de sa destination demeure.

Dans votre cas, vous semblez savoir que tel est le cas. Ce sera l'envoi et la réception de Google, donc il est peu probable que cela leur laisse le contrôle.

Quelques problèmes potentiels subsistent.

1. faites-vous confiance à Google? Vous faites probablement comme vous utilisez leur service de messagerie, mais il va sans dire qu'ils pourraient théoriquement accéder à votre courrier.
2. Sécurité du courrier une fois qu'il atteint sa destination. Il se peut que vous n'ayez pas le contrôle sur la façon dont le destinataire stocke / traite le courrier et cela pourrait entraîner sa conservation de manière non sécurisée (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 transférés, 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, en général oui, je dirais qu'il n'y a rien de mal à utiliser l'e-mail pour le transfert de données générales. L'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 peuvent très bien empêcher l'utilisation du courrier électronique.

Dans les révélations Snowden, il a montré que la NSA avait puisé dans les câbles à fibre optique reliant les centres de données de Google entre eux. Vous pouvez vous référer à l'image ci-dessous et faire vos propres déductions pour savoir si quelque chose sur le réseau de Google est réellement sécurisé.

Ils peuvent s'être améliorés 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. Il faudrait leur croire sur parole. Si vous voulez une sécurité réelle , vous devez utiliser un cryptage open source de bout en bout où seuls l'expéditeur et le destinataire ont les clés privées et tout le cryptage / décryptage est effectué côté client. 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: ce n'est pas parce que l'expéditeur et la destination finale sont tous les deux sur gmail 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 les renvoyer dans Google. Gmail peut le détecter et envoyer directement l'e-mail, ou suivre l'enregistrement MX sur 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 l ' identité de l'expéditeur. Et c'est une autre grande faiblesse de l'e-mail - 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 "depuis" bill.gates@microsoft.com . Vous n’avez aucun moyen de savoir si je suis vraiment Bill Gates.

Heureusement, de nombreux fournisseurs de messagerie ont déjà implémenté des mesures pour remédier à cela. Par exemple, beaucoup marqueront l'e-mail comme spam si le domaine concerné ne dispose pas du serveur SMTP que vous avez utilisé pour envoyer l'e-mail dans ses enregistrements MX. Truquer une adresse IP Internet est beaucoup plus difficile que simuler l'en-tête From, et il en va de même pour truquer les enregistrements DNS. Certains ne vous permettront pas d'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, ainsi 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 "nom" de l'expéditeur, tout en conservant l'adresse malwarehacker@gmail.com , ou Je pourrais essayer d'obtenir un domaine qui ne semble pas trop suspect à première vue (par exemple bill.gates@micorsoft.com ). Les noms de domaine Unicode seront probablement très amusants à cet égard :)

De nombreux clients de messagerie vous permettront également de signer et chiffrer l'e-mail, ce qui garantit à la fois l'identité et la sécurité du contenu. Bien sûr, vous devez savoir que vous pouvez faire confiance au certificat donné à l'avance, et vous avez besoin de la clé appropriée pour déchiffrer l'e-mail. C'est particulièrement utile pour par exemple entreprises, qui peuvent avoir des certificats racine approuvés, de sorte que tous les certificats enfants sont également approuvés implicitement. Cependant, même si vous n'avez que l'e-mail pour continuer, il est assez facile d'assurer l'échange sécurisé des clés - cela ne nécessite que quelques e-mails dans les deux sens (bien qu'il y ait encore des moyens de briser cela avec MITM). / p>

Le PO demande:

"Donc, il semble qu'ils (Google) pourraient, s'ils le voulaient, transformer les messages de gmail à gmail en un canal de communication sécurisé, et que ce serait probablement dans leur meilleur intérêt. "

Il ne fait aucun doute que Google" pourrait "transformer Gmail en l'un des services de messagerie les plus sécurisés du marché. Ils ont clairement les ressources. Mais pour répondre à la question du PO - Non, ce ne serait PAS dans leur meilleur intérêt !!!!! N'oubliez pas que leur modèle commercial consiste à fournir gratuitement toutes sortes de services Internet à l'utilisateur final. Ils gagnent leur argent en collectant les données de l'utilisateur final (contenu de l'e-mail, localisation GPS, requêtes de recherche, etc.) pour développer un profil qu'ils peuvent vendre aux annonceurs. Cela signifie que votre entreprise est littéralement celle de Google. Google examinera TOUJOURS vos données, les stockera toujours et les remettra toujours à des tiers. Ils doivent. C'est comme ça qu'ils paient les factures. De plus, étant donné que Google conserve la clé de toute information cryptée, il peut et la restituera en cas d'assignation du gouvernement ou même de parties privées. Ce n'est pas le cas pour les services qui «jettent» la clé de chiffrement. Si vous avez besoin de sécurité, recherchez des entreprises qui ne tirent pas profit de vos informations personnelles.

Si vous ressentez le besoin de diffuser vos informations financières par voie électronique, pourquoi ne pas utiliser des services conçus pour la sécurité (par exemple, le courrier proton) Wickr, ou même iMessage (ils jettent la clé de cryptage). De plus, divisez les nombres en messages séparés afin qu'un lecteur non intentionnel ne puisse pas facilement reconnaître qu'il s'agit d'un numéro CC.

Si vous avez un intérêt particulier pour les cartes de crédit, vous noterez cet article mettant en évidence la longue histoire de Google distribuant au moins par inadvertance des numéros de carte de crédit: http://www.toptal.com/web/with-a-filter-bypass-credit-card-numbers-are-still-still-google-able