End-To-End : le pour, le contre et le truandage

Par SwissTengu @SwissTengu @SwissTengu — 10.06.2014
/static/images/EndToEnd-Icon.png
Google a créé le buzz ces derniers temps avec son plugin Chrome End-To-End1, permettant de chiffrer les mails dans leur interface webmail, en implémentant OpenPGP2 en javascript.
Rien que ça. Idée intéressante, "trendy" vu les révélations de Snowden et la poursuite de la collecte des données personnelles sous toutes ses formes.

Seulement, il convient de se poser quelques questions :
  • Quand on sait que la crypto dans javascript est pourrie, que penser de cette annonce ?
  • Quand on sait que la génération de nombres aléatoires en javascript est une plaie, que penser des clefs générées par ce biais ?
  • Quelle confiance peut-on avoir dans le navigateur conservant les clefs privées ?
  • Quand on sait que Google compte sur le contenu de vos emails pour « mieux vous connaître », « vous proposer les bonnes publicités », « améliorer votre expérience », que pouvons-nous penser de cette extension ?
  • Comment gérer l'utilisation de plusieurs appareils ? Après tout, la clef privée est dans votre instance Chrome sur votre laptop, comment faire pour employer ça sur votre desktop ?

On va tâcher de répondre à ces questions de manière précise. Ça risque de partir dans la technique, mais on va faire en sorte de rendre ces parties facultatives :).

/static/images/js-crypto.jpg
Javascript et la cryptographie : amour impossible ?
Le problème principal est le passif de Javascript : pas mal de personnes se sont cassées les dents en tentant de reproduire des algorithmes de chiffrement, qui se sont révélés vulnérables à différentes attaques3.

Aussi, il y a le problème de la transmission du code au navigateur, la connexion au serveur pouvant être compromise de multiples manières. À priori, ce problème précis n'existe pas avec l'extension End-To-End, puisque tout est embarqué dans le navigateur (si tant est que le téléchargement et l'installation de l'extension ne sont pas compromis ;) ).

Le principal problème avec End-To-End est le fait que les développeurs semblent avoir créé une nouvelle implémentation — il ne semblait pas exister de librairies répondant à leurs besoins au moment où ils ont démarré le projet.
Il faudra donc attendre un certain temps avant de pouvoir faire confiance dans cette nouvelle librairie (et je ne parle que de la librairie, pas de son utilisation), de manière à laisser le temps aux différentes communautés pour valider les implémentations, auditer le code correctement, etc.

À ce niveau, on peut saluer la transparence des développeurs qui mentionnent clairement, dès le départ, que ce projet est en version « alpha » et n'est pas encore utilisable dans l'état.
Donner plus de précisions quant aux raisons aurait été sympa, mais je pinaille un peu sur ce point.

Après, on peut aussi se pencher sur les problèmes de V8, le moteur javascript de Chrome : https://code.google.com/p/v8/issues/list — je vous laisse apprécier les quelques perles qui s'y trouvent.

/static/images/random4.jpg
Javascript, l'aléatoire made-in Debian
Le fameux Math.random()4 retourne une valeur comprise entre [0, 1) (0 inclus, 1 exclu). Le problème principal est que la valeur retournée est basée sur le temps, et peut donc être retrouvée de manière assez simple.
Il ne s'agit donc pas d'un « vrai » nombre aléatoire, tout au plus d'une dérivation et de quelques manipulations5.
Et voir que la librairie en question fait appel à ça me semble un peu… vaseux. On peut donc se poser quelques questions quant à la solidité des clefs générées, le générateur aléatoire étant une des causes principales de faiblesse…

Après, Google semble avoir créé un « truc » qui génère des nombres aléatoires, mais j'avoue que mes compétences pour valider leur procédé sont très limitées (voire absentes)…
Mais employer sha1 est une mauvaise idée6.
Sans parler du fait que SHA1 a été démontré comme « peu sûr », des attaques (théoriques) ayant été démontrées7.

L'extension tente en premier d'employer le générateur natif, mais là encore, il est possible que ce ne soit pas gagné8

On peut donc raisonnablement douter de la solidité et de l'unicité des clefs produites — de là, il est tout autant raisonnable de douter de la sécurité offerte par cette extension.

