Google veut chiffrer les emails via PGP et une extension : une bonne idée ?

Google veut chiffrer les emails via PGP et une extension : une bonne idée ?

#PopCorn

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

04/06/2014 7 minutes
91

Google veut chiffrer les emails via PGP et une extension : une bonne idée ?

Certains l'avaient évoqué comme une possibilité, c'est désormais officiel : Google a décidé de communiquer autour de la sécurité des emails et du chiffrement. Le géant du web met ainsi en ligne un mini-site dédié à la question et diffuse le code d'une extension permettant d'exploiter OpenPGP au sein d'un navigateur : end-to-end.

Le chiffrement des emails est une problématique de longue date. En effet, et on ne le dira jamais assez, envoyer un email est semblable à l'envoi d'une carte postale. Tous ceux qui le font transiter ont accès à son contenu, qu'ils soient bienveillants... ou non. Il existe bien entendu la possibilité d'utiliser un chiffrement des échanges, notamment via TLS (Transport Layer Security), mais ce n'est pas systématique. Si vous le faites et pas votre contact, cela n'aura servi à rien.

Google évoque le chiffrement... pour redorer son blason ?

C'est tout le sens d'un nouveau « Transparency report » que Google vient de mettre en ligne. Critiqué pour son éventuelle participation aux programmes de la NSA et son respect de la vie privée, la société a en effet décidé (comme d'autres) d'agir afin d'éviter une fuite en masse de ses utilisateurs. On peut ainsi y voir le nombre de messages entrant et sortant qui sont chiffrés, accéder aux données détaillées, voir les bons et les mauvais élèves de chaque zone géographique, comprendre la problématique du chiffrement des échanges, faire passer le message, etc. Une FAQ a même été publiée.

Mais Google a conscience que placer une enveloppe pendant le transport n'empêche pas le facteur de lire le contenu du courier. Encore faut-il réellement sceller celle-ci. Et là encore des solutions existent depuis des lustres, comme nous l'avons déjà évoqué. Globalement, c'est le principe du chiffement asymétrique qui est utilisé, à la manière de ce que MEGA avait introduit lors de son retour (voir notre dossier). Une méthode que l'on retrouve aussi dans de nombreux outils de sécurité, comme Cryptocat, ou même par les crypto-monnaies pour les adresses de paiement et le porte-monnaie.

Google TLS Chiffrement EmailGoogle TLS Chiffrement Email
Chiffrer vos emails, même de bout en bout, n'est qu'une partie de la solution

Le chiffrement asymétrique à la rescousse, mais cela n'a rien de nouveau

Le principe est simple puisque chaque utilisateur dispose d'une paire de clefs : une privée qui l'identifie, et une publique qui permet de le contacter et qui doit donc être largement diffusée. Dans le cadre des emails, deux actions sont alors possibles : chiffrer et signer. La première vous permet, grâce la clef publique de votre interlocuteur, de rendre le message illisible à un tiers. Vous serez ainsi les seuls à pouvoir le lire, chacun grâce à votre clef privée et la clef publique de l'interlocuteur.

La signature est tout aussi intéressante puisqu'elle permet d'assurer que vous êtes bien l'expéditeur d'un message. Pour la générer, votre clef privée est nécessaire. Pour la vérifier, la personne recevant votre message devra l'associer à votre clef publique. Si les deux correspondent, c'est bien vous. Qui a dit qu'il n'y avait pas de solution au spam ?

Chiffrement asymétrique 
Le chiffrement asymétrique permet de vérifier l'expéditeur mais aussi de protéger le contenu

Pour chiffrer ses emails, de nombreuses solutions existent. Il faut néanmoins se méfier de celles qui promettent une utilisation facile et sans risque. Les soucis rencontrés par TrueCrypt ou OpenSSL montrent en effet que même les solutions largement utilisées et reconnues peuvent rencontrer des soucis importants.

Le principe est donc de ne fait confiance qu'à des outils largement utilisés, libres dans leur implémentation et audités. Comprendre : que le code source doit être accessible et que certains s'y sont penchés sérieusement afin de vérifier qu'il n'y avait ni faille de sécurité, ni porte dérobée.

Autant dire que cela réduit grandement les possibilités, et donc les usages ainsi que les utilisateurs. Depuis quelques années, GnuPG (ou GPG) existe, aussi bien sous Linux que sous Windows par exemple, via GPG4Win. Dans ce dernier cas, il s'agit d'un ensemble d'outils qui permettent de créer et de gérer vos clefs et celles de vos contacts, mais aussi d'envoyer des emails via Clawsmail. Ceux qui préfèrent peuvent aussi utiliser Thunderbird avec l'extension Enigmail

Chiffrer ses mails en ligne c'est déjà possible : mais est-ce vraiment sûr ?

Mais la gestion de clefs et de contacts n'est pas toujours simple, la simplicité étant souvent (mais pas toujours) un ennemi de la sécurité. Sans parler du nombre de clients et d'outils qui n'implémentent pas de telles possibilités, notamment pour le grand public.

De nombreux développeurs ont ainsi proposé des alternatives ou travaillent à des solutions, avec des outils comme Encipher.it ou diverses extensions de navigateurs permettant de gérer des échanges via GnuPG en passant par des outils tout-en-un, en ligne ou non.

Mais rares sont les solutions qui sont convaincantes, et ce pour une raison simple : utiliser un chiffrement asymétrique dans un navigateur, via un outil développé par un tiers, demande de faire confiance à ce dernier (revient alors la question du code libre et audité) mais aussi au navigateur et à sa sécurité.

C'est en effet lui qui va stocker ou accéder à la clef privée à un moment ou à un autre. Autant dire que c'est un peu comme accepter de laisser vos clefs à une société qui vous permettra ensuite d'accéder à votre appartement.

Enigmail 1.5.2
Enigmail

Google end-to-end : une promesse, mais pas (encore ?) une solution

Aucune solution n'aboutissant vraiment ou ne sortant du lot, et ce quel que soit le navigateur et le service en ligne, Google a donc décidé de proposer lui-même une extension : end-to-end. Son code source est diffusé sur Google Code sous licence Apache 2.0 et exploite une bibliothèque JavaScript développée pour l'occasion.

Impossible d'expliquer son fonctionnement de manière détaillée pour le moment puisque le code présent dans le dépôt est incomplet. L'équipe précise que le projet en est pour le moment au stade alpha et qu'une publication sur le Web Store sera effectuée lorsque tout sera prêt, ce qui n'est vraiment pas le cas pour le moment.

Il faut dire qu'un gros débat risque de suivre cette annonce. Le système tel qu'il semble expliqué par Google nécessite en effet une gestion des clefs au sein du navigateur et le support ne semble assuré que pour Gmail. Les méthodes de chiffrement vont sans doute être discutées et contestées, Google ayant déjà pris les devants en expliquant ses choix et les raisons de l'utilisation d'un implémentation JavaScript.

De plus, certains vont se demander dans quelle mesure le but n'est pas de s'assurer que le chiffrement des échanges ne va pas à l'encontre de la stratégie publicitaire de la société qui scanne le contenu de vos échanges afin de proposer des annonces relatives.

Google End-to-end extension

Bref, autant dire que même si cette annonce risque de faire grand bruit, elle ne devrait rien changer au problème de fond dans la pratique avant encore un bon moment. Espérons néanmoins que cette décision va en inciter d'autres à se pencher sérieusement sur la question : des fondations du libre aux sociétés qui sont omniprésentes dans notre vie numériques, en passant par les développeurs qui devraient sérieusement se mettre à fédérer leurs efforts pour produire des solutions exploitables et viables, plutôt que de chercher à bidouiller chacun la sienne sans forcément donner de suite.

Espérons également que cela commencera à sensibiliser un public plus large à la question de la signature et du chiffrement des emails qui, s'ils restent encore parfois complexes, devraient être une simple habitude pour de nombreux échanges, notamment dans un environnement professionnel. Mais sans solutions plus adaptées et plus simple à mettre en place, sur l'ensemble des plateformes disponibles (mobiles ou non), il y a fort à craindre que ce ne sera pas le cas.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Google évoque le chiffrement... pour redorer son blason ?

Le chiffrement asymétrique à la rescousse, mais cela n'a rien de nouveau

Chiffrer ses mails en ligne c'est déjà possible : mais est-ce vraiment sûr ?

Google end-to-end : une promesse, mais pas (encore ?) une solution

Fermer

Commentaires (91)


Cela soulève une autre question.

On sait que Google fait son beurre en lisant les mails de ses clients. Comment compte-t-il faire s’il sont chiffrés ?

J’ai du mal à croire qu’ils tuent la poule aux oeufs d’or.


Mais qu’est-il arrivé à Alice, et qui est cette Anne?<img data-src=" />


Tiens, ils veulent faire comme Apple avec MailDrop pour OSX 10.10.








Tornado_OLO a écrit :



Cela soulève une autre question.

On sait que Google fait son beurre en lisant les mails de ses clients. Comment compte-t-il faire s’il sont chiffrés ?

J’ai du mal à croire qu’ils tuent la poule aux oeufs d’or.





Toi tu as bien lu l’actu <img data-src=" />







Danytime a écrit :



Tiens, ils veulent faire comme Apple avec MailDrop pour OSX 10.10.





Ou MS avec outlook.com (mais leur solution était vraiment spé et passait par un compte… MS)









ragoutoutou a écrit :



Mais qu’est-il arrivé à Alice, et qui est cette Anne?<img data-src=" />





+1









ragoutoutou a écrit :



Mais qu’est-il arrivé à Alice, et qui est cette Anne?<img data-src=" />







<img data-src=" />



Je crois surtout que Bob a virer sa cutie pour vivre avec Dylan <img data-src=" />









Tornado_OLO a écrit :



Cela soulève une autre question.

On sait que Google fait son beurre en lisant les mails de ses clients. Comment compte-t-il faire s’il sont chiffrés ?

J’ai du mal à croire qu’ils tuent la poule aux oeufs d’or.





Dans le schéma ,tu ne le vois pas mais faut rajouter une branche “google” qui continue à lire tes mails ^^.



Et,au pire, il les lit avant l’envoie et après réception lors de ton ouverture du mail par ex.

Et ,rien ne les empêche de connaitre ta clef de chiffrage non plus.Maintenant, à dire si google puisse la passer à la nsa <img data-src=" />









John Shaft a écrit :



<img data-src=" />



Je crois surtout que Bob a virer sa cutie pour vivre avec Dylan <img data-src=" />





ça arrive parfois en cas de “man in the middle”…



Bof au niveau de ma vie privée pour le reste c’est pas moi qui m’en occupe.








Tornado_OLO a écrit :



Cela soulève une autre question.

On sait que Google fait son beurre en lisant les mails de ses clients. Comment compte-t-il faire s’il sont chiffrés ?

J’ai du mal à croire qu’ils tuent la poule aux oeufs d’or.





Pas compliqué, c’est une version “Alpha” si j’ai bien lu, donc tu envoie ton mail, Google le reçois, le décrypte, le lis, le recrypte et le renvoie, ca leur permet de vérifier que le cryptage marche bien <img data-src=" />



J’ai aucune confiance en Google (et la NSA).

Pour moi, si Google se permet de proposer quelque chose comme ça, c’est qu’ils ont déjà travaillé en amonts avec la NSA et qu’ils y ont déjà introduit des backdoors.








Tornado_OLO a écrit :



Cela soulève une autre question.

On sait que Google fait son beurre en lisant les mails de ses clients. Comment compte-t-il faire s’il sont chiffrés ?

J’ai du mal à croire qu’ils tuent la poule aux oeufs d’or.







Si j’ai bien compris, l’objectif de cette extension est





  • de chiffrer le courriel pendant son transport

  • de certifier l’identité des correspondants







    Le premier existait sûrement déjà via TLS, mais ne résout qu’une partie du problème : les courriels sont déchiffrés sur les serveurs de Google, car ils en ont besoin pour le profiling. C’est la raison pour laquelle j’ai retiré mes emails de Gmail et ouvert un compte chez online (en attendant mieux).



    Le second est la principale nouveauté, mais je ne le vois que comme un moyen de lutter contre le phishing et le spam. Ce qui est déjà une avancée.











okeN a écrit :



J’ai aucune confiance en Google (et la NSA).

Pour moi, si Google se permet de proposer quelque chose comme ça, c’est qu’ils ont déjà travaillé en amonts avec la NSA et qu’ils y ont déjà introduit des backdoors.







Même pas besoin de backdoor, Google aura en sa possession les clés privés de ces utilisateurs, et donc si un gouv veut accéder à ce contenu, Google sera obligé d’accepter ^^









Tornado_OLO a écrit :



Cela soulève une autre question.

On sait que Google fait son beurre en lisant les mails de ses clients. Comment compte-t-il faire s’il sont chiffrés ?

J’ai du mal à croire qu’ils tuent la poule aux oeufs d’or.







Ou comme dit dans l’actu, Google gère sa solution pour être sûr de pouvoir continuer à mettre le nez dans les e-mails pour le ciblage publicitaire <img data-src=" />



Ça pourrait amener de grands avantages dans la création de clefs signées par plusieurs personnes.

Si Google propose aux utilisateurs de signer les clefs publiques auxquelles ils font confiance (avec un minimum d’explication), cela pourrait peut être enfin lancer les architectures du type Web-of-Trust plutôt que l’inélégant système hiérarchique de certificate authorities.

(d’ailleurs Google pourrait ensuite déterminer des heuristiques pour savoir quelles clefs sont légitimes en fonction des utilisateurs l’ayant signée)



C’est peut être le coup de pouce qui manquait pour démocratiser le chiffrement par défaut et sensibiliser à l’encryptage asymétrique :)



