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 ».
Commentaires (34)
#1
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 ?
#1.1
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.
#2
Proton Mail souvent encensé ici fonctionne de ma même façon.
Et tu oublies les applications sur mobile.
#3
Difficile de faire confiance à Google à ce sujet, patriot act, tout ça tout ça.
#3.1
Que peut le Patriot Act sur le chiffrement de bout en bout ?
Merci d’argumenter et sourcer parce que je ne vois.
#3.2
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.
#3.3
+1
#4
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,
#5
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.
#6
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:
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.
#6.1
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é).
#7
Ca existe déjà: GPG. Avec pour conséquence ce que j’ai écrit juste au dessus.
#8
Cela a quand même embêté le FBI sur des iPhones…
#8.1
Les iPhones sont un « client » décidé, pas une interface web.
#9
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.
#10
Oui merci je sais. C’était juste pour dire que le patriot act ne permet pas d’avoir accès à tout.
#11
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.
#12
Ç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) ?
#12.1
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.
#13
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?
#14
Bah non pas du tout :
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 https://fr.wikipedia.org/wiki/S/MIME qui 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.
#15
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.
#16
Bah si. L’article parle de 2 choses différentes en terme de chiffrement :
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é.
Oui, et ?
Avec Google, on peut aussi choisir si on chiffre ou non un mail, et c’est heureux.
Encore heureux qu’ils utilisent un standard ! Mais le contraire m’aurait étonné dans ce contexte.
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.
#17
Cet article ne me parait pas plus clair, il ne distingue pas bien les deux choses pourtant différentes.
Moi aussi, mais vu que le nom des technos est pas précisé, on sait pas de quoi on parle.
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.
#18
…
#19
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.
#20
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.
#21
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.
#22
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
#23
Et Google qui analyse toutes les images pour détecter celles à caractère pédo pornographique. Comment va-t-il faire pour ?
cf. https://www.nextinpact.com/article/69833/accuses-a-tort-pedophilie-pour-photos-faites-a-demande-medecins (même si ici, c’est Google Photo, ça aurait pu arriver avec Gmail)
#24
Et bien il ne le fera pas car ne disposant pas des clefs de chiffrage….
#25
Combien utilise Olvid? A peu prêt autant que de gens qui utilise GPG… :)
#25.1
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.
#26
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, …