Connexion
Abonnez-vous

Gmail autorise le chiffrement de bout en bout pour certains de ses clients

Gmail autorise le chiffrement de bout en bout pour certains de ses clients

Le 21 décembre 2022 à 07h12

Google a annoncé qu'il ajoutait le chiffrement de bout en bout (E2EE) côté client à Gmail sur le Web, relève BleepingComputer : 

« Une fois activé, le chiffrement côté client de Gmail garantit que toutes les données sensibles fournies dans le cadre du corps de l'e-mail et des pièces jointes (y compris les images intégrées) ne peuvent pas être déchiffrées par les serveurs Google. L'en-tête de l'e-mail (y compris l'objet, les horodatages et les listes de destinataires) ne sera pas chiffré. »

Ce chiffrement côté client (Client-side encryption, ou CSE) de Google Workspace était déjà disponible pour les utilisateurs de Google Drive, Google Docs, Sheets, Slides, Google Meet et Google Calendar (bêta) : 

« De cette façon, les serveurs Google ne peuvent pas accéder à vos clés et déchiffrer vos données. Après avoir configuré CSE, vous pouvez choisir quels utilisateurs peuvent créer du contenu chiffré côté client et le partager en interne ou en externe. »

La version bêta de Gmail E2EE n'est actuellement disponible que pour les clients Google Workspace Enterprise Plus, Education Plus et Education Standard, mais « n'est pas encore disponible pour les utilisateurs disposant de comptes Google personnels ou de Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Education Fundamentals, Frontline et Nonprofits, ainsi que pour les anciens clients G Suite Basic et Business ».

Le 21 décembre 2022 à 07h12

Commentaires (34)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

C’est moi qui suit une ouiche en sécurité, ou bien le fait que le seul (quasi) client gmail soit un navigateur prête à sourire ?

votre avatar