Enfin je rêve là.








supercolino a écrit :



Si j’ai bien compris, l’objectif de cette extension est





  • de chiffrer le courriel pendant son transport

  • de certifier l’identité des correspondants







    Le premier existait sûrement déjà via TLS, …



    En fait, ce n’est pas le cas.

    Quand un serveur envoie un mail, il passe par plusieurs serveurs mails avant d’arriver chez le serveur mail du destinataire.

    Le premier serveur va communiquer avec un second serveur, et ils vont tous les deux chiffrer leur communication. Mais une fois le mail arrivé sur ce second serveur, ce dernier à accès au mail, qui n’est alors plus crypté. Puis lui même va refaire une communication crypté avec un troisième serveur, et ainsi de suite jusqu’au serveur mail du destinataire.



    Au final tous les serveurs auront accès au mail en clair.









supercolino a écrit :



C’est la raison pour laquelle j’ai retiré mes emails de Gmail et ouvert un compte chez online (en attendant mieux).







Tout pareil !



Par contre je cherche toujours à trouver une solution simple pour la gestion de mon agenda et surtout que ce soit synchronisable avec mon téléphone !









eliumnick a écrit :



Même pas besoin de backdoor, Google aura en sa possession les clés privés de ces utilisateurs, et donc si un gouv le goub US veut accéder à ce contenu, Google sera obligé d’accepter ^^







+1 Ce qui ne contrerait en rien leur analyse des mails sur leur serveur à des fins publicitaires.



Si il restent en clair sur le serveur et que Gmail ne s’occupe que de chiffrer avant le transport et de déchiffre à la réception c’est même pire.



Une clef privée, ca ne se donne pas.

Enfin, wait and see









Lilley a écrit :



C’est peut être le coup de pouce qui manquait pour démocratiser le chiffrement par défaut et sensibiliser à l’encryptage asymétrique :)



Enfin je rêve là.







CHIFFREMENT, HERETIQUE ! <img data-src=" /><img data-src=" />









Tornado_OLO a écrit :



Cela soulève une autre question.

On sait que Google fait son beurre en lisant les mails de ses clients. Comment compte-t-il faire s’il sont chiffrés ?