Le navigateur, coffre-fort des clefs privées ?
C'est l'une des deux choses qui me dérangent le plus : le fait que les clefs privées soient conservées dans le navigateur.
Quelle confiance peut-on avoir, réellement, dans cette application exécutant une multitude de codes divers et (a)variés, dont vous ne maîtrisez même pas la source ?
À ce niveau, les dévs font preuve de transparence et annoncent la couleur : les clefs se trouvant dans le LocalStorage9 ne sont pas protégés contre les accès — leur seule protection est le fait qu'elles soient chiffrées, donc « protégées par un mot de passe »…
Les clefs « en cours d'utilisation », donc déchiffrées et chargées en mémoire, sont protégées par le sandboxing (cloisonnement) des processus au sein de Chrome — là encore, rien n'assure à 100 % que rien ni personne n'arrivera à exploiter une faille quelconque.
Même que c'est précisé : si on active l'envoi automatique des rapports de bugs, il est possible que des bouts de mémoire contenant des éléments de la clef privée soient envoyés lors d'un crash…

On ne peut que se baser sur la confiance qu'on a pour ces développeurs et Google en général. 0, pour moi.

Et le business-model de Google, dans tout ça ?
Bah oui, n'oublions pas comment Google finance le fait de vous fournir un webmail avec 10'000 fonctionnalités, un antispam de qualité, etc : les publicités contextuelles10 !
/static/images/gmail-ads.jpg

Comment comptent-ils faire si tout le monde chiffre ses mails ? Ils ne peuvent, selon leurs propres dires, pas accéder à votre clef privée et donc, logiquement, il leur est impossible de déchiffrer vos correspondances de manière à vous envoyer des publicités ciblées !

De là, plusieurs possibilités :
  • Google se tire une balle dans le pieds (on y croit)
  • Google a laissé une porte ouverte dans son extension pour accéder aux contenus (pratique pour la NSA)
  • Google compte sur le fait que peu de monde utilisera son extension, tout en se rachetant une image un peu moins « evil »

Pour ma part, j'hésite entre la seconde et la troisième, avec un penchant pour cette dernière — la seconde serait possible si et seulement si le code n'était pas ouvert. On peut compter sur les communautés pour se poser les mêmes questions et auditer de manière stricte cette extension.

Bon, j'ai craqué, je l'utilise. Mais j'ai deux ordis…
Pas de miracle, il vous faudra exporter d'un côté, importer de l'autre. Et, évidemment, il sera fortement déconseillé de s'envoyer son keyring par mail.
Clef USB (voire disquettes selon qui vous conseille), volumes chiffrés, etc seront de mise pour un transfert en toute sécurité.
Pas grand chose d'autre à dire sur ce sujet, au final.

Autres considérations
Vouloir pousser les gens à employer des outils cryptographiques est bien. Vouloir simplifier l'utilisation de ces outils est encore mieux. Mais fournir un bout de code douteux, même avec des avertissements, n'est pas une bonne chose :

Il convient de ne pas se précipiter sur cet outil. Pour les multiples raisons invoquées précédemment. Pour d'autres raisons, aussi : après tout, on parle de Google. Google, l'entité qui vous traque où que vous alliez, quelque soit votre appareil, quelque soient vos intentions.
Leurs innovations sont certes intéressantes, mais il s'agit avant tout d'une société privée, ayant des budgets à tenir, des actionnaires à contenter, des retours sur investissements à générer.

Il faudra surtout attendre que des personnes externes à Google se penchent sur le code, sur les implémentations des concepts cryptographiques, etc. Ce n'est pas simple. Cela demande de solides connaissances en mathématiques et en programmation — le fait que ce soit en Javascript ne va pas non plus aider, à mon avis.

Il faut aussi garder en tête que l'extension, dans son état actuel, ne chiffre pas les pièces jointes. Il vous faudra donc les chiffrer à part. Seul le contenu du mail sera chiffré — les données annexes telles que le sujet, les destinataires seront en clair.

Et, à priori, End-to-End ne semble pas prévu pour un autre webmail que celui de Google, ce qui pose 2-3 problèmes annexes ;).

Pourquoi truandage ?
Le mot est peut-être un peu fort. Mais considérons les points suivants tels qu'abordés dans ce billet :
  • Google a besoin de vos contenus pour augmenter les chances que vous cliquiez sur une publicité
  • Google est soumis au Patriot Act, loi le forçant à s'assurer que les autorités US ont accès à vos informations et correspondances
  • Les dirigeants de Google ne sont pas réputés pour valoriser la protection des données personnelles11

