Connexion
Abonnez-vous

Yahoo Mail chiffrera lui aussi les emails avec une extension dédiée à PGP

Le chiffrement pour les (pas trop) nuls

Yahoo Mail chiffrera lui aussi les emails avec une extension dédiée à PGP

Le 08 août 2014 à 11h37

Yahoo proposera durant l’automne le support du chiffrement PGP des données dans son service Mail. La firme procèdera en fait de la même manière que Google, c’est-à-dire via l’utilisation d'un plugin spécifique pour les navigateurs.

Début juin, Google abordait le chiffrement des données via PGP grâce à une extension capable de largement simplifier les manipulations. « Pretty Good Privacy » est une solution existante depuis plus de vingt ans mais dont l’emploi implique que l’utilisateur sache se servir d’une solution reposant sur une infrastructure à clés privée et publique. L’extension End-to-End, développée par Google, a pour objectif de fournir ce chiffrement sur un plateau, en facilitant la vie de l’utilisateur.

 

Et c’est en pleine conférence Black Hat que Yahoo a annoncé qu’elle allait utiliser la même extension, en version modifiée, pour son propre service Mail. Une première sera mise à disposition des utilisateurs durant l’automne, sans qu’une date plus précise n’ait été indiquée. Elle s’adressera évidemment à tous ceux qui veulent mettre en place une telle solution, en simplifiant autant que possible les étapes.

 

Cela étant, les remarques qui étaient valables pour Gmail le sont avec Yahoo Mail. Ainsi, la reprise de cette extension ne fait que mettre en exergue le manque de fonctionnalités simples directement implantées dans les services qui en ont besoin. Même si simplicité et sécurité vont rarement de pair, il est plus que temps que les entreprises se penchent sérieusement sur la question et se mettent d’accord sur des solutions communes.

 

 

D’autre part, et c’est sans doute le plus important, le chiffrement des emails ne s’occupe que du contenu. Cela revient à envoyer un colis postal que l’on ne pourrait pas ouvrir : impossible d’en voir le contenu, mais les adresses de l’expéditeur et du destinataire sont parfaitement visibles. En d’autres termes, les métadonnées de chaque mail restent affichées en clair.

 

Interrogé par IT News, Alex Stamos, qui a fait hier soir l’annonce sur Twitter de l’arrivée de cette extension, précise que « ce ne sera pas facile ». Il reste cependant confiant : « Je pense que nous pouvons concevoir une expérience utilisateur qui rend le chiffrement des messages possible en un clic pour beaucoup de personnes ». Stamos n’a cependant rien dit sur l’attitude éventuelle des agences de sécurité face à ce projet.

 

La version finale du plugin est en tout cas attendue pour 2015, là encore sans plus de précisions.

Commentaires (29)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

La NSA aura évidement sa clé de déchiffrement … La question ne se pose même pas <img data-src=" />

votre avatar







Zimt a écrit :



La NSA aura évidement sa clé de déchiffrement … La question ne se pose même pas <img data-src=" />







:facepalm: … le but c’est que tu as un plugin sur ton poste, avec “ta” clé privée, et tu envoi à un destinataire qui a une clé publique que tu lui a fournis pour déchiffrer ton mail.



Chiffrage, clé, déchiffrage tout se fera sur les postes locaux. donc la NSA n’a pas de raison d’avoir “ta” clé si tu ne lui donnes pas …



Après le jeu sera de se débrouiller pour “passer la clé” … sans passer par un mail <img data-src=" />


votre avatar







atomusk a écrit :



:facepalm: … le but c’est que tu as un plugin sur ton poste, avec “ta” clé privée, et tu envoi à un destinataire qui a une clé publique que tu lui a fournis pour déchiffrer ton mail.



Chiffrage, clé, déchiffrage tout se fera sur les postes locaux. donc la NSA n’a pas de raison d’avoir “ta” clé si tu ne lui donnes pas …