Gmail E2EE n’est disponible que sur navigateur pour le moment mais y a apparemment “Google Workspace Client-side Encryption API (beta)” (cf. https://developers.google.com/workspace/cse/guides/overview) en préparation.

votre avatar

Proton Mail souvent encensé ici fonctionne de ma même façon.



Et tu oublies les applications sur mobile.

votre avatar

Difficile de faire confiance à Google à ce sujet, patriot act, tout ça tout ça.

votre avatar

Que peut le Patriot Act sur le chiffrement de bout en bout ?



Merci d’argumenter et sourcer parce que je ne vois.

votre avatar

Voir la réponse d’Uther très complète. L’idéal serait d’utiliser un client tiers pour le chiffrement et envoyer les données chiffrées sur les serveurs de Google.

votre avatar

+1

votre avatar

Le truc c’est que le contenu est bien chiffré sur le serveur et que les clés de chiffrement restent sur le client web. Mais vu que c’est Google qui gère le client, il reste le risque que le client puisse divulguer les clés insidieusement.



Tant que ça ne fonctionnera pas avec un client indépendant et auditable par un tiers, on reste obligé de faire confiance a Google,

votre avatar

AncalagonTotof a dit:


C’est moi qui suit une ouiche en sécurité, ou bien le fait que le seul (quasi) client gmail soit un navigateur prête à sourire ?


Gmail fonctionne en smtp/imap avec n’importe quel client tiers, type thunderbird. Ils ont par contre imposé Oauth2 il y a environ 6 mois qui peut poser pb si non supporté: Cas de mes notifs domotique pour partie gérées par le soft contrôleur et des scripts python. Résolu après avoir collé des mdp d’application mais qui imposent hélas de donner un numéro de mobile pour la récup. Ce dont je me foutais avec un compte dédié domotique jetable au besoin… et sur lesquelles les infos confidentielles (captures caméras…) étaient déjà envoyées dans des archives chiffrées. J’ai bien tenté des fournisseurs alternatifs mais il faut avouer qu’ils ont tous été très en dessous de google sur qq semaines d’essai.



Par contre, si leur chiffrement bout en bout impose le webmail, ce sera comme proton mail et autres: Zéro intérêt.

votre avatar

yl a dit:


Gmail fonctionne en smtp/imap avec n’importe quel client tiers, type thunderbird. Ils ont par contre imposé Oauth2 il y a environ 6 mois qui peut poser pb si non supporté: Cas de mes notifs domotique pour partie gérées par le soft contrôleur et des scripts python. Résolu après avoir collé des mdp d’application mais qui imposent hélas de donner un numéro de mobile pour la récup. Ce dont je me foutais avec un compte dédié domotique jetable au besoin… et sur lesquelles les infos confidentielles (captures caméras…) étaient déjà envoyées dans des archives chiffrées. J’ai bien tenté des fournisseurs alternatifs mais il faut avouer qu’ils ont tous été très en dessous de google sur qq semaines d’essai.



Par contre, si leur chiffrement bout en bout impose le webmail, ce sera comme proton mail et autres: Zéro intérêt.


Ca n’arrivera jamais, sécurité rime avec complexité et implication. Tu ne peux pas avoir un truc bullet proof qui fonctionne en web, appli dédié, windows, linux, android, ios,… juste en appuyant sur un bouton. Ça nécessite que les humain de chaque coté s’impliquent.



Si tu veux du E2EE dans ton client mail sans dépendre de presque personne, tu dois passer par GPG, avec les conséquences que ca impliquent:




  • Que tes contacts utilisent eux même GPG

  • Avoir vérifié préalablement l’identité réelle <=> identité GPG

  • Que tout le monde aient le même niveau de rigueur de gestion de ses clés => hsm



Bref, quand je vois comment les gens de mon entourages ne comprennent rien, et ne veulent pas comprendre (je ne blame personne, chacun ses centres d’intérêts), les boites comme Google ou Proton proposent des alternatives qui positionne le curseur différement, en proposant une solution relativement sécurisé, sans devoir comprendre toute la mécanique interne, avec pour tarif, de devoir faire confiance au tier.

votre avatar

Après en dehors de l’e-mail, les clients de messagerie instantanée, type Olvid, ont rendus le truc simple pour l’utilisation.



Génération des clefs sur le téléphone, puis échange de clefs par qr-code et c’est partie. Il y a juste la gestion de la sauvegarde des clefs derrière (et ça reste centralisé).

votre avatar

Ethan23 a dit:


Voir la réponse d’Uther très complète. L’idéal serait d’utiliser un client tiers pour le chiffrement et envoyer les données chiffrées sur les serveurs de Google.


Ca existe déjà: GPG. Avec pour conséquence ce que j’ai écrit juste au dessus.

votre avatar

Ethan23 a dit:


Difficile de faire confiance à Google à ce sujet, patriot act, tout ça tout ça.


Cela a quand même embêté le FBI sur des iPhones…

votre avatar

Les iPhones sont un « client » décidé, pas une interface web.

votre avatar

fred42 a dit:


Que peut le Patriot Act sur le chiffrement de bout en bout ?



Merci d’argumenter et sourcer parce que je ne vois.


Je ne suis pas au fait des dernières normes sur les emails, mais il me semble que les emails ne sont pas chiffrés de bout en bout. Ça sert à rien d’avoir une boite au lettres blindée si c’est pour empêcher le facteur de lire ton courrier.

votre avatar

pamputt a dit:


Les iPhones sont un « client » décidé, pas une interface web.


Oui merci je sais. C’était juste pour dire que le patriot act ne permet pas d’avoir accès à tout.

votre avatar

marba a dit:


Je ne suis pas au fait des dernières normes sur les emails, mais il me semble que les emails ne sont pas chiffrés de bout en bout. Ça sert à rien d’avoir une boite au lettres blindée si c’est pour empêcher le facteur de lire ton courrier.


C’est ce qui est indiqué dans la brève. Les en-têtes ne seront pas chiffres, seuls le corps du message et les pièces jointes le seront.

votre avatar

pamputt a dit:


C’est ce qui est indiqué dans la brève. Les en-têtes ne seront pas chiffres, seuls le corps du message et les pièces jointes le seront.


Ça n’est pas clair de quoi on parle.



Est ce que c’est la boîte email qui est chiffrée ? Est-ce que l’envoi/réception d’email est chiffré (j’en doute) ?

votre avatar

Quand on parle de “bout en bout”, le corps du message est chiffré et déchiffré par les clients mails. Il n’est donc pas en clair quand il sort du client mail que ce soit sur Internet (où il y avait déjà SSL pour le transport) ou sur les serveurs de google.



La clé de déchiffrement n’est connue que du récepteur.



C’est au contraire très clair.

votre avatar

ForceRouge a dit:


Si tu veux du E2EE dans ton client mail sans dépendre de presque personne, tu dois passer par GPG, avec les conséquences que ca impliquent:




  • Que tes contacts utilisent eux même GPG…


C’est une grosse contrainte, même s’il y a des outils pour la gérer. L’autre, c’est de savoir si google ne bloque pas: Avec une simple archive chiffrée/protégée par mdp en PJ, cela ne passe pas sur chiffrement complet (incluant les métadonnées path/noms de fichiers). Il ne doit y avoir que les données des fichiers de chiffrées sinon refus: Soit disant pour examiner des noms de véroles connues, comme si c’était une parade justifiée!



Alors un chiffrement GPG complet de bout en bout, pas certain que cela passe chez eux?

votre avatar

fred42 a dit:


C’est au contraire très clair.


Bah non pas du tout :




Ce chiffrement côté client (Client-side encryption, ou CSE) de Google Workspace était déjà disponible pour les utilisateurs de Google Drive, Google Docs


Depuis quand Google Docs sert à envoyer des emails ? Et le chiffrement de bout en bout ça peut être également pour l’enregistrement des emails, ou de fichiers en eux-mêmes comme le fait protonmail.



Sur protonmail la boite est chiffrée et on peut envoyer au choix des mails chiffrés ou non.



Le protocole utilisé par Google est fr.wikipedia.org Wikipediaqui est standard. C’est un peu ça qui manquait à la brève pour que je soit sur de quoi on parle.



Fin bref, chiffrement de Google ça vaut rien.

votre avatar

yl a dit:


C’est une grosse contrainte, même s’il y a des outils pour la gérer. L’autre, c’est de savoir si google ne bloque pas: Avec une simple archive chiffrée/protégée par mdp en PJ, cela ne passe pas sur chiffrement complet (incluant les métadonnées path/noms de fichiers). Il ne doit y avoir que les données des fichiers de chiffrées sinon refus: Soit disant pour examiner des noms de véroles connues, comme si c’était une parade justifiée!



Alors un chiffrement GPG complet de bout en bout, pas certain que cela passe chez eux?


Le chiffrement GPG, ca prend tout le contenu de l’email (message + pièces jointes),e le chiffre et en sort un texte en base64. Ce texte en base64 est soit le message, soit une pièce jointe de l’email non chiffré. Tout ca pour dire que du point de vue de Google, ils transmettent simplement un message texte ou une pièce jointe. Ils se foutent de ce qu’il y a dedans.
Et comme le payload est chiffré avant d’être envoyé, et déchiffré une fois reçu sur le PC client, Google ne peut rien voir.

votre avatar

marba a dit:


Bah non pas du tout :


Bah si. L’article parle de 2 choses différentes en terme de chiffrement :




  1. le chiffrement de bout en bout des mail.

  2. un chiffrement dit “côté client” dans Drive et Docs où l’on peut chiffrer avec sa propre clé. Je pense que bleepingcomputer.com fais une erreur en parlant pour cela de E2EE (ce n,‘est pas E2E). D’où peut-être une confusion de ta part si tu as lu leur article.




Depuis quand Google Docs sert à envoyer des emails ? Et le chiffrement de bout en bout ça peut être également pour l’enregistrement des emails, ou de fichiers en eux-mêmes comme le fait protonmail.


Il ne s’agit pas d’envoi de mail pour Google Docs, il s’agit du second sujet.



On ne parle de chiffrement de bout en bout que quand on envoie quelque chose à quelqu’un, pas quand on stocke sur un serveur en chiffrant avec notre clé.




Sur protonmail la boite est chiffrée et on peut envoyer au choix des mails chiffrés ou non.


Oui, et ?
Avec Google, on peut aussi choisir si on chiffre ou non un mail, et c’est heureux.




Le protocole utilisé par Google est fr.wikipedia.org Wikipediaqui est standard. C’est un peu ça qui manquait à la brève pour que je soit sur de quoi on parle.


Encore heureux qu’ils utilisent un standard ! Mais le contraire m’aurait étonné dans ce contexte.




Fin bref, chiffrement de Google ça vaut rien.


C’est toi qui le dit, sans rien démontrer. je pense qu’il est au même niveau que celui de Proton Mail en ce qui concerne le mail chiffré de bout en bout d’après ce que j’en ai lu.

votre avatar

fred42 a dit:


Bah si. L’article parle de 2 choses différentes en terme de chiffrement :




  1. le chiffrement de bout en bout des mail.

  2. un chiffrement dit “côté client” dans Drive et Docs où l’on peut chiffrer avec sa propre clé. Je pense que bleepingcomputer.com fais une erreur en parlant pour cela de E2EE (ce n,‘est pas E2E). D’où peut-être une confusion de ta part si tu as lu leur article.


Cet article ne me parait pas plus clair, il ne distingue pas bien les deux choses pourtant différentes.




Encore heureux qu’ils utilisent un standard ! Mais le contraire m’aurait étonné dans ce contexte.


Moi aussi, mais vu que le nom des technos est pas précisé, on sait pas de quoi on parle.




C’est toi qui le dit, sans rien démontrer. je pense qu’il est au même niveau que celui de Proton Mail en ce qui concerne le mail chiffré de bout en bout d’après ce que j’en ai lu.


Sur le principe, oui, ça a les mêmes failles que protonmail : ils peuvent intercepter le pass de chiffrement, donc ils ont la capacité de déchiffrer. Reste à savoir à qui on fait le plus confiance.

votre avatar

Après avoir configuré CSE, vous pouvez choisir quels utilisateurs peuvent créer du contenu chiffré côté client et le partager en interne ou en externe





Après avoir configuré OpenGPG, vous pouvez choisir avec quels utilisateurs communiquer des mails chiffrés côté client et partager votre clé publique en interne ou en externe


:cap: :D

votre avatar

Au vu du screenshot, j’ai l’impression que ça ressemble à ce que Microsoft fait avec le contenu du mail qui est lisible sur outlook.com après authent avec un compte autorisé (c’est comme ça qu’ils nous transmettent des infos relatives à un produit en preview privée par exemple). Le corps du mail n’est qu’un lien vers le portail pour le lire.

votre avatar

marba a dit:


Ça n’est pas clair de quoi on parle.



Est ce que c’est la boîte email qui est chiffrée ? Est-ce que l’envoi/réception d’email est chiffré (j’en doute) ?


Je suppose que c’est comme ProtonMail : Chiffrement asymétrique, l’utilisateur est le seul à avoir accès à la clé de déchiffrement (clé privée), mais la clé de chiffrement (clé publique) elle est accessible aussi au serveur.
Ce qui signifie que si tu reçois un email d’un tiers qui te l’envoie en clair plutôt qu’en le chiffrant via ta clé privée, c’est le serveur qui le chiffre avant de le stocker (et donc peut éventuellement faire ce qu’il veut du clair avant, comme le copier, le modifier, etc). Idem si tu envoies un email à un tiers qui ne supporte pas ce chiffrement, l’email est alors envoyé en clair au serveur pour qu’il puisse l’envoyer en clair au destinataire. Mais ta copie sera ensuite stockée en E2E sur ton propre compte.



En somme c’est véritablement E2E uniquement en communiquant avec des tiers supportant le même chiffrement/protocole que Gmail/ProtonMail. Dans le cas de ProtonMail par exemple il me semble que ça ne fait pas si longtemps qu’ils permettent d’utiliser du “vrai” PGP et donc de pouvoir communiquer E2E même si ton destinataire utilise pas lui aussi ProtonMail.
Je ne sais pas si Gmail a les mêmes limitations.

votre avatar

Il semble que l’article confond Gmail avec Workspace et l’utilise de manière interchangeable, tous les articles Google liés renvoient vers les pages d’aide administrateur Google Workspace, je ne vois pas d’indication que E2EE sera disponible pour les utilisateurs de Gmail standards, considérant que SMIME n’est pas disponible pour les utilisateurs de Workspace.



Google possédera toujours une deuxième clé secrète pour déchiffrer vos e-mails sous la demande des autorités et des gouvernements, mais j’ai lu qu’il s’agirait plus d’une fonctionnalité de conformité qui vous permet de travailler avec des informations personnelles tout en respectant les réglementations comme PCI qui vous obligent à tout chiffrer en transit au repos, je l’ai lu sur Hacker News donc prenez là avec un grain de sel.

votre avatar

Après relecture, je pense avoir fait une erreur de jugement parce que l’article ne suppose pas que E2EE sera à coup sûr disponible pour les utilisateurs de Gmail standards, mais je suppose que ses articles peuvent prêter à confusion.



A voir, je pense que ce n’est pas mal, même si l’email chiffré n’accompli vraiment pas grand chose en règle général.



https://latacora.singles/2020/02/19/stop-using-encrypted.html
https://www.kicksecure.com/wiki/OpenPGP#Issues_with_PGP

votre avatar

Et Google qui analyse toutes les images pour détecter celles à caractère pédo pornographique. Comment va-t-il faire pour ?



cf. nextinpact.com Next INpact(même si ici, c’est Google Photo, ça aurait pu arriver avec Gmail)

votre avatar

bansan a dit:


Et Google qui analyse toutes les images pour détecter celles à caractère pédo pornographique. Comment va-t-il faire pour ?



cf. nextinpact.com Next INpact(même si ici, c’est Google Photo, ça aurait pu arriver avec Gmail)


Et bien il ne le fera pas car ne disposant pas des clefs de chiffrage….

votre avatar

(quote:2111430:Kazer2.0)
Après en dehors de l’e-mail, les clients de messagerie instantanée, type Olvid, ont rendus le truc simple pour l’utilisation.



Génération des clefs sur le téléphone, puis échange de clefs par qr-code et c’est partie. Il y a juste la gestion de la sauvegarde des clefs derrière (et ça reste centralisé).


Combien utilise Olvid? A peu prêt autant que de gens qui utilise GPG… :)

votre avatar

Mes parents utilisent Olvid, je ne suis pas sûr que j’arriverais à le faire utiliser GPG par contre.



À part la sauvegarde, Olvid est simple d’utilisation (et l’échange des clefs en direct par QR-Code), même si ce n’est pas la seule.

votre avatar

(quote:2111700:Kazer2.0)
Mes parents utilisent Olvid, je ne suis pas sûr que j’arriverais à le faire utiliser GPG par contre.



À part la sauvegarde, Olvid est simple d’utilisation (et l’échange des clefs en direct par QR-Code), même si ce n’est pas la seule.


Le périmètre d’Olvid est ridicule comparé à GPG. Il fait un truc et le fait bien, mais ce n’est pas du tout comparable.
GPG sert à chiffrer, signer, certifier.
La composante privée peut être stocké dans un HSM.
Le périmètre de GPG est bien plus vaste. De la messagerie instantanée, aux e-mails, en passant par la signature de package Linux et le chiffrement de fichiers locaux, …

Gmail autorise le chiffrement de bout en bout pour certains de ses clients

Fermer