J’ai du mal à croire qu’ils tuent la poule aux oeufs d’or.





Google a plus intérêt à te garder dans ses filets qu’à te laisser voir ailleurs. Tu ne chiffre pas tout tes mails, tu va garder ton compte gmail connecter quand tu va faire une recherche sur son moteur…



Heu, cette extension est destiné à être une extension chrome, donc potentiellement aussi chromium. Le code source est ouvert pour pouvoir faire un audit (en tout cas, c’est ce que google dit sur sa page) et chromium l’est aussi, donc l’audit est possible, non ? bon on sait aussi que même si c’est possible, ça ne sera pas forcément fait, c’est comme le SSH de mac ou de heartbleed.



Toujours est-il, je pense qu’une extension gmail sous forme de script javascript serait un plus améliorant l’adoption du cryptage en la rendant plus facile à adopté. On peut imaginer aussi par exemple que la clé privé puisse être enregistré dans le cloud, mais qu’elle reste crypté par un mot de passe (ça permet ainsi d’avoir des clés privés complexes, mais garder un mot de passe qui lui est facilement transposable d’une machine à l’autre.)



Envoie un MP à un impactien nommé Anozer, il m’avait filé un tuto pour mettre en œuvre une synchro Cal/CardDAV avec un NAS <img data-src=" />








eliumnick a écrit :



Même pas besoin de backdoor, Google aura en sa possession les clés privés de ces utilisateurs, et donc si un gouv veut accéder à ce contenu, Google sera obligé d’accepter ^^







Pas forcement… c’est poiur ca qu’ils proposent une extension au navigateur, c’est pour laisser les clés sur le poste de l’utilisateur.



Personellement, je pense que c’est tout a fait possible que Google se (re)mette a faire un minimum attention a ses clients et propose des outils fiables et sans backdoor. En tout cas, je suis sur qu’il y aura assez d’avis d’experts independants sur cette extension pour nous rassurer ou l’ecarter au moindre doute.



Neanmoins, il va falloir aussi gerer le probleme des appareils mobiles type tablettes et smartphones. Or, est ce que les autres constructeurs/editeurs comme MS, Apple, HTC, Samsung, etc seront aussi enclins a une transparence totale sur cette problematique de la securité personnelle ?



Pour moi, c’est quand meme pas gagné…



L’ideal serait quand meme de revoir profondement SMTP et IMAP pour prendre en compte ces problematiques serieusement… mais ca sera encore plus long.



ca sert a rien de crypter ses mails la NSA auras toujours les moyens et le dernier mots pour lire notre correspondance avec sa maitresse.

<img data-src=" />








KP2 a écrit :



Pas forcement… c’est poiur ca qu’ils proposent une extension au navigateur, c’est pour laisser les clés sur le poste de l’utilisateur.



Personellement, je pense que c’est tout a fait possible que Google se (re)mette a faire un minimum attention a ses clients et propose des outils fiables et sans backdoor. En tout cas, je suis sur qu’il y aura assez d’avis d’experts independants sur cette extension pour nous rassurer ou l’ecarter au moindre doute.



Neanmoins, il va falloir aussi gerer le probleme des appareils mobiles type tablettes et smartphones. Or, est ce que les autres constructeurs/editeurs comme MS, Apple, HTC, Samsung, etc seront aussi enclins a une transparence totale sur cette problematique de la securité personnelle ?



Pour moi, c’est quand meme pas gagné…



L’ideal serait quand meme de revoir profondement SMTP et IMAP pour prendre en compte ces problematiques serieusement… mais ca sera encore plus long.







Genre si le gouv US arrive pour demander une clé, Google va leur dire “ah bah désolé on se préoccupe de nos clients on a fait exprès de la laisser sur le poste du client” et la le gouv US dira “bah vous vous souvenez de Lavabits ? Fournissez nous la clé ou votre entreprise disparait” :x



J’ai lu en diagonale (pas taper)

Je pensais que leur “brique” servait uniquement à encrypter. Ils sont fourbent lol


1- Si j’ai bien compris la news cela veut dire que pour l’instant le chiffrement end to end ne fonctionnera qu’entre 2 comptes Gmail ?



2- Comme déjà dit… si Google stocke les clés privées, je ne vois pas en quoi cette solution sera plus “sure” qu’une autre…




Tous ceux qui le font transiter ont accès à son contenu, qu’ils soient bienveillants… ou non. Il existe bien entendu la possibilité d’utiliser un chiffrement des échanges, notamment via TLS (Transport Layer Security), mais ce n’est pas systématique. Si vous le faites et pas votre contact, cela n’aura servi à rien.





Cette explication est bizarre : TLS c’est juste pour un bout de la connexion (client-serveur, serveur-serveur…). Même si vous utilisez TLS (entre vous et votre serveur), que votre contact aussi (entre lui et son serveur), et même si vos deux serveurs utilisent TLS entre-eux, chacun des serveurs peut lire le contenu du message…



La grosse différence, c’est le “de bout en bout”.








wanou2 a écrit :



Tout pareil !



Par contre je cherche toujours à trouver une solution simple pour la gestion de mon agenda et surtout que ce soit synchronisable avec mon téléphone !







J’ai installé Baikal sur mon serveur Web. Attention, je n’ai réussi à la faire marcher qu’en l’installant dans un sous-domaine (baikal.mondomaine.com par exemple), à cause de redirections bizarres.



Ensuite sur Thunderbird j’utilise l’extension SoGO et mon téléphone Android CardDAVSync (ou n’importe laquelle qui permet une synchro avec un serveur CardDAV). Et ça marche :)



Me reste plus qu’à faire la même chose avec CalDAV (également sur Baikal) pour le calendrier.









wanou2 a écrit :



Tout pareil !



Par contre je cherche toujours à trouver une solution simple pour la gestion de mon agenda et surtout que ce soit synchronisable avec mon téléphone !





Il te faut une boite mail compatible avec Exchange/Entreprise. De base, hotmail/Outlook le fait très bien (et heureusement). Mais comme ça, je ne sais pas si il y a beaucoup de boite perso qui le permettent (mais beaucoup de boite pro le font).









Droup a écrit :



En fait, ce n’est pas le cas.

Quand un serveur envoie un mail, il passe par plusieurs serveurs mails avant d’arriver chez le serveur mail du destinataire.

Le premier serveur va communiquer avec un second serveur, et ils vont tous les deux chiffrer leur communication. Mais une fois le mail arrivé sur ce second serveur, ce dernier à accès au mail, qui n’est alors plus crypté. Puis lui même va refaire une communication crypté avec un troisième serveur, et ainsi de suite jusqu’au serveur mail du destinataire.



Au final tous les serveurs auront accès au mail en clair.







Oui j’aurais dû préciser que les facteurs peuvent lire le courrier même s’il est chiffré via TLS. Du coup l’extension de Google règle ça je suppose, le courrier étant seulement déchiffrés sur les serveurs de Google et sur le serveur du destinataire.



C’est donc un mieux.









Lilley a écrit :



Ça pourrait amener de grands avantages dans la création de clefs signées par plusieurs personnes.

Si Google propose aux utilisateurs de signer les clefs publiques auxquelles ils font confiance (avec un minimum d’explication), cela pourrait peut être enfin lancer les architectures du type Web-of-Trust plutôt que l’inélégant système hiérarchique de certificate authorities.

(d’ailleurs Google pourrait ensuite déterminer des heuristiques pour savoir quelles clefs sont légitimes en fonction des utilisateurs l’ayant signée)



C’est peut être le coup de pouce qui manquait pour démocratiser le chiffrement par défaut et sensibiliser à l’encryptage asymétrique :)



Enfin je rêve là.







Moi, je n’y crois pas une seule seconde au web of trust…

Le probleme de ce concept, c’est la confiance des masses. Or, les masses ne sont pas assez eduquees, conscientes des risques et critiques pour creer naturellement un “reseau” de confiance solide et perenne.