Après le jeu sera de se débrouiller pour “passer la clé” … sans passer par un mail <img data-src=" />





un message privé sur FB :oui2:



mais bien joué yahoo, en espérant que ça soit bien compatible avec Gmail comme c’est prévu toussa


votre avatar

il y a des serveurs de clés publiques déjà …



Non ce qu’il manque vraiment c’est un truc standardisé par le w3c pour que les navigateurs puissent faire du chiffrement/signature côté navigateur sans passer par des trucs plus ou moins exotiques et surtout que ce soit implémenté sur les navigateurs…

votre avatar







atomusk a écrit :



:facepalm: … le but c’est que tu as un plugin sur ton poste, avec “ta” clé privée, et tu envoi à un destinataire qui a une clé publique que tu lui a fournis pour déchiffrer ton mail.



Chiffrage, clé, déchiffrage tout se fera sur les postes locaux. donc la NSA n’a pas de raison d’avoir “ta” clé si tu ne lui donnes pas …



Après le jeu sera de se débrouiller pour “passer la clé” … sans passer par un mail <img data-src=" />





Ben que la nsa récupère ta cle publique, c’est pas grave. de toute façon, tu as encodé le mail avec la clé publique de ton destinataire, qui lui ne pourra le décoder qu’avec sa clef privée (qui, ne circule pas elle).

La seul soluce pour la nsa serait de s’être faite passée pour ton destinataire et t’avoir filé leur clé publique pour chiffrer le mail. Bon, ils ont toute une ferme de calculateur pour casser le chiffrement de ton mail, mais je doute qu’ils mettent cette puissance à dispo pour tes mails à toi hein, rassure toi.


votre avatar







nirgal76 a écrit :



Ben que la nsa récupère ta cle publique, c’est pas grave. de toute façon, tu as encodé le mail avec la clé publique de ton destinataire, qui lui ne pourra le décoder qu’avec sa clef privée (qui, ne circule pas elle).

La seul soluce pour la nsa serait de s’être faite passée pour ton destinataire et t’avoir filé leur clé publique pour chiffrer le mail. Bon, ils ont toute une ferme de calculateur pour casser le chiffrement de ton mail, mais je doute qu’ils mettent cette puissance à dispo pour tes mails à toi hein, rassure toi.









En effet, c’est ce sens là, me suis loupé <img data-src=" />


votre avatar







Zimt a écrit :



La NSA aura évidement sa clé de déchiffrement … La question ne se pose même pas <img data-src=" />







pourquoi faire vu qu’ils auront une vu du mail avant chiffrement directe de ton webmail <img data-src=" />


votre avatar

PGP est en closed source non ?



Backdoor tout ça non ?

votre avatar







FRANCKYIV a écrit :



PGP est en closed source non ?



Backdoor tout ça non ?





Le PGP originel d’il y a 25 ans n’était pas libre, mais le code source était quand même déjà ouvert. Mais maintenant, il y a GPG, libre, ouvert, et 100% compatible PGP.


votre avatar







alexandredenis a écrit :



Le PGP originel d’il y a 25 ans n’était pas libre, mais le code source était quand même déjà ouvert. Mais maintenant, il y a GPG, libre, ouvert, et 100% compatible PGP.







Ok pour GPG, mais la je parlais de la news ;)


votre avatar







atomusk a écrit :



En effet, c’est ce sens là, me suis loupé <img data-src=" />





J’ai pas de mérite, j’ai développé un cryptage RSA au boulot ;)


votre avatar







pharyon a écrit :



(…)



