Carnet de notes

Catégorie : Sécurité informatique

  • Les petits utili­taires : 1– Le gestion­naire de mots de passe

    Il y a toute une série de petits utili­taires indis­pen­sables avec lesquels je ne suis pas satis­fait. Je me dis qu’en mettant ici mon usage, peut-être que ça ouvrira des portes.

    Bref, j’ai­me­rais un logi­ciel pour gérer mes mots de passe et les stocker de façon sécu­ri­sée.

    • Je veux y avoir accès aussi bien sur Mac, que sur Linux et sur mon mobile Android, y compris hors-ligne. Ce serait top s’il y avait un client web mais ce n’est pas indis­pen­sable.
    • Le stockage et l’ac­cès doivent être sécu­ri­sées. Rien ne doit être acces­sible sans mot de passe maître, et ce dernier ne doit être stocké nul part.
    • L’app mobile doit pouvoir avoir un verrouillage soft (via un pin, un schéma ou une empreinte digi­tale) quand le télé­phone passe en veille (ou à défaut quand je bascule sur une autre app).
    • Tous les clients (app mobile, desk­top, navi­ga­teur) doivent de rever­rouiller au bout d’un certain temps d’ac­ti­vité et néces­si­ter la saisie du mot de passe maître pour être réou­verts.
    • Je dois avoir une exten­sion du navi­ga­teur pour auto-complé­ter les formu­laires de login, autant sur desk­top que sur mobile. Idéa­le­ment l’auto-complé­tion n’injecte pas plein de trucs auto­ma­tique­ment dans chaque page web et n’agit que sur ma demande via un bouton dans la barre d’ou­til.
    • La même exten­sion du navi­ga­teur doit savoir créer une entrée dans les mots de passe enre­gis­trés à partir d’un formu­laire de login sur une page web.
    • Il existe un moyen simple et rapide de faire une recherche dans la base de mots de passe.
    • L’ou­til embarque un géné­ra­teur de mots de passe.
    • Ça serait top de pouvoir parta­ger des mots de passe, en lecture et/ou en écri­ture, à une personne ou à un groupe.

    Parce que je suis geek :

    • Il existe un accès en ligne de commande ou un moyen de bidouiller l’en­semble
    • Il est possible de sauve­gar­der faci­le­ment et auto­ma­tique­ment ma base de mots de passe quelque part (que tout ne repose pas sur un pres­ta­taire)
    • Le fonc­tion­ne­ment (API, chif­fre­ment) est docu­menté, idéa­le­ment open source
    • Ça serait top que ça gère aussi direc­te­ment l’agent pour mes clefs SSH
    Dash­lane

    J’ai exploré par mal de choses. Pour l’ins­tant Dash­lane coche la plupart des cases mais l’ex­ten­sion navi­ga­teur me gêne. Il s’agit d’une coquille vide qui s’oc­cupe des auto-comple­tion et qui inter­agit avec l’ap­pli­ca­tion Dash­lane native sur le système.

    Je trou­vais le système assez smart mais en réalité non seule­ment je ne vois pas ce que ça m’ap­porte mais je vois même en quoi ça peut dimi­nuer légè­re­ment la sécu­rité.

    Dans tous les cas, l’injec­tion de scripts dans toutes les pages à formu­laire est fran­che­ment gênante. Fire­fox me signa­lait régu­liè­re­ment des ralen­tis­se­ment dû à Dash­lane mais en plus l’UX de gestion de l’auto-comple­tion me gêne plus souvent qu’elle me faci­lite la vie, surtout sur un petit écran mobile (sans comp­ter que sur mobile ça m’oblige à utili­ser Chrome plutôt que Fire­fox).

    Enfin, ça veut dire faire confiance. J’ai confiance dans la crypto de base mais quand j’ai posé des ques­tions sur les inter­ac­tions entre le navi­ga­teur et l’ap­pli­ca­tion native j’ai eu des demies réponses sans détails tech­niques. J’ai l’im­pres­sion que cette partie de l’ar­chi­tec­ture repose plutôt sur l’obs­cu­rité. Non seule­ment ça me gêne, mais je doute encore plus de voir arri­ver autre chose que ce que l’équipe a prévu et a le temps de faire.

    Bref, beau­coup de bons points mais j’ai peur que ça ne coche jamais les cases restantes.

    Enpass

    Ça couvre beau­coup moins de choses mais j’aime bien l’idée de fichiers qu’on peut synchro­ni­ser sans serveur via un disque en ligne quel­conque genre Drop­box ou Google Drive. Ça me permet aussi de gérer les sauve­gardes tout en me rassu­rant sur la péren­nité.

    Pass­bolt

    J’en ai encore moins de cases cochées mais là j’ai de l’open­source, donc quitte à bidouiller ça peut être que ça peut faire une base de départ ?

    Là où je suis étonné c’est de ne pas voir plus de projets open source que ça, et pas plus abou­tis. Le cœur logi­ciel est pour­tant assez faci­le­ment acces­sible pour deux ou trois dev moti­vés et le besoin est géné­ral au moins au niveau des geeks.

  • J’ai un problème (sécu­rité) avec Dash­lane – Vous m’ai­dez ?

    Je vous ai déjà parlé de Dash­lane. Fran­che­ment c’est le bonheur.

    Puis je suis tombé aujourd’­hui sur un échange à propos de faiblesses dans le code d’auto-comple­tion de Last­pass. Et là, même si le problème de Last­pass ne se retrouve pas sur Dash­lane j’ai eu un malai­se… « Merde, mes exten­sions Chrome et Fire­fox arrivent à tirer des mots de passe de Dash­lane un peu trop faci­le­ment »

    * * *

    Dash­lane a une app native très clas­sique. C’est elle qui a les mots de passe (chif­frés), que je déver­rouille avec mon mot de passe maître. À partir de la quelle je peux copier les iden­ti­fiants et mots de passe.

    De cette app native, j’ai pu instal­ler les exten­sions Chrome et Fire­fox. Je suppose que ça construit une exten­sion qui m’est spéci­fique, avec des jetons d’ac­cès qui sont diffé­rents chez chacun.

    Ces exten­sions peuvent libre­ment ajou­ter et récu­pé­rer les mots de passe depuis l’app native. Rien à faire, rien à déver­rouiller. Pour peu que l’app native soit ouverte, ça fonc­tionne.

    * * *

    Qu’est-ce qui m’em­pêche de créer un script ou une appli­ca­tion qui ouvre le profil Fire­fox sur le disque, y trouve les fichiers de l’ex­ten­sion Dash­lane, y lit les jetons d’ac­cès et s’adresse à l’app native Dash­lane en cours d’exé­cu­tion pour en extraire tous les mots de passe ?

    Ok, il faudrait que mon script ait accès à mon disque dur, ce qui est en soi un problème, mais si j’uti­lise Dash­lane ce n’est pas pour que n’im­porte quelle appli­ca­tion qui a accès à mon disque puisse accé­der à mes mots de passe en clair aussi faci­le­ment.

    En réalité c’est proba­ble­ment plus complexe. Un petit tour dans les fichiers javas­cript de Dash­lane me fait dire qu’il y a du chif­fre­ment en jeu et qu’il faudrait quelques jours de boulot pour réuti­li­ser le même canal de commu­ni­ca­tion. Rien d’im­pos­sible cepen­dant.

    En fait je peux même proba­ble­ment récu­pé­rer tout le fichier Javas­cript et l’uti­li­ser en tapant direc­te­ment dans l’API interne plutôt que de mimer ce qu’elle sait faire.

    Tout au plus il y a peut-être un système qui iden­ti­fie le nom de l’ap­pli­ca­tion source qui s’adresse à l’app native Dash­lane. Je doute que ça aussi soit incon­tour­nable.

    * * *

    Bref, c’est moi où j’ai un gros problème avec Dash­lane ? Si un techos de Dash­lane passe par là, sans forcé­ment révé­ler tous les méca­nismes dans le détail, j’ai­me­rais bien savoir pourquoi je peux faire confiance au système mis en place.

  • Logi­ciel de mot de passe

    Ça faisait long­temps que je voulais passer à un gestion­naire de mot de passe un peu évolué.

    J’ai tenté par deux fois de me mettre à Last­pass. Je ne saurais dire pourquoi mais les deux fois j’ai fini par peu l’uti­li­ser, le lais­ser dans un coin et reve­nir à mes habi­tudes.

    Depuis peu de temps j’ai tenté avec Dash­lane. Il n’y a pas de client Linux, l’in­ter­face web et en lecture seule mais son gros avan­tage est de pouvoir fonc­tion­ner tota­le­ment offline. Mieux : C’est une entre­prise française. Même si le chif­fre­ment fait que mes données sont théo­rique­ment illi­sibles par le pres­ta­taire, j’ai un peu plus confiance que dans une société US.

    Peut-être est-ce l’er­go­no­mie mais cette fois la sauce a pris. J’ap­pré­cie le login auto­ma­tique sur le navi­ga­teur. J’aime le fonc­tion­ne­ment de l’app mobile qui se contente de l’em­preinte digi­tale si l’app a déjà été déver­rouillée récem­ment par le mot de passe maître.

    Pour le même prix il m’a signalé les sites où mon mot de passe était trop faible ou obso­lète (genre le mot de passe Yahoo qui n’a pas changé depuis les failles) et a su le chan­ger d’un simple bouton sans me deman­der d’al­ler faire les mani­pu­la­tions moi-même sur les diffé­rents sites.

    Il me reste la fonc­tion­na­lité de partage que je n’ai pas testée mais j’ai bon espoir que ça résolve nos diffi­cul­tés de comptes commun avec ma femme.

    Enfin la bonne surprise c’est le mode urgence : Permettre à un tiers iden­ti­fié de récu­pé­rer ma base de mots de passe si je ne décline pas sa requête après un certain nombre de jours. Quelque part ça peut faire office de testa­ment numé­rique, même si ça n’est pas parfait.

    Depuis on m’a pointé vers le récent Enpass, qui ne demande que 10 € pour l’achat à vie de l’app mobile (contre 40 € par an pour le premium Dash­lane). Il a le support Linux, le offline, sa synchro­ni­sa­tion se fait par des pres­ta­taires de cloud habi­tuels, mais il n’y a pour l’ins­tant pas de partage possible. Ça vaut peut-être le coup de commen­cer par Enpass si vous n’avez pas besoin de cette dernière fonc­tion­na­lité.

  • Empreinte digi­tale et sécu­rité

    Nouveau télé­phone avec un capteur d’em­preinte digi­tale. Il n’y a pas à dire, c’est super pratique et le compro­mis de sécu­rité est plutôt bien adapté au cas d’usage.

    Compro­mis ? C’est évident pour les geeks sécu­rité alors je m’adresse aux autres. Tout est histoire de compro­mis entre la faci­lité d’uti­li­sa­tion et le niveau de sécu­rité recher­ché.

    L’em­preinte digi­tale est facile à utili­ser mais assure un assez mauvais niveau de sécu­rité.

    Security - xkcd 358
    Secu­rity – xkcd 538

    Donc, qu’est prêt à faire celui qui veut accé­der à vos données ?

    Si vous ne vous cachez pas sérieu­se­ment à chaque fois que vous déver­rouillez votre télé­phone, le code PIN ou le schéma à la Android ne sécu­risent que contre le vol à l’ar­ra­chée, quand le voleur ne vous connait pas et ne peut rien obte­nir de vous.

    Si votre voleur est prêt à fouiller votre télé­phone sans votre accord, il est certai­ne­ment prêt à loucher par dessus votre épaule pour voir votre PIN ou votre schéma quand vous le tracez. Pour un schéma il peut même parfois se conten­ter des traces de doigts sur l’écran pour peu que vous ayez oublié de les effa­cer.

    C’est *là* que l’em­preinte digi­tale est inté­res­sante. Elle est est simple à utili­ser mais ne peut pas être repro­duite sans un mini­mum d’ef­forts.

    * * *

    Si par contre votre attaquant est prêt à être… méchant, alors l’em­preinte digi­tale est la pire des solu­tions.

    Le plus simple : Même un grin­ga­let peut vous prendre par surprise et retour­ner votre poignet dans votre dos pour vous faire déver­rouiller le télé­phone par la contrainte.

    Le plus discret : Récu­pé­rer une de vos empreintes quelque part où vous la lais­sez – c’est à dire partout, tout au long de la jour­née – et créer une fausse empreinte propre à leur­rer le capteur permis­sif du télé­phone. N’im­porte qui en est capable avec assez de volonté.

    Contre quelqu’un prêt à faire un mini­mum d’ef­forts il ne reste qu’un mot de passe ou un schéma suffi­sam­ment complexe que vous gardez confi­den­tiel. Rien ne battra même un bête code PIN si l’ap­pa­reil limite le nombre de tenta­tives.

    Le problème c’est que tour­ner le dos à vos proches à chaque déver­rouillage de télé­phone puis s’as­su­rer de ne pas lais­ser de traces sur l’écran, ce n’est pas neutre au jour le jour. Bien entendu, si vous allez dans cette direc­tion, il faut que le disque du télé­phone soit chif­fré, que le télé­phone se verrouille immé­dia­te­ment quand vous le lais­sez sur une table, et que l’éven­tuel schéma à tracer soit très complexe. Sinon autant reve­nir à l’em­preinte digi­tale.

     

  • Que se passe-t-il le jour où je ne suis plus là ?

    Je peux passer sous un bus et me retrou­ver soit sur un lit d’hô­pi­tal soit dans une boite en chêne. Que se passe-t-il le jour où je ne suis plus là ?

    Les données infor­ma­tiques ne sont pas forcé­ment les premières choses auxquelles mes proches pense­ront mais j’ai la désa­gréable habi­tude de chif­frer les disques et avoir de vrais mots de passe. Pire : je suis l’in­for­ma­ti­cien de la maison et donc le seul à déte­nir certaines clefs.

    Photos, docu­ments, tout ceci risque d’être perdu si le NAS arrête de fonc­tion­ner. Les fichiers qui peuvent trai­ner sur un Google Drive ou un Drop­box ont eux un compte à rebours. Il y a des vraies données qu’il faut faire vivre plus long­temps que moi.

    Livres, textes, codes sources, qu’est-ce que ceux qui restent vont faire de ça ? Sauront-ils même les iden­ti­fier et quelles sont les possi­bi­li­tés ?

    Pour le reste – blog, réseaux sociaux, noms de domaine – je ne sais pas bien quel sens ça a mais je n’ai pas envie de lais­ser un parcours du combat­tant pour que mes survi­vants les éteignent ou les archivent s’ils le souhaitent.

    * * *

    J’ai beau­coup de ques­tions, peu de réponses. Je peux faire un docu­ment qui explique des choses. Le plus compliqué va être qu’il survive et puisse être trouvé faci­le­ment. Le papier peut brûler s’il y a vrai­ment un acci­dent grave, plus proba­ble­ment il sera perdu avant 20 ans. L’in­for­ma­tique n’est guère mieux : j’ai des sauve­gardes mais qui saura y avoir accès sans moi ? qui saura les exploi­ter et retrou­ver l’in­for­ma­tion ?

    Même avec ce docu­ment, est-ce suffi­sant pour qu’un non-infor­ma­ti­cien se débrouille ? Je n’ai de toutes façons pas envie que ma famille fasse de l’ar­chéo­lo­gie infor­ma­tique.

    Aujourd’­hui je demande à deux proches en qui j’ai toute confiance s’ils peuvent prendre cette lourde charge : trans­mettre et porter assis­tance sur ces ques­tions le jour où je ne le pour­rai pas. Je ne sais pas comment ça tien­dra 50 ans, quelle forme ça pourra prendre.

    * * *

    Il restera de toutes façons le point central : les clefs, les mots de passe, les iden­ti­fiants. Je ne peux pas lais­ser un docu­ment avec tout ça, ni sous forme de papier ni sous forme infor­ma­tique, ni chez moi ni chez d’autres.

    Il y a la ques­tion de sécu­rité et de confi­den­tia­lité tant que je suis encore là, mais aussi que les mots de passe vivent. Comment mettrai-je à jour systé­ma­tique­ment ce docu­ment tout en gardant sa confi­den­tia­lité et sans peser sur les deux proches qui accep­te­ront d’être mes relais ?

    On me propose des fichiers chif­frés à poser d’un côté et la clef ou le mot de passe à poser de l’autre. Je ne sais pas quelle péren­nité j’ai côté humain. Je crains aussi la tech­nique : Quel est le risque que le chif­fre­ment soit cassé de mon vivant et que les données fuitent ? Quel est le risque que le chif­fre­ment ne soit pas cassé mais que les tech­no­lo­gies changent et deviennent diffi­cile à exploi­ter à ce moment là ?

    * * *

    Plein de ques­tions, et diable­ment l’en­vie de monter yet another side project pour créer ce qui n’existe pas : une plate­forme et des outils pour s’oc­cu­per de tout cela, simpli­fier ce qui est déjà diffi­cile humai­ne­ment et qui ne doit pas être aussi diffi­cile tech­nique­ment.

  • [Vidéo] Public key cryp­to­gra­phy – Diffie-Hell­man Key Exchange

    J’ai déjà vu l’ex­pli­ca­tion des pein­tures, mais là on va plus loin, et l’ex­pli­ca­tion de Diffie-Hell­man est juste excel­lente.

  • [Lecture] Most soft­ware already has a “golden key” back­door: the system update

    Réflexions à partir d’un article sur Ars Tech­nica

    Q: What does almost every piece of soft­ware with an update mecha­nism, inclu­ding every popu­lar opera­ting system, have in common?

    A: Secure golden keys, cryp­to­gra­phic single-points-of-failure which can be used to enable total system compro­mise via targe­ted mali­cious soft­ware updates.

    Mine de rien, la plupart de nos appa­reils modernes ont un système de mise à jour, souvent auto­ma­tique. Celui qui détient les clefs peut injec­ter ce qu’il veut, ou simple­ment attendre que vous le fassiez vous-même en croyant mettre à jour.

    On parle de Google, Samsung, Apple, Nokia, Micro­soft et les autres. Des gens parfois recom­man­dables, toujours avec leurs propres inté­rêts.

    On parle aussi des États qui, offi­ciel­le­ment ou non, auraient pu avoir accès à ces clefs. Main­te­nant qu’on connait un peu PRISM et l’éten­due des griffes USA, et l’en­vie de la plupart des pays de les imiter, par la force ou par la loi, ce n’est pas rien.

    On parle ensuite de tous les indi­vi­dus qui ont pu avoir accès à ces clefs et les faire fuiter, volon­tai­re­ment ou non.

    This problem exists in almost every update system in wide use today. Even my favo­rite opera­ting system, Debian, has this problem. If you use Debian or a Debian deri­va­tive like Ubuntu, you can see how many single points of failure you have in your update authen­ti­city mecha­nism with this command:

    sudo apt-key list | grep pub | wc -l

    For the compu­ter I’m writing this on, the answer is nine. When I run the apt-get update command, anyone with any one of those nine keys who is sitting between me and any of the webser­vers I retrieve updates from could send me mali­cious soft­ware and I will run it as root.

    Et si je fais rela­ti­ve­ment confiance à la PKI de Apple, Google et Micro­soft, c’est bien moins vrai pour la plupart des indi­vi­dus isolés derrière les logi­ciels open source.

    Person­nel­le­ment mon Debian perso fait confiance à 14 clefs, certaines proba­ble­ment mal sécu­ri­sées, d’autres parta­gées par plusieurs acteurs, et proba­ble­ment toutes sans le niveau de sécu­rité d’un Apple face aux incur­sions des États.

    La sécu­rité c’est défi­ni­ti­ve­ment trop compliqué pour le monde réel dès qu’il s’agit de se proté­ger contre les très gros acteurs.

    Je ne suis même pas certain que ces très gros acteurs le puissent entre eux. La France utilise des postes sous Micro­soft Windows pour l’ar­mée. Même les postes sous Debian, à ma connais­sance la France n’a pas son armée de déve­lop­peur pour faire une revue de tout le code source et le compi­ler eux-même (et même là, on tombe sous le problème du compi­la­teur qui a lui-même une porte déro­bée qu’il repro­duit dans ce qu’il compile, ça s’est déjà vu dans l’his­toire). En cas de vrai conflit, nous sommes tota­le­ment à genoux.

  • Amazon’s custo­mer service back­door

    Wow. Just wow. The atta­cker gave Amazon my fake details from a whois query, and got my real address and phone number in exchange. Now they had enough to bounce around a few services, even convin­cing my bank to issue them a new copy of my Credit Card.

    — Amazon’s custo­mer service back­door

    Rien de neuf, on a déjà vu des récits de comptes twit­ter pira­tés et de commandes VPC rerou­tées, voire de vraies usur­pa­tions d’iden­tité. C’est désor­mais à chaque fois via de l’in­gé­nie­rie sociale.

    Les ques­tions « secrètes » sont de la bonne blagues et un peu de culot accom­pa­gnés d’un télé­phone permettent d’à peu près tout savoir via votre famille ou vos amis. Les supports tech­niques de vos diffé­rents pres­ta­taires ont telle­ment d’in­for­ma­tions sur vous qu’ils sont des cibles privi­lé­giées.

    De fil en anguille, en récu­pé­rant un bout chez l’un, un autre bout chez l’autre, on peut remon­ter jusqu’à avoir quelque chose de fort.

    Peu de solu­tions. Très peu de gens sont prêts à se faire éjec­ter de leurs services et de leurs données s’ils ont simple­ment changé d’adresse et oublié de la mettre à jour, ou perdu leur mot de passe de l’an­cien compte email, etc. Les service de support client ne font que ce que tout le monde attend.

  • Kaza­kh­te­le­com JSC noti­fies on intro­duc­tion of Natio­nal secu­rity certi­fi­cate from 1 January 2016

    By words of Nurlan Meir­ma­nov, Mana­ging direc­tor on inno­va­tions of Kaza­kh­te­le­com JSC, Inter­net users shall install natio­nal secu­rity certi­fi­cate, which will be avai­lable through Kaza­kh­te­le­com JSC inter­net resources. « User shall enter the site www.tele­com.kz and install this certi­fi­cate follo­wing step by step instal­la­tion instruc­tions”- under­li­ned N.Meir­ma­nov.

    — Tele­com.kz (dépu­blié, voir la version en cache)

    Première réac­tion : Oh la dicta­ture !

    Seconde réac­tion : Chez nous c’est déjà le cas. Notre gouver­ne­ment contrôle une auto­rité de confiance instal­lée dans tous les gros navi­ga­teurs du marché. Pire : Ils l’ont déjà utili­sée pour faire du man in the middle.

    On peut se récon­for­ter en se disant que l’in­ten­tion n’a jamais été délic­tueuse, mais au final la capa­cité est là. Il y a déjà eu déra­page et vu le climat actuel, il n’y a pas vrai­ment lieu d’avoir beau­coup plus confiance que dans le Kaza­khs­tan sur ce point là. Plus récem­ment, l’État français demande aussi accès aux codes sources et archi­tec­tures des héber­geurs et des four­nis­seurs d’ac­cès. On pour­rait ajou­ter que nous sommes déjà un des leaders mondiaux sur les solu­tions commer­ciales de surveillance à l’échelle de pays.

    Plutôt que de se moquer, nous devrions avoir honte de montrer l’exemple. Le Kaza­khs­tan est juste en retard sur nous.

  • TLS et vie privée

    Pour répondre à David :

    TLS does not provide privacy. What it does is disable anony­mous access to ensure autho­rity. It changes access patterns away from decen­tra­li­zed caching to more centra­li­zed autho­rity control.
    That is the oppo­site of privacy. […] TLS is NOT desi­rable for access to
    public infor­ma­tion, except in that it provides an ephe­me­ral form of message inte­grity that is a weak repla­ce­ment for content inte­grity.

    Je suis convaincu que ces gens ont réflé­chi à la ques­tion plus long­temps et plus sérieu­se­ment que moi, mais je ne peux m’em­pê­cher de poser les ques­tions :

    Parler de vie privée c’est parler de confi­den­tia­lité. Vis à vis de qui ? De même, à partir de quand parle-t-on d’ano­ny­mat ?

    Consi­dé­rer que TLS est inutile pour accé­der à une infor­ma­tion publique me semble très étrange. La confi­den­tia­lité n’est pas dans le fait que cette infor­ma­tion soit publique, mais à ce que je consulte ou ce que j’en­voie dans le détail.

    Savoir que j’ac­cède à Face­book est une chose. Savoir quel profil j’uti­lise et ce que j’écris en est une autre, quand bien même les textes en ques­tions sont ne sont pas d’ac­cès restreint. Je ne souhaite pas forcé­ment que l’uni­ver­sité de mon fils puisse lire ce qu’il y écrit via le WIFI local.

    Savoir que j’ac­cède à Wiki­pe­dia est une chose. Savoir que les pages que j’y lis parlent de certains problèmes de sexua­lité en est une autre. Je ne souhaite pas forcé­ment que mon employeur puisse savoir ce que j’y lis pendant ma pause de midi.

    Savoir que je consulte la presse est une chose. Savoir quels sont les articles poli­tiques que je lis et ce que je commente en est une autre. Suivant le pays où je suis, je ne souhaite pas faci­li­ter une éven­tuelle analyse au niveau de mon four­nis­seur d’ac­cès ou du gouver­ne­ment.

    Bref, je suis conscient que l’im­plé­men­ta­tion actuelle des navi­ga­teurs peuvent en théo­rie faci­li­ter le tracking à partir du serveur. Je ne suis pas certain que la tech­nique soit mise en œuvre telle­ment d’autres méthodes plus simples sont effi­caces. La confi­den­tia­lité que ça m’ap­porte compense large­ment ce surcoût.

    La démo­cra­ti­sa­tion de TLS est pour moi une vraie bonne nouvelle.

    I have no objec­tion to the IESG propo­sal to provide infor­ma­tion *also* via https. It would be better to provide content signa­tures and encou­rage mirro­ring

    Je ne nie pas que ça puisse être inté­res­sant, mais l’usage est pour moi tota­le­ment diffé­rent. En fait, à réflé­chir, l’es­sen­tiel des cas où j’ai besoin de garan­tir l’in­té­grité du message sont ceux où j’ai besoin d’une authen­ti­fi­ca­tion, donc où le chif­fre­ment de TLS est aussi néces­saire.

    Propo­ser HTTPS en alter­na­tive me semble aussi une fausse bonne idée. Sur mes deux derniers exemples, j’ai poten­tiel­le­ment non seule­ment besoin que le contenu de ma requête soit confi­den­tielle, mais aussi que mon besoin de confi­den­tia­lité le soit aussi. Que j’uti­lise d’un coup TLS me fera paraitre « louche », ce que juste­ment j’au­rais souhaité éviter. Je l’ai d’ailleurs vu récem­ment dans la presse lors de mises en accu­sa­tion : le fait que les suspects aient utilisé des commu­ni­ca­tions cryp­tées faisait partie des éléments à charge, même sans savoir ce qu’ils ont échangé. Dange­reux, au mieux.

    Plus prag­ma­tique : Il serait facile de bloquer HTTPS pour la plupart des sites publics comme Wiki­pe­dia, Doctis­simo, Twit­ter ou Le Monde, obli­geant les gens à se rabattre sur HTTP. Même les geeks les plus au fait des problèmes ont tendance à accep­ter de dégra­der la commu­ni­ca­tion en clair quand le chif­fre­ment ne passe pas. Rendre TLS option­nel revien­drait à le reti­rer là où juste­ment il est le plus néces­saire.

    Le fait que le web avance pas à pas vers un « TLS unique­ment » est un gros pas en avant pour la confi­den­tia­lité vis à vis de mon envi­ron­ne­ment direct.

    TLS everyw­here is great for large compa­nies with a finan­cial stake in Inter­net centra­li­za­tion. It is even better for those provi­ding iden­tity services and TLS-outsour­cing via CDNs. It’s a shame that the IETF has been abused in this way to promote a campaign that will effec­ti­vely end anony­mous access, under the guise of promo­ting privacy.

    Bref, il y a des choses à faire. Par exemple s’as­su­rer de réduire l’iden­ti­fi­ca­tion possible du navi­ga­teur entre deux requêtes ? (le navi­ga­teur utilise-t-il le même certi­fi­cat à chaque fois ? si c’est ça le problème, il y a certai­ne­ment moyen de faire des rota­tions régu­lières, et de ne pas parta­ger un même certi­fi­cat entre diffé­rentes desti­na­tions).

    Quant à mon anony­mat, il est bien plus vidé de son sens à cause de mon IP qu’à cause du tracking : si j’ai vrai­ment besoin, je peux utili­ser un navi­ga­teur ou un profil diffé­rent pour certaines acti­vi­tés, mais mon IP demande un effort plus impor­tant pour être chan­gée.

    L’autre ques­tion est de savoir auprès de qui est-ce que je cherche le plus à être anonyme, et ce que repré­sente mon iden­tité. Google saura proba­ble­ment me relier à mon email. Mon FAI et mon employeur savent me relier à mon iden­tité civile

    Bref, travaillons à amélio­rer les problèmes de tracking. Ils ne me semblent cepen­dant pas inhé­rents à la tech­no­lo­gie TLS (me trompe-je ?). Ne jetons en tout cas pas le bébé avec l’eau du bain. Surtout si nous n’avons rien à la place.

    Roy T. Fiel­ding nous rappelle le prin­ci­pal danger de TLS et de « SSL partout » : la centra­li­sa­tion des auto­ri­tés de certi­fi­ca­tion. Et par exten­sion du Web.

    C’est un vrai problème, mais qui commence à être dépassé. Le nombre d’au­to­ri­tés de mon Fire­fox se rapproche des 200. Si on consi­dère que ces auto­ri­tés délèguent elles-mêmes à de multiples sous-auto­ri­tés, qui parfois font elles aussi de même, on est loin d’une centra­li­sa­tion déran­geante pour la vie privée. En fait il y a tant de délé­ga­tion que le prin­cipe même d’au­to­rité de confiance devient assez théo­rique.

    Il reste un problème de confiance (auto­rité) et un problème commer­cial. DANE et letsen­crypt sont deux initia­tives qui me font croire qu’on va lais­ser ça derrière nous à moyen (pour letsen­crypt) ou long terme (pour DANE).

    Un client qui sait ne pas réuti­li­ser inuti­le­ment le même certi­fi­cat, qui véri­fie le serveur à l’aide de DANE les écueils de confi­den­tia­lité suivants seront surtout dans SNI, DNS et IP.