Gmail : bientôt des alertes pour les messages reçus via une connexion sans chiffrement

SSLStrip poker

Le 16 novembre 2015 à 16h00

3 min

Internet

Google publie une étude effectuée en collaboration avec deux universités américaines. Le résultat : une partie du Net « empêche activement » l'usage du chiffrement pour les emails. Pour protéger ses utilisateurs, le groupe compte bientôt avertir les utilisateurs de Gmail quand un message a transité par une zone non-protégée.

Le chiffrement est l'un des chevaux de bataille de Google, qu'on se le dise. Jeudi, le groupe a publié les résultats d'une étude pluriannuelle sur la sécurité des emails, menée avec les universités du Michigan et de l'Illinois. Cette étude a observé l'évolution de la sécurité des échanges entre les services de messagerie, depuis 2013. Le résultat : une forte augmentation de la sécurité des emails pendant leur livraison, même si tout n'est pas rose.

« Pourtant, la majorité de cette progression peut être attribuée à une poignée de grands fournisseurs, quand beaucoup de plus petites organisations trainent à la fois sur le déploiement et sur la configuration » de ces technologies, explique l'étude dans sa conclusion. Aussi, elle note que, comme le protocole n'a pas été initialement développé pour la sécurité, les serveurs privilégieront l'arrivée d'un message à son destinataire au chiffrement de son transport.

De nouveaux défis pour les services d'emails

Surtout, l'étude identifie plusieurs défis pour les services de courriels, qui n'étonneront qu'à moitié. « Nous avons trouvé des régions d'Internet qui empêchent activement le chiffrement des messages, en interférant avec les requêtes qui initient les connexions SSL » explique Google. Le groupe travaille avec l'association M3AAWG, qui comprend entre autres des fournisseurs de services (dont les GAFA) et des opérateurs (AT&T ou Orange), pour activer le chiffrement dans plus de cas (via le chiffrement opportuniste).

Gmail Google sécurité emails — Crédits : Google

Une autre menace identifiée est l'existence de serveurs DNS menteurs, qui redirigent les emails destinés à Gmail vers un autre site, qui peut le renvoyer vers Gmail après l'avoir consulté. « Même si ce type d'attaque est rare, il est inquiétant qu'elles puissent permettre à des attaquants de censurer ou altérer des messages avant qu'ils ne soient relayés au destinataire » affirme le groupe. Selon l'étude, jusqu'à 20 % des messages reçus par Gmail dans certains pays sont concernés par du man-in-the-middle, c'est-à-dire leur interception et déchiffrement en chemin.

Dans les prochains mois, des alertes en cas de déchiffrement

Pour aider les utilisateurs à se protéger de ces attaques, Google développe en ce moment des alertes qui préviendront l'utilisateur quand un message est reçu par une connexion non-chiffrée. Cette fonction devrait arriver dans les prochains mois, selon le groupe.

Cette mesure viendra s'ajouter à toute une série d'autres prises ces dernières années. Parmi elles, on peut noter l'extension End-to-End pour Chrome, qui permet d'utiliser OpenPGP directement depuis le navigateur, même si elle ne change pas grand-chose à la situation. De son côté, Gmail alerte depuis juin 2012 s'il détecte une attaque potentiellement « soutenue par un État » sur le compte ou le PC de l'utilisateur. Enfin, le groupe propose des données sur la sécurité des emails échangés avec Gmail, dans le cadre de son Transparency Report.

Commentaires (19)

Picos

Le 16/11/2015 à 17h07

Certes mais ça fait peut être sonner l’alarme de Google tout de même.

Même si tu ne lis pas le contenu, c’est possible et donc ça rentre quand même dans ce cas pour ma part.

C’est tout de même limite comme solution car de mémoire, déchiffrer une communication chiffrée avec une banque est condamnable.

J’ai jamais aimé ce principe. Réécrire mon certificat me donne envie de brûler l’admin sys.

CryoGen

Le 16/11/2015 à 17h13

Picos a écrit :

Certes mais ça fait peut être sonner l’alarme de Google tout de même.

Même si tu ne lis pas le contenu, c’est possible et donc ça rentre quand même dans ce cas pour ma part.

C’est tout de même limite comme solution car de mémoire, déchiffrer une communication chiffrée avec une banque est condamnable.

J’ai jamais aimé ce principe. Réécrire mon certificat me donne envie de brûler l’admin sys.