Aujourd’hui, il est bien trop facile de manipuler l’opinion publique, propager de l’information fausse, creer des buzz pour que les gens se mettent a douter et verifier que telle ou telle personne est bien celle qu’elle pretend etre.

Deja que les gens sont pas foutus de consulter 2 ou 3 sources d’informations differentes alors dela a authentifier des identités… Y’aura bien trop de gens pour mal le faire donc ca ne marchera pas…









®om a écrit :



Cette explication est bizarre : TLS c’est juste pour un bout de la connexion (client-serveur, serveur-serveur…). Même si vous utilisez TLS (entre vous et votre serveur), que votre contact aussi (entre lui et son serveur), et même si vos deux serveurs utilisent TLS entre-eux, chacun des serveurs peut lire le contenu du message…



La grosse différence, c’est le “de bout en bout”.







+1 même si le serveur de chaque bout peut lire le mail, ça améliore la sécurité pendant le transport.









tazvld a écrit :



Il te faut une boite mail compatible avec Exchange/Entreprise. De base, hotmail/Outlook le fait très bien (et heureusement). Mais comme ça, je ne sais pas si il y a beaucoup de boite perso qui le permettent (mais beaucoup de boite pro le font).







Les solutions Microsoft marchent bien, mais on perd le côté confiance vu que c’est du closed source de compétition. Du coup, pour tous ceux qui se préoccupent des backdoors, c’est à éviter.



Je ne savais que les comptes Outlook gratuits étaient compatibles Exchange, c’est bon à savoir.









KP2 a écrit :



Moi, je n’y crois pas une seule seconde au web of trust…

Le probleme de ce concept, c’est la confiance des masses. Or, les masses ne sont pas assez eduquees, conscientes des risques et critiques pour creer naturellement un “reseau” de confiance solide et perenne.

Aujourd’hui, il est bien trop facile de manipuler l’opinion publique, propager de l’information fausse, creer des buzz pour que les gens se mettent a douter et verifier que telle ou telle personne est bien celle qu’elle pretend etre.

Deja que les gens sont pas foutus de consulter 2 ou 3 sources d’informations differentes alors dela a authentifier des identités… Y’aura bien trop de gens pour mal le faire donc ca ne marchera pas…







Pour la confiance de masse je suis d’accord, mais mettons que tu fasses confiance à ton entreprise, ton frère et quelques un(e)s de tes ami(e)s, on peut aussi imaginer que tu fasses confiance à ceux auxquels ils font confiance. C’est le début d’un “intraWeb” of trust <img data-src=" />









David_L a écrit :



Toi tu as bien lu l’actu <img data-src=" />





Déjà quand même il a lu le titre <img data-src=" />







FunnyD a écrit :



Pas compliqué, c’est une version “Alpha” si j’ai bien lu, donc tu envoie ton mail, Google le reçois, le décrypte, le lis, le recrypte et le renvoie, ca leur permet de vérifier que le cryptage marche bien <img data-src=" />





<img data-src=" /> et dans la version beta ils envoient la clé privé à la NSA <img data-src=" />









eliumnick a écrit :



Genre si le gouv US arrive pour demander une clé, Google va leur dire “ah bah désolé on se préoccupe de nos clients on a fait exprès de la laisser sur le poste du client” et la le gouv US dira “bah vous vous souvenez de Lavabits ? Fournissez nous la clé ou votre entreprise disparait” :x







Si la clé privee est reellement sur le poste de l’utilisateur et que Google n’a aucun moyen de la recuperer via l’extension alors ils pourront effectivement s’en laver les mains…

Lavabits est un cas a part, a ma connaissance, on ne sait pas trop precisement ce que leur a demandé le gvt US ni les menaces qu’ils ont subi. Par contre, ils ont fermé leur service tres vite et tres radicalement eux meme.









supercolino a écrit :



Les solutions Microsoft marchent bien, mais on perd le côté confiance vu que c’est du closed source de compétition. Du coup, pour tous ceux qui se préoccupent des backdoors, c’est à éviter.



Je ne savais que les comptes Outlook gratuits étaient compatibles Exchange, c’est bon à savoir.





Il existe des implémentations open source compatible avec Exchange/Entreprise. Je sais par exemple que la solution de webmail “zimbra” propose une compatibilité avec les comptes “Exchange/Entreprise” d’Android. Je ne sais pas si par exemple yahoo ou free l’on laissé activé.









supercolino a écrit :



Pour la confiance de masse je suis d’accord, mais mettons que tu fasses confiance à ton entreprise, ton frère et quelques un(e)s de tes ami(e)s, on peut aussi imaginer que tu fasses confiance à ceux auxquels ils font confiance. C’est le début d’un “intraWeb” of trust <img data-src=" />







Mouais bof… Deja, je suis pas convaincu que je puisse avoir confiance au dela du 1er cercle.

Mais ensuite, qui me dit qu’une de mes personnes de confiance ne s’est pas faite abusee elle meme et fait confiance a qqn qu’il ne faut pas ?

Quand on voit le nombre de naifs qui tombent dans le panneau du phishing, c’est assez effrayant… et meme chez des gens parfois plutot eduqués.



Non, pour moi, definitivement, baser la securité sur une “confiance” de masse est une erreur.

Deja que cette histoire de NSA nous prouve que la confiance envers un nombre limité d’acteurs bien identifiés, censés etre fiables et ayant pignon sur rue peut etre mise a mal profondement alors diperser cette confiance a tout va ne risque pas specialement d’ameliorer les choses.









KP2 a écrit :



Pas forcement… c’est poiur ca qu’ils proposent une extension au navigateur, c’est pour laisser les clés sur le poste de l’utilisateur.











carbier a écrit :



2- Comme déjà dit… si Google stocke les clés privées, je ne vois pas en quoi cette solution sera plus “sure” qu’une autre…







On est bien d’accord que pour l’instant, c’est une inconnue ? On ne sait pas comment une clé privée est stockée dans leur mécanisme n’est ce pas ?



Effectivement, si Google stocke la clé et y a accès, tu as raison Carbier, cette solution c’est plus ou moins du vent. Et ça ne vient pas participer à une meilleure compréhension/utilisation de ce genre de système par chacun : on oublie la règle de base qui est de ne jamais distribuer un mot de passe, une clé privée… et on se croit protéger car on chiffre nos courriels.



Mais, au risque de dire une grosse connerie, moi, je l’ai bafoué cette règle : Google a bien accès à mon mot de passe de compte non ? Alors, j’imagine bien qu’il le conserve sous une forme qui rend son exploitation “impossible” , du moins, je l’espère (je ne suis pas un expert mais Google ou autre doit stocker un hash salé du bazar, quelques chose dans l’esprit….).



N’est-il pas possible d’envisager un truc du genre pour une clé privée ? Ou suis-je largement a côté de la plaque ?









KP2 a écrit :



Si la clé privee est reellement sur le poste de l’utilisateur et que Google n’a aucun moyen de la recuperer via l’extension alors ils pourront effectivement s’en laver les mains…

Lavabits est un cas a part, a ma connaissance, on ne sait pas trop precisement ce que leur a demandé le gvt US ni les menaces qu’ils ont subi. Par contre, ils ont fermé leur service tres vite et tres radicalement eux meme.







Ce n’est pas pake Google choisit de ne pas le faire qu’il ne peuvent pas le faire.



Et pour Lavabits, ils utilisaient la même clé pour tout leur clients, et le gouv voulait cette clé. Du coup Lavabits avait le choix entre donner indirectement tout les mails de leur client, ou de fermer.









malock a écrit :



On est bien d’accord que pour l’instant, c’est une inconnue ? On ne sait pas comment une clé privée est stockée dans leur mécanisme n’est ce pas ?



Effectivement, si Google stocke la clé et y a accès, tu as raison Carbier, cette solution c’est plus ou moins du vent. Et ça ne vient pas participer à une meilleure compréhension/utilisation de ce genre de système par chacun : on oublie la règle de base qui est de ne jamais distribuer un mot de passe, une clé privée… et on se croit protéger car on chiffre nos courriels.