Bref. Tout cela me fait penser à une jolie arnaque dont les utilisateurs finaux feront, une fois de plus, les frais.

Pour ma part, je reste avec mon Icedove et Enigmail…


Commentaires (4)

par Mayeu — 11.06.2014, 11:59 — PermaLink

De là, plusieurs possibilités :
* Google se tire une balle dans le pieds (on y croit)
* Google a laissé une porte ouverte dans son extension pour accéder aux contenus (pratique pour la NSA)
* Google compte sur le fait que peu de monde utilisera son extension, tout en se rachetant une image un peu moins « evil »


Je pense qu'il manque l'évidence ici, personnelement je ne crois en aucunes de ces solutions. Se tirer une balle dans le pied est évidemment impossible, mettre une backdoor serait pire que de se tirer une balle dans le pied. Compter que personne ne l'utilise serait peut-être le plus probable.

Mais surtout tout à lieu dans le browser. Google a accès à l'e-mail en train d'être écrit et sa version final juste avant chiffrement, et il aura aussi accès à l'e-mail après déchiffrement. La seule chose qui change dans son business model ? Il n'a accès au contenu du message qu'une fois celui ci ouvert par l'utilisateur :) En gros, ça protège d'écoute exterieur, mais pas de Google lui même => Image racheté, business model sauvé. Win-win. Alors que si les clients externes avec GPG se propagent avant leur extension leurs business model devient moins interessant.

Ça me parait le plus problable !
par SwissTengu — 11.06.2014, 12:03 — PermaLink
Ouep, j'y ai aussi pensé, mais de ce que j'ai vu, le mail est écrit dans l'extension directement, i.e. il "dessine" une nouvelle interface. Il faudrait donc que le JS envoie le contenu en sous-main aux serveurs de Google, ce qui sera visible dans le code (encore que pas mal de trucs sont internes à Chrome, pour ce que j'en ai vu)…

Mais ce que tu décris rejoint la second proposition, au final : l'extension laisse un truc pour que le contenu soit accédé (ou envoyé).
Après, j'ai aussi vu mentionné que le service gmail pourrait devenir payant si on veut employer end-to-end, parce que justement ça casse le business de Google…

M'enfin, faut déjà que l'extension sorte en stable, pour le moment c'est du pré-alpha…

T.
par Mayeu — 11.06.2014, 12:29 — PermaLink

Ouep, j'y ai aussi pensé, mais de ce que j'ai vu, le mail est écrit dans l'extension directement, i.e. il "dessine" une nouvelle interface. Il faudrait donc que le JS envoie le contenu en sous-main aux serveurs de Google, ce qui sera visible dans le code (encore que pas mal de trucs sont internes à Chrome, pour ce que j'en ai vu)…


Ok je n'avais pas vu ça.


Mais ce que tu décris rejoint la second proposition, au final : l'extension laisse un truc pour que le contenu soit accédé (ou envoyé).
Après, j'ai aussi vu mentionné que le service gmail pourrait devenir payant si on veut employer end-to-end, parce que justement ça casse le business de Google…


Je voyais la backdoor comme technique. Le cas du draft sauvé sur le serveur non chiffré est un classique avec GPG où il faut toujours configurer le client pour ne pas sauver les drafts ! Du coup pour moi je voyais vraiment l'interface web comme un client, qui fait ce qu'il fait d'habitude. Et End-to-End comme enigmail, qui s'intégre tant bien que mal dans un client non pensé pour cet usage.

Le fait de devenir payant serait une solution interessante, mais bon dans ce cas autant avant un compte gratuit et tout chiffrer depuis un client desktop ^^
par SwissTengu — 11.06.2014, 12:40 — PermaLink
Y a aussi le fait que l'indexation des mails ne devrait plus tant marcher… Du coup, quel intérêt d'employer gmail ? C'est un peu "LE" point fort de ce webmail : la recherche très pointue…
Si les mails sont chiffrés, logiquement, y a plus d'indexation :].

Bref, beaucoup de questions sont encore ouvertes, et toutes pointent le même problème : allier protection des données et utilisation de services de pointe.
Ajouter un commentaire