Il n’y a rien de condamnable… enfin théoriquement la société te met au courant " />

Et puis bon, on parle de protection d’entreprise, il y a toujours des concessions à faire pour protéger un réseau. Rapellons que tous les utilisateurs ne sont pas des utilisateurs avertis " /> (si si " />)

Picos

Le 16/11/2015 à 17h26

CryoGen a écrit :

Il n’y a rien de condamnable… enfin théoriquement la société te met au courant " />

Et puis bon, on parle de protection d’entreprise, il y a toujours des concessions à faire pour protéger un réseau. Rapellons que tous les utilisateurs ne sont pas des utilisateurs avertis " /> (si si " />)

Dans la réalité, aucune société ne le fait, encore moins avec les prestaires. Je pense sincèrement que toute les société que j’ai connu peuvent être poursuivi en justice sans problème. (dont celle d’où j’écris ces lignes).

Et j’ai du grand groupe, des instances publiques de l’état et des petits groupes.

Pour les concessions, je sais pas. On est dans le BYOD de plus en plus (encore plus avec les prestas …) et ton réseau est totalement vulnérable à une attaque interne malgré ton proxy.

Bien sur il existe d’autres outils de protections pour l’interne …

Du coup, je trouve que c’est une grosse concession pour un avantage que je ne vois pas. Rien n’empêchera le mec qui veut se mater du pron au boulot de le faire sur son mobile (payer par la boite).

On parle quand même d’intrusion dans un échange sécurisé au profit de patron (et d’admin sys) que je ne connais pas. On râle sur les boites noires, c’est pareil en mon sens.

Il est évident que je n’ai rien contre toi personnellement CryoGen " />

C’est juste pour répondre au 20% qui, pour moi, n’est pas beaucoup finalement au vue de ce que je rencontre, ici, en France.

Aznox

Le 16/11/2015 à 18h04

seerom a écrit :

Les clients email mal configurés (outlook, thunderbird,…) qui se connectent sans couche SSL font de n°3 une norme pas respectée à 100%. 

Avec la configuration automatique (on entre le login/password et le client de messagerie va demander les paramètres au serveur) c’est de moins en moins le cas, seuls les gens qui utilisent laposte.net/wanadoo.fr ou une messagerie d’entreprise mal configurée/dépassée ont encore besoin de taper manuellement l’adresse du serveur SMTP/IMAP (et donc de se tromper dans l’activation des protocoles de sécurité).

Picos a écrit :

Est-ce que ces 20% ne prennent pas en compte également les superbes boîtiers que bon nombre d’entreprises aime s’ajouter jouer l’intermédiaire entre toi et le boîtier et le boîtier et le service en ligne.

Genre les boitiers BlueCoat qui donne un accès HTTPS vers le boitier sur un certificat interne et qui fait lui la transision avec le service externe avec le bon certificat.

Ce qui fait que pour discuter avec ta banque, tu discutes avec le boitier en HTTPS mais avec un certif interne jusqu’au boitier puis le boitier avec la banque avec le certif de la banque.

T’as bien un Man-in-the-middle dans ce cas là et beaucoup de boite française l’utilise. Du coup, ca pourrait rentrer dans les 20%, non ?

C’est pas vraiment du man-in-the-middle, dans le sens ou si tu utilises un machine de l’entreprise, alors tu fais entièrement confiance à l’entreprise à ce sujet. Point.

Si tu te connectes avec une machine perso sur un réseau d’entreprise qui utilise une passerelle d’inspection du https, alors tu aura un bel avertissement de certificat te prévenant du Man-in-the-middle car le certificat SSL du boitier de terminaison-rechiffrement ne sera pas installé sur dans ta “liste de confiance” comme c’est le cas du pc d’entreprise.

Pour les 20% évoqués par google, je pense que ça fait plutôt référence à des fournisseurs de mail gratuits et un peu dépassés (genre laposte.net ou ce genre de truc) dont les serveurs de relais SMTP ne gèrent pas le TLS :

Mme Michu écrit un mail de [email protected] à [email protected]

le serveur smtp3.laposte.net contacte smtp17.gmail.com 

le serveur de google demande à celui de laposte s’il est prêt pour le chiffrement (négociation TLS)

le serveur de laposte répond que non, désolé, je sais pas faire