J’utilise (ou du moins je suis prêt à utiliser PGP (avec thunderbird+enigmail sur PC ou K9-mail+APG sur android) depuis longtemps. Le seul pépin c’est que seul 1 ou 2 contacts l’utilisent de temps à autre avec moi…. pour me faire plaisir…. <img data-src=" />



L’idéal serait de l”utiliser massivement y compris pour les mails les plus simples. C’est loin d’être le cas… (…)







J’espère que les différentes solutions de chiffrement-déchiffrement PGP-OpenPGP sont compatibles entre elles, c’est à dire qu’un message chiffré avec une application puisse être relu avec une autre application d’une manière transparente.


votre avatar







nirgal76 a écrit :



Ben que la nsa récupère ta cle publique, c’est pas grave. de toute façon, tu as encodé le mail avec la clé publique





<img data-src=" />

De grâce, pas “encodé”, pliz, mais chiffrer (à la rigueur, “codé”, car on parle aussi de message codé, le chiffrement est un codage).







Zimt a écrit :



Meuh oui par exemple la génération de nombre aléatoire en fonction du serial number du CPU comme ça se fait déjà …





Après ta grosse bêtise en 1er commentaire, tu devrais faire attention. La génération des nombres aléatoires, en tous cas sur Linux, se fait en prenant plusieurs sources, sachant qu’on se méfie même de la fonction (relativement) récente intégrée aux CPU Intel, qui s’appelle RDRAND je crois. Ceux qui écrivent les logiciels de génération aléatoires réfléchissent un peu, figure-toi.







nirgal76 a écrit :



J’ai pas de mérite, j’ai développé un cryptagechiffrement RSA au boulot ;)





<img data-src=" />


votre avatar







FRANCKYIV a écrit :



PGP est en closed source non ?



Backdoor tout ça non ?





La news dit que l’extension de Yahoo serait une version modifiée de celle de Google (End-to-End) qui utilise OpenPGP et dont le code source est donc libre.


votre avatar







Lanthares a écrit :



La news dit que l’extension de Yahoo serait une version modifiée de celle de Google (End-to-End) qui utilise OpenPGP et dont le code source est donc libre.







&gt;Et c’est en pleine conférence Black Hat que Yahoo

&gt;a annoncé qu’elle allait utiliser la même extension,

&gt;en version modifiée,



A quel niveau ?



Sinon je me posais la question car dans le tweet il parle de PGP, pas d’OpenPGP.



Après c’est peut-être un abus de langage <img data-src=" />


votre avatar







FRANCKYIV a écrit :



&gt;Et c’est en pleine conférence Black Hat que Yahoo

&gt;a annoncé qu’elle allait utiliser la même extension,

&gt;en version modifiée,



A quel niveau ?



Sinon je me posais la question car dans le tweet il parle de PGP, pas d’OpenPGP.



Après c’est peut-être un abus de langage <img data-src=" />





Dans le titre de la news consacrée à End-to-End le terme PGP est également utilisé, pourtant au sein du texte c’est bien OpenPGP qui est cité, peut-être qu’il s’agit comme tu dis d’un abus ou d’une facilité de langage.



Pour ce qui est des modifications, un point pour toi, j’en sais rien, faudrait demander à Vincent. <img data-src=" />


votre avatar







FRANCKYIV a écrit :



&gt;Et c’est en pleine conférence Black Hat que Yahoo

&gt;a annoncé qu’elle allait utiliser la même extension,

&gt;en version modifiée,



A quel niveau ?



Sinon je me posais la question car dans le tweet il parle de PGP, pas d’OpenPGP.



Après c’est peut-être un abus de langage <img data-src=" />



Sauf erreur :




  • PGP (Pretty Good Privacy) est le soft originel de Philip Zimmerman, open source mais non libre.

  • OpenPGP est une “norme” (RFC 2440, RFC 4880) basée sur le fonctionnement de PGP.

  • GPG (GNU Privacy Guard) est une implémentation libre d’OpenPGP.





    Quant à la modification de Yahoo, c’est probablement pour s’adapter au webmail Yahoo (Zimbra, je crois) plutôt qu’à l’interface GMail.


votre avatar







papinse a écrit :