Mais, au risque de dire une grosse connerie, moi, je l’ai bafoué cette règle : Google a bien accès à mon mot de passe de compte non ? Alors, j’imagine bien qu’il le conserve sous une forme qui rend son exploitation “impossible” , du moins, je l’espère (je ne suis pas un expert mais Google ou autre doit stocker un hash salé du bazar, quelques chose dans l’esprit….).



N’est-il pas possible d’envisager un truc du genre pour une clé privée ? Ou suis-je largement a côté de la plaque ?







Je ne pense pas que Google stocke ton mot de passe, mais plutôt une empreinte (ou hash, ou checksum) de celui-ci.



Chaque fois que tu tentes de te connecter, ils génèrent l’empreinte du mot de passe que tu proposes. Si l’empreinte générée est identique à l’empreinte qu’ils ont associé à ton compte, ils t’autorisent à te connecter.



Pour la méthode de faire une empreinte de la clé privée, je ne vois pas comment ça pourrait marcher.









supercolino a écrit :



Je ne pense pas que Google stocke ton mot de passe, mais plutôt une empreinte (ou hash, ou checksum) de celui-ci.



Chaque fois que tu tentes de te connecter, ils génèrent l’empreinte du mot de passe que tu proposes. Si l’empreinte générée est identique à l’empreinte qu’ils ont associé à ton compte, ils t’autorisent à te connecter.







Oui, c’est ce que j’imagine aussi. Je n’ai pas réussi à l’exprimer aussi clairement que toi, merci <img data-src=" />



Mais si Google ou autre faisait de même avec la clé privée, dans ce cas, “ça roule” non ? ça n’est plus un problème d’avoir une empreinte de notre clé privée stockée par chez eux ?









malock a écrit :



Oui, c’est ce que j’imagine aussi. Je n’ai pas réussi à l’exprimer aussi clairement que toi, merci <img data-src=" />



Mais si Google ou autre faisait de même avec la clé privée, dans ce cas, “ça roule” non ? ça n’est plus un problème d’avoir une empreinte de notre clé privée stockée par chez eux ?







Comment utiliser la clé à partir de son empreinte ?









malock a écrit :



N’est-il pas possible d’envisager un truc du genre pour une clé privée ? Ou suis-je largement a côté de la plaque ?







L’idéal serait de le stocker dans le plugin donc coté navigateur …



Ainsi, tant que Google a bien fait son boulo, “Google”, ne sera pas capable de déchiffrer eux même sans le plugin, avec la bonne clé.



Maintenant si ils l’intégrent dans l’outil de synchronisation de Chrome et que l’utilisateur l’active, oui, ils auront la clé …



Mais bon, là faut pas te plaindre <img data-src=" /><img data-src=" />









supercolino a écrit :



Chaque fois que tu tentes de te connecter, ils génèrent l’empreinte du mot de passe que tu proposes. Si l’empreinte générée est identique à l’empreinte qu’ils ont associé à ton compte, ils t’autorisent à te connecter.







Le probleme du mot de passe est moins aussi elevé que cette histoire de stockage de cle privee.



Aujourd’hui, on fait tous confiance aux sites sur lesquels on cree des comptes pour chiffrer ou hasher nos mots de passe dans leur base… mais on en a aucune preuve reelle…

Et meme si il nous donnaient une preuve que notre mot de passe est correctement hashé ou chiffré dans la base, qui sait si ils n’ont pas un mecanisme supplementaire qui stocke le passe ailleurs en clair ?

Qui sait si a chaque fois qu’on se logue sur un site, celui ci n’enregistre pas le contenu du champ password a chaque fois ?



A partir du moment ou on entre une information dans un formulaire, meme si c’est un formulaire de login, il est strictement impossible de savoir ce qui est reellement fait derriere. Totalement impossible.

Car meme si le site publie son source, il est impossible de verifier si c’est bien ce source qui tourne reellement sur le serveur sans se connecter en root dessus.










atomusk a écrit :



L’idéal serait de le stocker dans le plugin donc coté navigateur …



Ainsi, tant que Google a bien fait son boulo, “Google”, ne sera pas capable de déchiffrer eux même sans le plugin, avec la bonne clé.



Maintenant si ils l’intégrent dans l’outil de synchronisation de Chrome et que l’utilisateur l’active, oui, ils auront la clé …



Mais bon, là faut pas te plaindre <img data-src=" /><img data-src=" />







C’est quoi cette fausse quote ? ^^









eliumnick a écrit :



Comment utiliser la clé à partir de son empreinte ?







C’est une bonne question…

A la manière d’un mot de passe comme l’exprime Supercolino ?

Ce n’est d’ailleurs pas le rôle de la passephrase qui est générée (obligatoirement ?) lorsque l’on créé un couple clé publique/clé privée ?



Je précise bien : je me perds bien souvent dans ces mécanismes de protection de mot de passe, de chiffrement, tout ça… si certains peuvent pointer là où je me plante, je vous en serez bien reconnaissant.









malock a écrit :



C’est une bonne question…

A la manière d’un mot de passe comme l’exprime Supercolino ?

Ce n’est d’ailleurs pas le rôle de la passephrase qui est générée (obligatoirement ?) lorsque l’on créé un couple clé publique/clé privée ?



Je précise bien : je me perds bien souvent dans ces mécanismes de protection de mot de passe, de chiffrement, tout ça… si certains peuvent pointer là où je me plante, je vous en serez bien reconnaissant.







Un mot de passe te sert juste à t authentifier (en gros on vérifie que le mdp en base = le mdp saisie), alors que la clé est utilisé directement dans le processus de chiffrement.









malock a écrit :



C’est une bonne question…

A la manière d’un mot de passe comme l’exprime Supercolino ?

Ce n’est d’ailleurs pas le rôle de la passephrase qui est générée (obligatoirement ?) lorsque l’on créé un couple clé publique/clé privée ?



Je précise bien : je me perds bien souvent dans ces mécanismes de protection de mot de passe, de chiffrement, tout ça… si certains peuvent pointer là où je me plante, je vous en serez bien reconnaissant.







Je comprends pas a quoi pourrait servir un hash de cle privee…









supercolino a écrit :



J’ai installé Baikal sur mon serveur Web. Attention, je n’ai réussi à la faire marcher qu’en l’installant dans un sous-domaine (baikal.mondomaine.com par exemple), à cause de redirections bizarres.



Ensuite sur Thunderbird j’utilise l’extension SoGO et mon téléphone Android CardDAVSync (ou n’importe laquelle qui permet une synchro avec un serveur CardDAV). Et ça marche :)



Me reste plus qu’à faire la même chose avec CalDAV (également sur Baikal) pour le calendrier.







Je t’aime toi <img data-src=" />







tazvld a écrit :



Il te faut une boite mail compatible avec Exchange/Entreprise. De base, hotmail/Outlook le fait très bien (et heureusement). Mais comme ça, je ne sais pas si il y a beaucoup de boite perso qui le permettent (mais beaucoup de boite pro le font).







J’ai mon domaine perso et les offres pour un usage basique (1 cpte mail + 1 agenda) en exchange ne sont pas données (3,30 chez ms chez les européens 1&1 : 7€ et ovh 4€) alors que chez Online j’en ai pour 1,2€









wanou2 a écrit :



Je t’aime toi <img data-src=" />







Je crois que owncloud gere toutes ces problematiques… y’a juste a ajouter un serveur imap et c’est bueno, non ?









eliumnick a écrit :



C’est quoi cette fausse quote ? ^^







bonne question … je sais pas comment je me suis débrouillé <img data-src=" />



C’est corrigé <img data-src=" />









atomusk a écrit :



L’idéal serait de le stocker dans le plugin donc coté navigateur …



Ainsi, tant que Google a bien fait son boulo, “Google”, ne sera pas capable de déchiffrer eux même sans le plugin, avec la bonne clé.