le serveur de google répond que tant pis, balances tout en clair

n’importe quel FAI/Etat peut lire/enregistrer le message pendant son transport

(j’ai pris laposte.net comme exemple, mes excuses à leur postmaster s’ils ont récemment modernisé leur infra)

Je pense que d’ici quelques mois/années, Google et cie vont menacer ce genre de fournisseurs à la ramasse de refuser les emails si leurs serveurs ne gèrent pas le TLS pour le transport.

d9pouces

Le 16/11/2015 à 18h42

Picos a écrit :

Dans la réalité, aucune société ne le fait, encore moins avec les prestaires. Je pense sincèrement que toute les société que j’ai connu peuvent être poursuivi en justice sans problème. (dont celle d’où j’écris ces lignes).

Et j’ai du grand groupe, des instances publiques de l’état et des petits groupes. 

Personnellement, je n’ai toujours connu que ça " /> Et ça ne me choque pas plus que ça, la sécurité est parfois censée primer.

Bejarid

Le 16/11/2015 à 19h24

d9pouces a écrit :

Personnellement, je n’ai toujours connu que ça " /> Et ça ne me choque pas plus que ça, la sécurité est parfois censée primer.

Pareil, ça me gène pas de manière général, mais dans certains cas c’est fait de façon aberrante.

 

Par exemple dans une certaine entreprise de matos militaire française (et pas une PME…), tout le trafic était logué. En clair. Sur un serveur pas spécialement protégé, dans leur infra toute sauf sûre (un audit de la DGA en a prit le contrôle de 36h, et c’est là que ça s’est sût et qu’ils ont du arrêter, non sans perdre quelques têtes au passage).

Bon après le SI y était bien con (au point qu’on évitait de se servir des PCs qu’ils contrôlaient au maximum) donc je doute qu’ils soient nombreux à faire des conneries de cette envergure, mais bon…

Optix

Le 16/11/2015 à 22h00

Tu m’as mis le doute…  Received: from smtp.laposte.net (smtpoutz11.laposte.net [194.117.213.174]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (²⁵⁶⁄₂₅₆ bits)) (No client certificate requested) by mail.newsoo.eu (Postfix) with ESMTPS id A9D9641A47 for <[email protected]>; Mon,  9 Nov 2015 15:41:22 +0100 (CET) LaPoste communique bien en chiffré. Dommage que leur SMTP ne communique pas en v6 :(

Aznox

Le 17/11/2015 à 00h35

Toutes mes excuses à laposte.net :)

J’ai essayé d’en trouver un autre pour l’exemple, et j’ai fait bingo assez vite :

 Si tu envois un mail à [email protected], le serveur SMTP (MX) qui répond sera berlioz.elysee.fr

https://mxtoolbox.com/SuperTool.aspx?action=mx%3aelysee.fr&run=toolpage#

Or celui-ci ne semble pas supporter TLS :

https://mxtoolbox.com/SuperTool.aspx?action=smtp%3aberlioz.elysee.fr&run…

Donc tous les mails non chiffrés à destination de ce domaine peuvent être considérés comme des cartes postales " />

 

CryoGen

Le 17/11/2015 à 08h25

Objet: SPAM code nucléaire

Bonjour M. le président,

Voici les codes nucléaires pour la semaine du 12.

Cordialement,

Soriatane Abonné

Le 17/11/2015 à 08h34

Très bon résumé

CryoGen

Le 16/11/2015 à 16h13

Une autre menace identifiée est l’existence de serveurs DNS menteurs, qui redirigent les emails destinés à Gmail vers un autre site, qui peut le renvoyer vers Gmail après l’avoir consulté. « Même si ce type d’attaque est rare, il est inquiétant qu’elles puissent permettre à des attaquants de censurer ou altérer des messages avant qu’ils ne soient relayés au destinataire » affirme le groupe. Selon l’étude, jusqu’à 20 % des messages reçus par Gmail dans certains pays sont concernés par du man-in-the-middle, c’est-à-dire leur interception et déchiffrement en chemin.

Rare = 20%

On n’a pas la même définition de “rare” " />

Aznox

Le 16/11/2015 à 16h17

Attention à bien distinguer

- chiffrement des emails pendant leur transit (les différents relais SMTP communiquent en TLS pour éviter que quelqu’un ayant accès aux tuyaux puisse lire les mails qui vont de gmail à hotmail par exemple)