Sauf erreur :




  • PGP (Pretty Good Privacy) est le soft originel de Philip Zimmerman, open source mais non libre.

  • OpenPGP est une “norme” (RFC 2440, RFC 4880) basée sur le fonctionnement de PGP.

  • GPG (GNU Privacy Guard) est une implémentation libre d’OpenPGP.





    Quant à la modification de Yahoo, c’est probablement pour s’adapter au webmail Yahoo (Zimbra, je crois) plutôt qu’à l’interface GMail.





    Merci pour les explications. <img data-src=" />


votre avatar







papinse a écrit :



Sauf erreur :




  • PGP (Pretty Good Privacy) est le soft originel de Philip Zimmerman, open source mais non libre.

  • OpenPGP est une “norme” (RFC 2440, RFC 4880) basée sur le fonctionnement de PGP.

  • GPG (GNU Privacy Guard) est une implémentation libre d’OpenPGP.





    Quant à la modification de Yahoo, c’est probablement pour s’adapter au webmail Yahoo (Zimbra, je crois) plutôt qu’à l’interface GMail.







    Ah ok, donc il y a une différence entre GPG et OpenPGP <img data-src=" />


votre avatar







Lanthares a écrit :



Merci pour les explications. <img data-src=" />







FRANCKYIV a écrit :



Ah ok, donc il y a une différence entre GPG et OpenPGP <img data-src=" />



Pour être honnète, je ne savais pas la différence non plus il y a 20 minutes donc j’ai cherché. <img data-src=" />

Après, je me suis souvenu du “Quand tu ne sais pas, demande. Quand tu sais, partage.” <img data-src=" />


votre avatar







Lordtoniok a écrit :



Non ce qu’il manque vraiment c’est un truc standardisé par le w3c pour que les navigateurs puissent faire du chiffrement/signature côté navigateur sans passer par des trucs plus ou moins exotiques et surtout que ce soit implémenté sur les navigateurs…





Sinon on a ceux qui expliquent que le chiffrement en javascript n’est pas sûr et que SSL c’est mieux,



le créateur de miniLock qui explique que les bibliothèques de crypto en javascript ont suffisamment mûri et que Chrome via entre autre sa sandbox et les extensions dont le code est signé offre un moyen sûr de chiffrer via le navigateur,



ceux qui comme toi pensent que l’avenir c’est le chiffrement dans le navigateur via l’api web crypto,



et ceux qui pensent que le chiffrement via le navigateur ne pourra jamais être considéré comme sûr.



Qui a raison ? <img data-src=" />


votre avatar







Lanthares a écrit :



Sinon on a ceux qui expliquent que le chiffrement en javascript n’est pas sûr et que SSL c’est mieux,



le créateur de miniLock qui explique que les bibliothèques de crypto en javascript ont suffisamment mûri et que Chrome via entre autre sa sandbox et les extensions dont le code est signé offre un moyen sûr de chiffrer via le navigateur,



ceux qui comme toi pensent que l’avenir c’est le chiffrement dans le navigateur via l’api web crypto,



et ceux qui pensent que le chiffrement via le navigateur ne pourra jamais être considéré comme sûr.



Qui a raison ? <img data-src=" />





Chiffrer avec Chrome… qui envoie les données en clair à google en cas de besoin. Quelle fumisterie <img data-src=" />


votre avatar







RRMX a écrit :



Chiffrer avec Chrome… qui envoie les données en clair à google en cas de besoin. Quelle fumisterie <img data-src=" />





Ben dans la vidéo de conférence où il présente son extension, il explique bien qu’il a créé miniLock d’abord sur Chrome pour des raisons de sécurité parce qu’il pense que c’est le navigateur qui donne le plus de garanties à ce niveau-là.



Après si Chrome c’est un souci y’aura des portages sur Firefox et Safari et puis y’a Chromium aussi.