Maintenant si ils l’intégrent dans l’outil de synchronisation de Chrome et que l’utilisateur l’active, oui, ils auront la clé …



Mais bon, là faut pas te plaindre <img data-src=" /><img data-src=" />







Oui, ok et d’accord pour l’idéal de stocker côté plugin. Je me demande justement s’il y a pas un moyen de synchroniser l’empreinte d’une clé, de sorte que Google ne puisse pas l’exploiter disons “aussi simplement”.







eliumnick a écrit :



Un mot de passe te sert juste à t authentifier (en gros on vérifie que le mdp en base = le mdp saisie), alors que la clé est utilisé directement dans le processus de chiffrement.







D’accord avec ça oui. Le mot de passe ou la clé privée ont tout deux des objectifs différents. Je me pose la question du maintien en base de données de la clé privée, ce qui est sans doute relativement proche de celui d’un mot de passe.

Je n’arrive sans doute pas à être clair…







KP2 a écrit :



Je comprends pas a quoi pourrait servir un hash de cle privee…







Et bien pour “répondre” à ceux qui très justement affirment que si la clé privée est stockée en l’état chez Google, alors le chiffrement est plus ou moins inutile.

Mais tu as peut être répondu dans ton poste 45.



Je me perds juste un peu dans tout ça… je n’arrive plus à percuter où est le réel soucis.



PS : je crois que j’ai réussi à démêler le bazar que j’ai en tête. Mes excuses… j’ai rien bité au problème… Le fond du problème est qu’il n’y aucune raison à ce que Google conserve notre clé privée (s’il choisisse de le faire).









malock a écrit :



D’accord avec ça oui. Le mot de passe ou la clé privée ont tout deux des objectifs différents. Je me pose la question du maintien en base de données de la clé privée, ce qui est sans doute relativement proche de celui d’un mot de passe.

Je n’arrive sans doute pas à être clair…







Non le but d’un Hash est de vérifier si ce que renseigne l’utilisateur correspond à ce qu’on a stocké en mêmoire.



Le but du chiffrage est que c’est avec la clé qu’on déchiffre le message (enfin c’est plus compliqué avec les clés publiques & privé & co, mais c’est l’idée <img data-src=" />) qui permet de déchiffrer le message.



La régle d’or : à partir du moment où tu peux lire le contenu de tes messages dans un webservice (donc hors plugin/appli tierce), le prestataire de service a ta clé et donc est capable de déchiffrer ton message.



Le but est que tu tapes ton message, une appli locale le chiffre, il l’envoi à google, google le transmet tel quel et c’est une appli locale qui le déchiffre.



Concretement, un hash de clé ne permettra que de valider que la clé que tu renseigne est la bonne … ce qui est inutile, vu que c’est en voyant le message déchiffré que tu verras si ta clé est bonne ..









malock a écrit :



Et bien pour “répondre” à ceux qui très justement affirment que si la clé privée est stockée en l’état chez Google, alors le chiffrement est plus ou moins inutile.

Mais tu as peut être répondu dans ton poste 45.



Je me perds juste un peu dans tout ça… je n’arrive plus à percuter où est le réel soucis.







Et bien, si Google a acces a ta cle privee alors tu n’as aucune securité vis a vis de Google lui meme. Car aujourd’hui, tout le probleme est là : comment garantir la securité de nos données vis a vis de ceux qui les stockent sur leur serveur.



Un hash de la cle privee n’a aucune utilité ni pour eux… ni pour toi malheureusement.



La comparaison avec un hash de pass ne peut pas aller bien loin car on ne parle pas du tout du meme usage. Le pass sert a t’authentifier vis a vis de google alors que la clé va servir a chiffrer ta correspondance avec d’aurtres gens.

La clé doit necessairement etre en clair a un moment ou a un autre pour etre utilisee.









wanou2 a écrit :



Tout pareil !



Par contre je cherche toujours à trouver une solution simple pour la gestion de mon agenda et surtout que ce soit synchronisable avec mon téléphone !







Copain <img data-src=" />







wanou2 a écrit :



Je t’aime toi <img data-src=" />







J’ai mon domaine perso et les offres pour un usage basique (1 cpte mail + 1 agenda) en exchange ne sont pas données (3,30 chez ms chez les européens 1&1 : 7€ et ovh 4€) alors que chez Online j’en ai pour 1,2€







J’ai pas compris. Quand tu dis Online ? C’est Online.net ? C’est ou ?



Je pense que beaucoup de gens comprennent mal comment Google veut faire fonctionner ça. Tout va se passe dans le navigateur lui-même. La FAQ précise bien que les clés sont uniquement gardées localement et qu’elle ne seront pas expédiées vers les servers de Google.



Donc les clés vont se trouver dans la RAM de nos ordis pour que le code javascript puisse les utiliser mais Google n’y aura pas accès directement. reste encore à voir comment ça se passe dans le détail mais, pour l’instant et théoriquement, les clés restent en local.








atomusk a écrit :



(…)











KP2 a écrit :



(…)







Oui, merci à vous deux <img data-src=" />

J’étais largement à côté de la plaque.









KP2 a écrit :



Je crois que owncloud gere toutes ces problematiques… y’a juste a ajouter un serveur imap et c’est bueno, non ?







J’utilise OwnCloud sur mon serveur perso, ça fait CardDAV/CalDAV, note, hébergement de fichier, … et c’est aussi accessible via une interface web.









KP2 a écrit :



La clé doit necessairement etre en clair a un moment ou a un autre pour etre utilisee.









Oui mais rien n’oblige Google a les avoir pour faire transiter les mails chiffrés. Les clés doivent forcément être dispo sur l’ordi de l’émetteur et du receveur pour que les mails soient chiffrés/déchiffrés mais tout peut très bien se passer dans le navigateur lui-même cad avant l’envoi et après la réception.









Glyphe a écrit :



Je pense que beaucoup de gens comprennent mal comment Google veut faire fonctionner ça. Tout va se passe dans le navigateur lui-même. La FAQ précise bien que les clés sont uniquement gardées localement et qu’elle ne seront pas expédiées vers les servers de Google.



Donc les clés vont se trouver dans la RAM de nos ordis pour que le code javascript puisse les utiliser mais Google n’y aura pas accès directement. reste encore à voir comment ça se passe dans le détail mais, pour l’instant et théoriquement, les clés restent en local.





Comme avec toutes les précédentes extensions du genre. Tout le souci étant : quid de la sécurité du stockage de la clef en local dans le nav, quid de la confiance en Google vu que on est dans un environnement Chrome / Gmail / Implémentation Google de GnuPG, etc.



Je ne dis pas qu’il y aura un abus, juste qu’il y a possibilité de, et donc manque de confiance à la base. Du coup, ça part mal pour une solution pensée pour assurer la sécurité des échanges. Déjà que laisser des clefs se trimbaler sur une ou plusieurs machine(s) certains trouvent ça tendu (sans doute à raison) alors les confier à un navigateur…









Tornado_OLO a écrit :



Cela soulève une autre question.

On sait que Google fait son beurre en lisant les mails de ses clients. Comment compte-t-il faire s’il sont chiffrés ?

J’ai du mal à croire qu’ils tuent la poule aux oeufs d’or.





Peut-être simplement parce que la poule aux oeufs d’or de c’est pas spécialement les mails échangés avec Tati Danièle mais les mailing list auxquelles tu es inscris.

Et qui ne seront dans leurs grandes majorités JAMAIS chiffrées <img data-src=" />









David_L a écrit :



Je ne dis pas qu’il y aura un abus, juste qu’il y a possibilité de, et donc manque de confiance à la base. Du coup, ça part mal pour une solution pensée pour assurer la sécurité des échanges. Déjà que laisser des clefs se trimbaler sur une ou plusieurs machine(s) certains trouvent ça tendu (sans doute à raison) alors les confier à un navigateur…





Comme tu l’as si bien dit, la sécurité a un impact sur la facilité. Pour éviter de stocker sur un PC tu peux stocker ta clé privée sur une clé usb chiffrée également (en fait 2 pour éviter la perte de la première…)

En plus, il ne faut pas oublier que si on perd sa clé privée on est un peu dans la panade…

Donc même si Google fait cela dans les règles de l’art, seuls 3 à 4 % des utilisateurs vont réellement le faire correctement… pour les autres il y aura leurs clés privées dans Google drive… <img data-src=" />





Depuis quelques années, GnuPG (ou GPG) existe, aussi bien sous Linux que sous Windows par exemple, via GPG4Win.

Pour info, sur OSX c’est GPGTools (open-source) qui permet l’install. via un package unique. Je l’utilise avec Enigmail dans TB pour une adresse sur 8 mais effectivement, ça se passe pas comme une lettre à la “poste” quoi ;)








