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

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

SSLStrip poker

Avatar de l'auteur
Guénaël Pépin

Publié dans

Internet

16/11/2015 3 minutes
19

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

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.

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

De nouveaux défis pour les services d'emails

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

Commentaires (19)




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” <img data-src=" />


Attention à bien distinguer

-&nbsp;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.&nbsp;


20% dans certain pays. pas au niveau mondial








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”.



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


Le ratio 80 - 20 , c’est la loi de Pareto. Logique <img data-src=" />








Aznox a écrit :



Attention à bien distinguer

-&nbsp;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.&nbsp;





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









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 ?



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é.


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.








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 <img data-src=" />

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 <img data-src=" /> (si si <img data-src=" />)









CryoGen a écrit :



Il n’y a rien de condamnable… enfin théoriquement la société te met au courant <img data-src=" />

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 <img data-src=" /> (si si <img data-src=" />)







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 <img data-src=" />



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.









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%.&nbsp;





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&nbsp;

  • 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.









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.&nbsp;





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









d9pouces a écrit :



Personnellement, je n’ai toujours connu que ça <img data-src=" /> 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.

&nbsp;

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&nbsp;é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…



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


Toutes mes excuses à laposte.net :)



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



&nbsp;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 <img data-src=" />



&nbsp;


Objet: SPAM code nucléaire



Bonjour M. le président,



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



Cordialement,


Très bon résumé