chiffrement du contenus des emails (pour que quelqu’un qui arrive à se connecter à votre compte ou même le fournisseur Microsoft/Google ne puisse pas les lire sans votre clef privée)

chiffrement de la connexion au service en ligne (accès au webmail en https) là encore pour éviter l’écoute pendant le trajet Cloud/Maison.

n°3 est la norme depuis longtemps, n°1 aussi même si Google va gronder les retardataires (objet de l’article je crois) et n°2 a encore beaucoup de chemin à parcourir avant démocratisation.

Minikea

Le 16/11/2015 à 16h18

20% dans certain pays. pas au niveau mondial

CryoGen

Le 16/11/2015 à 16h19

geekounet85 a écrit :

20% dans certain pays. pas au niveau mondial

Ca ne change rien ^^

Rare c’est de temps en temps. Pour arriver à du 20% c’est que c’est relativement courant déjà, ce n’est plus “rare”.

Gab&

Le 16/11/2015 à 16h30

Faudrait faire un sondage pour définir quel est le pourcentage correspondant à rare. Pour moi c’est moins de 1%

Z-os Abonné

Le 16/11/2015 à 16h41

Le ratio 80 - 20 , c’est la loi de Pareto. Logique " />

seerom

Le 16/11/2015 à 16h47

Aznox a écrit :

Attention à bien distinguer

- chiffrement des emails pendant leur transit (les différents relais SMTP communiquent en TLS pour éviter que quelqu’un ayant accès aux tuyaux puisse lire les mails qui vont de gmail à hotmail par exemple)

chiffrement du contenus des emails (pour que quelqu’un qui arrive à se connecter à votre compte ou même le fournisseur Microsoft/Google ne puisse pas les lire sans votre clef privée)

chiffrement de la connexion au service en ligne (accès au webmail en https) là encore pour éviter l’écoute pendant le trajet Cloud/Maison.

n°3 est la norme depuis longtemps, n°1 aussi même si Google va gronder les retardataires (objet de l’article je crois) et n°2 a encore beaucoup de chemin à parcourir avant démocratisation. 

Les clients email mal configurés (outlook, thunderbird,…) qui se connectent sans couche SSL font de n°3 une norme pas respectée à 100%.

Picos

Le 16/11/2015 à 16h49

Aznox a écrit :

Attention à bien distinguer

- chiffrement des emails pendant leur transit (les différents relais SMTP communiquent en TLS pour éviter que quelqu’un ayant accès aux tuyaux puisse lire les mails qui vont de gmail à hotmail par exemple)

chiffrement du contenus des emails (pour que quelqu’un qui arrive à se connecter à votre compte ou même le fournisseur Microsoft/Google ne puisse pas les lire sans votre clef privée)

chiffrement de la connexion au service en ligne (accès au webmail en https) là encore pour éviter l’écoute pendant le trajet Cloud/Maison.

n°3 est la norme depuis longtemps, n°1 aussi même si Google va gronder les retardataires (objet de l’article je crois) et n°2 a encore beaucoup de chemin à parcourir avant démocratisation.

Est-ce que ces 20% ne prennent pas en compte également les superbes boîtiers que bon nombre d’entreprises aime s’ajouter jouer l’intermédiaire entre toi et le boîtier et le boîtier et le service en ligne.

Genre les boitiers BlueCoat qui donne un accès HTTPS vers le boitier sur un certificat interne et qui fait lui la transision avec le service externe avec le bon certificat.

Ce qui fait que pour discuter avec ta banque, tu discutes avec le boitier en HTTPS mais avec un certif interne jusqu’au boitier puis le boitier avec la banque avec le certif de la banque.

T’as bien un Man-in-the-middle dans ce cas là et beaucoup de boite française l’utilise. Du coup, ca pourrait rentrer dans les 20%, non ?

CryoGen

Le 16/11/2015 à 17h01

Dans les 20% je pense que c’est plutôt à des fins de surveillance, censure et altération.

Le cas des pare-feu / proxy à déchiffrement “interne” c’est pour de l’analyse antivirus, filtrage de contenu (accès à des sites de cannailliou), détection de documents privés, mais franchement rarement pour “lire” humainement ce qui passe dedans.

D’ailleurs, je vends une solution de ce type et il n’y a pas d’accès “utilisateur” au contenu déchiffré puis chiffré.