David_L a écrit :



Comme avec toutes les précédentes extensions du genre. Tout le souci étant : quid de la sécurité du stockage de la clef en local dans le nav, quid de la confiance en Google vu que on est dans un environnement Chrome / Gmail / Implémentation Google de GnuPG, etc.



Je ne dis pas qu’il y aura un abus, juste qu’il y a possibilité de, et donc manque de confiance à la base. Du coup, ça part mal pour une solution pensée pour assurer la sécurité des échanges. Déjà que laisser des clefs se trimbaler sur une ou plusieurs machine(s) certains trouvent ça tendu (sans doute à raison) alors les confier à un navigateur…







Totalement d’accord avec toi sur les nombreuses questions qui restent en suspens !

Mais je voulais surtout recentrer le débat qui partait un peu en couilles à propos des clés transmises à Google.



De toute évidence, ça ne restera qu’un outil de sécurité destiné au grand publique, avec de nombreux problèmes de sécurité inhérent à la simplification du concept et des pratiques pour le rendre utilisable par le plus grand nombre. (Si c’est là réellement le but … )



Dans tout les cas si on veut une email sécure et chiffré on ne passe pas par Gmail <img data-src=" /><img data-src=" />


C’est du pipo.



L’implémentation SSL/TLS a une version affaiblie d’AES (14 rondes), sois-disant pour des raisons de perfs.

Si tu sais pas ça, t’as raté ta vie d’expert en sécurité …



Et puis ils ont surement une master key, comme ça c’est encore plus simple …








Zimt a écrit :



C’est du pipo.



L’implémentation SSL/TLS a une version affaiblie d’AES (14 rondes), sois-disant pour des raisons de perfs.

Si tu sais pas ça, t’as raté ta vie d’expert en sécurité …



Et puis ils ont surement une master key, comme ça c’est encore plus simple …







Et vu que l’extention open source est en licence Apache, libre à toi de faire ta version avec sécurité max, et où tu insère ta propre clé <img data-src=" />



On verra bien quand la version finale de l’extention arrivera … <img data-src=" />









misterB a écrit :



Dans tout les cas si on veut une email sécure et chiffré on ne passe pas par Gmail un webmail<img data-src=" /><img data-src=" />







<img data-src=" /> <img data-src=" />









atomusk a écrit :



<img data-src=" /> <img data-src=" />





Tu crois ?

Pourtant j’ai tellement souvent entendu de la part de commerciaux : “C’est en HTTPS, c’est sécurisé.”

<img data-src=" />









Zimt a écrit :



Tu crois ?

Pourtant j’ai tellement souvent entendu de la part de commerciaux : “C’est en HTTPS, c’est sécurisé.”

<img data-src=" />







tout dépend de ce que tu entends par “sécurisé” … Https, c’est indispensable niveau sécurité contre le mec qui snif les communications, et ça donne un certain niveau de sécurité … (bon ça empeche pas des boites de faire du man in the middle avec des certifs auto signés … pas de souci sous IE préinstallé, gros warning rouge sous firefox & Chrome dans un boite où je suis allé <img data-src=" /><img data-src=" />).



Mais si tu parles sécurité par rapport à la justice, aux gouvernements & co …



Monte ta propre solution de mail hosté, avec chiffrage dans tous les sens <img data-src=" />



Mais là c’est la sécurité de tes données qui est en danger <img data-src=" />









David_L a écrit :



Comme avec toutes les précédentes extensions du genre. Tout le souci étant : quid de la sécurité du stockage de la clef en local dans le nav, quid de la confiance en Google vu que on est dans un environnement Chrome / Gmail / Implémentation Google de GnuPG, etc.



Je ne dis pas qu’il y aura un abus, juste qu’il y a possibilité de, et donc manque de confiance à la base. Du coup, ça part mal pour une solution pensée pour assurer la sécurité des échanges. Déjà que laisser des clefs se trimbaler sur une ou plusieurs machine(s) certains trouvent ça tendu (sans doute à raison) alors les confier à un navigateur…







Sincèrement, je trouve ca assez moche de jeter le doute sur Google comme tu le fais alors que leur solution est de loin la meilleure que l’on puisse avoir:



Le plugin marchera sans nul doute sur Chromium et le plugin est lui même libre, on peut raisonnablement se dire qu’il n’y aura pas d’espions à l’interieur car tout le code source est libre. Ensuite que le mail transite par Gmail et que ce soit l’implémentation de Google ne change rien a l’affaire: le protocole PGP est censé etre secure de ce point de vue. Et c’est d’ailleurs le role des experts de confirmer que l’implémentation n’est pas foireuse.



Bref, c’est dommage, l’article tombe dans le bashing anti-Google primaire alors que leur solution est très intéressante car elle permettrait de démocratiser enfin PGP.









flagos_ a écrit :



, on peut raisonnablement se dire qu’il n’y aura pas d’espions à l’interieur car tout le code source est libre.





Non…

Libre ou pas si personne de compétent ne fait un audit en profondeur du code tu ne peux être certain de rien.

(Heartbleed aurait pourtant du marquer les esprits)









jice68 a écrit :



Non…

Libre ou pas si personne de compétent ne fait un audit en profondeur du code tu ne peux être certain de rien.

(Heartbleed aurait pourtant du marquer les esprits)







D’où l’interet de l’audit. Sincèrement, le code est libre et Google file de la thune pour faire un audit, que peut-on faire de mieux ?!?



Désolé mais je maintiens, l’article a été écrit sans prendre le moindre recul.









jice68 a écrit :



Non…

Libre ou pas si personne de compétent ne fait un audit en profondeur du code tu ne peux être certain de rien.

(Heartbleed aurait pourtant du marquer les esprits)







Heartbleed est une faille de sécurité, dans une fonction. Ici ce que tu prétend est qu’il y aura toute une partie de code qui enverra à Google les clés …



C’est pas le même genre de difficulté à detecter …



Et je rajoute que c’est suite à une vérification du code que la faille Heartbleed a été detectée … <img data-src=" />








atomusk a écrit :



Heartbleed est une faille de sécurité, dans une fonction. Ici ce que tu prétend est qu’il y aura toute une partie de code qui enverra à Google les clés …



C’est pas le même genre de difficulté à detecter …







Tout a fait. Heartbleed n’était pas intentionnel. Et encore une fois, la démarche de Google est bien plus interessante car Google met de la thune sur la table que les audits se fassent. Ils n’attendent pas que ca arrive tout seul.



C’est plus productif que les mecs d’OpenSSL qui n’ont pas forcément les moyens de payer cet audit.









flagos_ a écrit :



D’où l’interet de l’audit. Sincèrement, le code est libre et Google file de la thune pour faire un audit, que peut-on faire de mieux ?!?

Désolé mais je maintiens, l’article a été écrit sans prendre le moindre recul.





Pour ce projet oui tu as raison. <img data-src=" />

Mais c’est cette assertion systématique de certains quand on parle de code source libre qui me hérisse les poils.

Concernant l’article, je pense réellement qu’il n’y a pas anguille sous roche de la part de goole, mais connaissant la complexité de la gestion au quotidien des clés publiques de ses contacts, de sa clé privée (qui peut avoir une durée de vie…).