Mais bon le mec n’a pas l’air d’être un vendu à Google (ou bien je suis naïf <img data-src=" />), et il a l’air de s’y connaître puisqu’il fait parti de l’équipe du w3c qui bosse sur le draft consacré à l’api web crypto.



Enfin la question reste posée, peut-on faire confiance à un navigateur quel qu’il soit pour chiffrer des données en javascript ?


votre avatar



le chiffrement des emails ne s’occupe que du contenu





Effectivement mais c’est déjà beaucoup mieux que rien comme c’est le cas maintenant.



Je suis d’accord avec votre article. Sans simplification pour l’utilisateur le service ne sera jamais utilisé comme il le faudrait.



J’utilise (ou du moins je suis prêt à utiliser PGP (avec thunderbird+enigmail sur PC ou K9-mail+APG sur android) depuis longtemps. Le seul pépin c’est que seul 1 ou 2 contacts l’utilisent de temps à autre avec moi…. pour me faire plaisir…. <img data-src=" />



L’idéal serait de l”utiliser massivement y compris pour les mails les plus simples. C’est loin d’être le cas… Du coup de nos jours si un mail part avec des entêtes PGP, j’imagine qu’il doit arriver en rouge dans les bureaux des RG pour historiser les méta.

votre avatar







Lanthares a écrit :



Ben dans la vidéo de conférence où il présente son extension, il explique bien qu’il a créé miniLock d’abord sur Chrome pour des raisons de sécurité parce qu’il pense que c’est le navigateur qui donne le plus de garanties à ce niveau-là.



Après si Chrome c’est un souci y’aura des portages sur Firefox et Safari et puis y’a Chromium aussi.



Mais bon le mec n’a pas l’air d’être un vendu à Google (ou bien je suis naïf <img data-src=" />), et il a l’air de s’y connaître puisqu’il fait parti de l’équipe du w3c qui bosse sur le draft consacré à l’api web crypto.



Enfin la question reste posée, peut-on faire confiance à un navigateur quel qu’il soit pour chiffrer des données en javascript ?





C’est à dire que Chrome trimballe toujours GoogleUpdater et autres qui font… on ne sait quoi, et qu’il est donc possible que Google puisse faire appel à la partie non-ouverte de son code pour accéder à du contenu en clair avant le chiffrage en javascript. Je ne doute pas que la sandbox et l’environnement dans lequel Javascript est exécuté avec Chrome est sécurisé, cependant je doute que ce soit là la grosse faille liée à Chrome.


votre avatar







RRMX a écrit :



C’est à dire que Chrome trimballe toujours GoogleUpdater et autres qui font… on ne sait quoi, et qu’il est donc possible que Google puisse faire appel à la partie non-ouverte de son code pour accéder à du contenu en clair avant le chiffrage en javascript. Je ne doute pas que la sandbox et l’environnement dans lequel Javascript est exécuté avec Chrome est sécurisé, cependant je doute que ce soit là la grosse faille liée à Chrome.





Ah oui tu as raison, au temps pour moi, je savais pas qu’une partie du code source de Chrome n’était pas ouvert. <img data-src=" />


votre avatar







Lordtoniok a écrit :



il y a des serveurs de clés publiques déjà …



Non ce qu’il manque vraiment c’est un truc standardisé par le w3c pour que les navigateurs puissent faire du chiffrement/signature côté navigateur sans passer par des trucs plus ou moins exotiques et surtout que ce soit implémenté sur les navigateurs…





Meuh oui par exemple la génération de nombre aléatoire en fonction du serial number du CPU comme ça se fait déjà …



hein … ;)


votre avatar







pharyon a écrit :



J’utilise (ou du moins je suis prêt à utiliser PGP (avec thunderbird+enigmail sur PC ou K9-mail+APG sur android) depuis longtemps. Le seul pépin c’est que seul 1 ou 2 contacts l’utilisent de te.







  • 1


votre avatar







Lanthares a écrit :



Ah oui tu as raison, au temps pour moi, je savais pas qu’une partie du code source de Chrome n’était pas ouvert. <img data-src=" />





C’est Chromium qui est entièrement libre.


Yahoo Mail chiffrera lui aussi les emails avec une extension dédiée à PGP

Fermer