Ils savent pertinemment que cela ne va pas du tout nuire à leur business model et en même temps redorer un peu leur blason :)









atomusk a écrit :



Ici ce que tu prétend est qu’il y aura toute une partie de code qui enverra à Google les clés …

C’est pas le même genre de difficulté à detecter …





Je ne prétends rien (je me suis mal exprimé), au contraire je dis qu’un code libre non audité n’est pas plus sécurisé qu’une appli propriétaire.

Dans le cas ci-présent, google va faire auditer son code, nous serons donc face à qqch de sécurisé (en tout cas dans la version auditée)









Bio Teckna a écrit :



Copain <img data-src=" />







J’ai pas compris. Quand tu dis Online ? C’est Online.net ? C’est ou ?







online.net pour le mail et un mini blog et du coup je vais installer baikal server pour le mail.



Pour ce qui est de l’hebergement de fichier j’utilise le cloud d’orange tel quel.









Glyphe a écrit :



Oui mais rien n’oblige Google a les avoir pour faire transiter les mails chiffrés. Les clés doivent forcément être dispo sur l’ordi de l’émetteur et du receveur pour que les mails soient chiffrés/déchiffrés mais tout peut très bien se passer dans le navigateur lui-même cad avant l’envoi et après la réception.







Oui oui, tout a fait

Mais on etait parti un peu loin dans la discussion effectivement…







David_L a écrit :



Je ne dis pas qu’il y aura un abus, juste qu’il y a possibilité de, et donc manque de confiance à la base. Du coup, ça part mal pour une solution pensée pour assurer la sécurité des échanges. Déjà que laisser des clefs se trimbaler sur une ou plusieurs machine(s) certains trouvent ça tendu (sans doute à raison) alors les confier à un navigateur…







Le plus gros probleme des communications chiffrees ne sont meme pas la… ils se trouvent dans la gestion des clés elles memes.



Comment genere t on sa paire de clés ?




  • via le plugin gmail ? ayez confiaaaaaance…

  • via une solution tiers ? complexe pour les lambdas



    Comment conserve t on sa paire de clés ?

  • vraie procedure de backup

  • qu’est ce qu’on fait quand on perd ses cles ?



    Comment gerer le renouvellement de sa paire de clé ?

  • c’est encore plus chiant que changer de n° de mobile ou de boite mail



    Comment fait on l’echange de clés publiques ?

  • de la main a la main ? c’est quand meme pas genial

  • via un “repertoire” de clés publiques ? on retombe sur les problemes de confiance envers un tiers “unique” + comment etre sur que la clé repertoriee est valide ?

  • via un espace de stockage public decentralisé ? il va falloir inventer un protocole…



    Bref, ca fait longtemps que le chiffrement des mails existe mais ca n’a jamais depassé un tres petit cercle de personnes concernées specifiquement par le souci de la preservation du secret des communications.

    Et si ca n’a jamais vraiment depassé ce tres petit cercle (meme chez les geeks epais), c’est parce que c’est une plaie absolue a gerer tant pour les tech que pour les utilisateurs et que le jeu n’en vaut generalement pas la chandelle…











atomusk a écrit :



tout dépend de ce que tu entends par “sécurisé” … Https, c’est indispensable niveau sécurité contre le mec qui snif les communications, et ça donne un certain niveau de sécurité … (bon ça empeche pas des boites de faire du man in the middle avec des certifs auto signés … pas de souci sous IE préinstallé, gros warning rouge sous firefox & Chrome dans un boite où je suis allé <img data-src=" /><img data-src=" />).



Mais si tu parles sécurité par rapport à la justice, aux gouvernements & co …



Monte ta propre solution de mail hosté, avec chiffrage dans tous les sens <img data-src=" />



Mais là c’est la sécurité de tes données qui est en danger <img data-src=" />





Je voulais juste dire que les mecs vendent la couche de transport comme une sécurité de stockage …










Zimt a écrit :



Je voulais juste dire que les mecs vendent la couche de transport comme une sécurité de stockage …







Disons qu’il faut les 2 <img data-src=" />



Mailvelope

is a browser extension that enables the exchange of encrypted emails following the OpenPGP encryption standard.

Mailvelope 0.8.3

https://addons.mozilla.org/en-US/firefox/addon/mailvelope/

https://www.mailvelope.com/help




  • Gmail™

  • Yahoo!™

  • Outlook.com™

  • GMX™



    Je viens de l’installer sur Firefox c’est en version beta encore, dans Ecrire il y a bien une fenêtre à droite avec le verrou qui renvoit elle-même une autre fenêtre pour le chiffrement…le help a l’air explicite…à voir….








atomusk a écrit :



Disons qu’il faut les 2 <img data-src=" />



<img data-src=" />



[quote:5045364:wanou2]



Je t’aime toi <img data-src=" />



Envoie moi un MP si tu as des questions sur les détails.


Tiens c’est rigolo, Openmailbox.org vient de m’envoyer un mail comme quoi le GPG était pris en charge dans le webmail. Coïncidence ?



Et justement, même si cette annonce est de la poudre aux yeux concernant les données personnelles, peut être que au moins Google va “lancer le mouvement”, ça ne m’étonnerai pas que d’ici quelques semaines Yahoo! fasse une annonce identique. Et à force, ça permettrai démocratiser ce genre d’outils de chiffrement, ils sont plutôt fort pour faire bouger les choses chez Google, on l’a déjà souvent vu (navigateurs, webmail…).








san-claudio a écrit :



Mailvelope

is a browser extension that enables the exchange of encrypted emails following the OpenPGP encryption standard.

Mailvelope 0.8.3

https://addons.mozilla.org/en-US/firefox/addon/mailvelope/

https://www.mailvelope.com/help




  • Gmail™

  • Yahoo!™

  • Outlook.com™

  • GMX™



    Je viens de l’installer sur Firefox c’est en version beta encore, dans Ecrire il y a bien une fenêtre à droite avec le verrou qui renvoit elle-même une autre fenêtre pour le chiffrement…le help a l’air explicite…à voir….





    Je plussoie <img data-src=" />



    Mailveloppe est bien foutu, je l’utilise avec gmail et ergonomiquement c’est réussi !









san-claudio a écrit :



Mailvelope

is a browser extension that enables the exchange of encrypted emails following the OpenPGP encryption standard.

Mailvelope 0.8.3

https://addons.mozilla.org/en-US/firefox/addon/mailvelope/

https://www.mailvelope.com/help




  • Gmail™

  • Yahoo!™

  • Outlook.com™

  • GMX™



    Je viens de l’installer sur Firefox c’est en version beta encore, dans Ecrire il y a bien une fenêtre à droite avec le verrou qui renvoit elle-même une autre fenêtre pour le chiffrement…le help a l’air explicite…à voir….







    Enigmail avec Gnupg pour Thuderbird, sinon.









supercolino a écrit :



[quote:5045364:wanou2]



Je t’aime toi <img data-src=" />



Envoie moi un MP si tu as des questions sur les détails.







Installation super facile

Paramétrage simple

Le logiciel pour la synchro des contacts nickel

Je cherche quelque chose pour le calendrier (caldav) je pense que je vais devoir aller sur du payant



Sinon 1010 !!!









wanou2 a écrit :



Installation super facile

Paramétrage simple

Le logiciel pour la synchro des contacts nickel

Je cherche quelque chose pour le calendrier (caldav) je pense que je vais devoir aller sur du payant



Sinon 1010 !!!







Comment ça du payant ?



Baikal est aussi un serveur CalDAV.

Le plugin Lighting pour Thunderbird gère très bien CalDAV.

Pour Android, j’ai vu qu’une appli gère à la fois CardDAV et CalDAV, c’est DAVdroid. Je vais tester (jusqu’à maintenant j’utilisais CardDAV-Sync beta). Effectivement, toutes les applis semblent être payantes.



Content que ça t’aie sevi :) Pour ma part j’aime vraiment gérer mails/contact/calendrier sur Thunderbird.