GuiGui's Show

Stade de Nice

• Différence entre MOP et PPP :

  • Maîtrise d'Ouvrage Public (MOP) : la collectivité emprunte elle-même et elle gère elle-même le projet de bout en bout.
    
    
  • Partenariat Public Privé-PPP) : le prestataire fait l'emprunt, gère la construction, empoche les entrées et autres revenus (publicitaires, location pour des congrès et autre), jouit d'une redevance annuelle payée par la collectivité, profite des subventions et d'une compensation d'impôts (taxe foncière, IS, taxe professionnelle, etc.) pendant la durée du contrat (27 ans et 5 mois pour le stade de Nice) c'est-à-dire que c'est la ville qui paye les impôts, y compris si ceux-ci augmentent.
• Le PPP peut être utile et profitable à la collectivité quand il n'est pas vu comme une simple commodité financière pour éviter de lever l'impôt ou pour s'endetter tout en améliorant les équipements de la collectivité. Or, un rapport resté confidentiel du Ministère des Finances met en évidence une explosion du nombre de contrats PPP passés quelques années seulement avant une échéance électorale dans les collectivités.
  
  
• Je retiens que le contrat (y compris les annexes) est bien un document communicable au sens de la loi de 1978 et que donc Cash a exagéré avec le secret des affaires.

Contrat "open bar" entre Microsoft et la Défense française

J'en ai déjà parlé dans un autre shaarli : http://shaarli.guiguishow.info/?mBvFqA

• J'apprécie le full disclosure concernant la relation d'amitié entre Élise Lucet et Marc Mossé.
  
  
• Faire intervenir Éric Filiol… oui… Le gus qui prétendait avoir cassé AES au début des années 2000 puis qui a prétendu que son équipe a cassé TOR en 2011 (https://koolfy.be/2011/10/24/did-filiol-break-tor-1/). Sans compter le paradigme étrange et la com' très bancale autour de Perseus (https://exploitability.blogspot.fr/2011/07/lib-perseus-pas-convaincu.html et https://news0ft.blogspot.fr/2011/06/challenge-fail.html ). Bref, quelques bourdes et exagérations qui ne jouent pas en sa faveur mais bon…
  
  
• Je ne suis pas convaincu par la démonstration. Oui, tout système sera toujours vulnérable à un-e humain-e qui clique sur n'importe quoi.
  
  
• Ce reportage révèle la logique sous-jacente (que l'on retrouve aujourd'hui dans le choix de Skype Pro par la DSI du CNRS) : on prend la décision en amont, on nomme des comités de prise de décision totalement bidons que l'on n'écoutera pas et surtout, surtout, on n'écoute pas les techniciens. Les propos du vice-amiral Coustillière sont clairs : « Ce débat est un débat d'informaticien [...] C'est un débat dépassé depuis plusieurs années ».

Pôle emploi et opérateurs privés de placement (OPP)

• Théorie : les personnes à la recherche d'un emploi les plus autonomes sont confiées au privé pour du suivi personnalisé afin que le public prenne soin des autres personnes, jugées plus en difficulté.
  
  
• Dans la pratique, Pôle emploi doit refourguer de la prestation privée à marche forcée. Objectifs chiffrés à tenir.
  
  
• Exemples d'OPP : Ingeus, Aksis, etc.
  
  
• Quelques pratiques douteuses : présentation PowerPoint en solitaire en lieu et place d'un-e interlocuteur-rice, rdv administratif pour l'enregistrement du dossier (mais c'est toujours mieux que de voir Pôle emploi partager le dossier complet de la personne en recherche d'emploi avec le privé), services en ligne doublons de ceux proposés par Pôle emploi comme Emploi Store (et donc payés par la puissance publique), interlocuteur-rice différent-e à chaque rendez-vous, rendez-vous collectif ou via Skype, bilan de clôture pas du tout personnalisé (une ex-employée d'Ingeus) dénonce des bilans copiés/collés, etc. Bref, suivi pas personnalisé du tout.
  
  
• L'OPP récolte en moyenne 435 € pour tout-e chômeur-euse qui retrouve un emploi, 152 € sinon.
  
  
• Le directeur général de Pôle emploi qui croit à l'autorégulation des OPP. Puisque ces sociétés commerciales sont mieux payées si le-a chômeur-euse retrouve un emploi, elles vont tout faire pour faire du vrai bon boulot. C'est mignon tout plein, non ? :))))

Cash est toujours aussi chiant avec sa scénarisation genre créer de la symbolique autour des accords privés/publics assimilés à un mariage entre un BCBG et Marianne. Osef de savoir en détails comment l'équipe s'est faite blouser par le ministre de la Défense. Toute la mise en scène doit représenter au moins 1/3 du temps total de l'émission, quoi !

Le ton est toujours aussi insupportable, ça coupe la parole sans arrêt aux personnes interrogées. Même si la personne ment, noie le poisson ou raconte n'importe quoi, tu le laisses finir et tu rectifie après, sérieux. Là, c'est juste inaudible et bien prise de tête à suivre.

Je n'avais pas regardé cette émission depuis septembre 2015 (un épisode) et novembre 2014 et ça ne m'avait pas manqué. Et c'est dommage car il y a un vrai travail sur le fond. :(

Ce que j'en retiens :

• Je n'y avais pas pensé avant mais un arbre GPON est partagé donc tous les membres de l'arbre reçoivent les flux descendants (Internet -> abonné-e) de tous les autres membres de l'arbre. Ce flux peut être chiffré avec AES entre l'OLT et l'ONT (reste à savoir si les FAI le mette en pratique). L'upstream n'est pas dupliqué et n'est pas chiffré. On retrouve les mêmes problématiques de média partagé que sur le câble… ou le Wi-Fi (oui, même avec un mécanisme WPA-2 avec chiffrement AES+CCMP, toutes les personnes qui connaissent la passphrase peuvent prendre connaissance du trafic de toutes les autres).
  
  
• L'authentification de l'ONT de l'abonné-e est réalisée par l'OLT avec un identifiant, le SLID. Soit cet ID est provisionné en amont de l'installation chez le client puis configuré sur l'ONT lors de l'installation chez le client (Orange), soit il est volatile (SFR en 2013). Dans ce dernier cas, l'OLT peut utiliser l'adresse MAC de l'ONT pour l'authentifier, c'est ce que SFR ferait en 2016 en plus du SLID (voir http://www.zdnet.fr/actualites/d-inquietantes-failles-de-securite-dans-les-acces-fibre-optique-ftth-en-france-39844258.htm).
  
  

• Au final, pour monter une connexion Internet fonctionnelle, il faut :

  • dans tous les cas : forcer une armoire d'immeuble et avoir un ONT.
    
    
  • chez SFR : (un SLID valide qui doit être enregistré sur le bon arbre GPON ?) + le DHCP vendor-id qui est parfois spécifique à une zone géographique donnée.
    
    
  • chez Orange : un SLID valide qui doit être enregistré sur le bon arbre GPON + login PPP ou DHCP mais il doit falloir transmettre au serveur des attributs spécifiques, je pense.
• Sur les ONT en eux-même :
  • J'apprends qu'il ne s'agit pas d'un équipement passif qui ferait uniquement du codage de l'information en couche 1 entre fibre et cuivre. Il s'agit d'un vrai Linux + busybox avec une IP locale, du telnet et tout.
    
    
  • Comme d'habitude, on trouve un accès de maintenance dont le login/mdp (qui permet au technicien de saisir le SLID lors de l'installation chez le client) a fuité depuis fort longtemps. Mais, on trouve aussi plusieurs comptes root, un « Alcatel User » quand Alcatel est l'équipementier, etc.
    
    
  • Comme d'habitude sur ce genre d'équipement, tous les ONT Alcatel partagent les mêmes clés SSH (ce qui n'est pas conforme au modèle de sécurité de SSH mais bon, osef, les techniciens n'utilisent pas SSH mais telnet), les permissions Unix sont désastreuses, il y a une faille Remote Code Exploitation dans les scripts CGI (mais il faut être authentifié… mais comme un couple login/mdp a fuité ;) ), bref, c'est crade.

En bref : je suis déçu par ce papier. l'authentification foireuse dans un arbre quand on remonte physiquement la chaîne des équipements physiques de fourniture d'accès, on a déjà eu ça sur le câble. L'auth' foireuse au niveau PPP, on a déjà eu ça sur l'ADSL (genre un couple identifiant/mdp qui fonctionne sur d'autres lignes physiques que celle de l'abonné, genre un login FDN marchait sur une ligne SFR pas encore migrée vers FDN, ce genre de choses). Rien de neuf ni d'alarmant : il faut quand même réunir beaucoup d'éléments pour avoir une connexion THD "anonyme". À ce compte-là, tu peux aussi prétendre que les connexion THD sur les campus universitaires sont totalement pas sécurisées et qu'elles permettent des connexions THD "anonymes".

Il y a un flou dans l'article de zdnet : Orange distribuait encore des ONT Alcatel en octobre-novembre 2015 à ses nouveaux clients. À l'inverse, en novembre 2014, dans une autre ville de France, c'est bien un ONT chinois qui est distribué par Orange à ses nouveaux clients. Il en découle qu'il doit encore y avoir masse d'ONT Alcatel en circulation.

Via #ffdn.

En physique relativiste, on place la dimension du temps sur le même plan que les dimensions spatiales. L’ensemble forme donc une seule entité appelée « espace-temps ». L’hypothèse selon laquelle on devrait pouvoir se déplacer sur l’axe temporel aussi bien que l’on se déplace sur les axes de l’espace n’a donc rien d’absurde en soi.

[...]

Voyager dans le futur

Si je vous disais qu’on voyage actuellement dans le temps, vous me croiriez ? On voyage dans le futur à raison d’une seconde par seconde.
Ça a l’air idiot dit ainsi, c’est pourtant la réalité. Le temps qui passe n’est rien d’autre qu’un voyage inlassable le long de l’axe temporel, du passé vers le futur en restant sur l’instant présent.

Bon à part ça, tel qu’on l’entend habituellement voyager dans le futur n’est pas exclu par la physique. Le voyage dans le futur ne crée en effet aucun paradoxe ou problème temporel. En fait c’est même possible.

Maintenant, imaginez : plutôt que que de voyager dans le futur à raison d’une seconde chaque seconde, vous avanciez dans le futur à raison de deux secondes chaque seconde. Si vous faisiez cela et que votre ami ne le faisait pas, alors vous vous retrouveriez en avance sur l’axe temporel par rapport à votre ami. Vous seriez dans son futur.

[...] Et se placer dans un tel cas est faisable : la relativité restreinte nous dit que chaque référentiel (chaque lieu, chaque personne, chaque planète…) dispose de son propre écoulement du temps. Deux personnes peuvent donc avoir des horloges qui avancent à deux vitesses différentes, et donc que l’une avance plus rapidement dans le temps que l’autre.

En pratique, pour que votre horloge avance plus vite que celle du reste du monde, il y a deux possibilités :

• soit se déplacer à une vitesse très importante par rapport au reste du monde.
• soit se placer à côté d’un très intense champ gravitationnel (comme celui d’un trou noir supermassif).

[...]

Quand on se déplace à très grande vitesse (proche de celle de la lumière), notre temps semble s’écouler beaucoup moins vite pour [pour] quelqu’un qui serait resté immobile et qui nous observe. Ainsi, si vous montiez dans un vaisseau spatial et que vous faites un voyage à très grande vitesse, il pourra s’être écoulé 100 ans sur Terre alors que vous n’auriez vécu qu’un an. Les gens restés sur Terre verront alors atterrir une personne jeune qui existait par le passé. Dit autrement, vous auriez effectué un bond dans leur futur.

Ces deux méthodes sont parfaitement valables sur la plan de la physique. Il reste cependant impossible de les utiliser pour le moment : nous ne disposons encore ni la technologie nécessaire pour construire un vaisseau spatial assez rapide, ni un moyen d’aller visiter les abords d’un trou noir supermassif et de revenir.

Néanmoins, il n’est pas nécessaire de voyager à des vitesses proches de la lumière ou près d’un trou noir pour être affecté par ces phénomènes. Voyager à n’importe quelle vitesse et près de n’importe quel objet massique suffit. Les effets seront simplement beaucoup moins importants.
Le meilleur cas observable peuvent être les astronautes à bord de la Station Spatiale Internationale (ISS) : ils voyagent à une vitesse relativement importante (faisant le tour de la Terre en 1h30) en plus de se trouver dans un champ gravitationnel légèrement moins intense que le reste du monde, à cause de leur éloignement à la Terre.

De ces deux effets, aux conséquences contradictoires (le premier accélère l’horloge des astronautes, le second la ralentit) la plus significative est celle liée à la vitesse. Ainsi, après avoir passé 6 mois à bord de l’ISS, un astronaute a vécu 5 millisecondes de moins que nous. On peut dire qu’il a voyagé 5 millisecondes dans notre futur.

Voyager dans le passé

On serait tenté de dire que le voyage dans le passé est impossible : le principe de causalité nous l’empêcherait : par exemple, puisque vous descendez de vos parents, alors revenir dans le passé pour empêcher vos ancêtres de se rencontrer peut-il empêcher l’existence de vos parents et donc de la vôtre dans le présent… et par conséquent vous empêcher de retourner dans le passé (en conséquence de quoi vous finiriez par exister tout de même, faute d’avoir pu prévenir votre conception !).

[...]

Ce paradoxe empêcherait donc totalement le voyage dans le passé ? À vrai dire, on ne sait pas encore.
À ce jour, avec la physique dont nous disposons, les tentatives pour prouver l’impossibilité de voyager dans le passé, y compris les travaux de Stephen Hawking n’ont pas abouties : on n’a pas réussi à prouver que le voyage dans le passé était impossible. Ceci ne dit pas qu’il est possible, ça dit juste qu’on n’est pas encore sûr que ce soit impossible, et rien ne dit que cette impossibilité existe et/ou soit un jour prouvée.

[...]

L’une d’elle est l’hypothèse du multivers. Avec ça, lorsque l’on voyage dans le passé, on ne se retrouve plus sur notre propre axe temporel, mais sur un autre, dans un autre univers. Toute modification ainsi apportée au cours des événements seront alors totalement décorrélés de l’axe temporel initial. C’est ce qui arrive dans Retour Vers le Futur quand la DeLorean revient en 1985 et découvre qu’il n’y plus qu’un seul arbre debout alors que le 1985 qu’ils avaient quitté en avaient deux

Ainsi il n’y aurait jamais de paradoxe du grand-père : si vous supprimez votre grand-père sur cette nouvelle branche du temps, ceci n’affectera pas votre destinée sur la branche principale. Seulement la nouvelle destinée sur la nouvelle branche (qui n’est à ce moment pas encore écrite). Votre propre existence n’y serait pas non plus compromise car elle naît de l’axe temporel (de l’univers) initial, pas de la nouvelle.

Mouiiiiin deux univers bien cloisonnés mais l'univers "d'origine" sert de référence donc on retrouve les mêmes personnes, les mêmes objets, etc. Difficilement à concevoir…

[...]

Une autre idée pour résoudre le paradoxe du grand-père et donc un problème où des effets (vous) pourraient exister avant leur causes (vos ancêtres) et les empêcher, serait que l’ensemble des événements soient contenues dans une seule et même boucle qui aurait toujours existé. Ainsi, un événement dans votre passé s’est produit grâce à un autre « vous » retourné dans le temps.

On retrouve cette hypothèse dans des œuvres telles que Harry Potter et le Prisonnier d’Azkaban, où Harry et Hermione décident de changer les trois dernières heures de leur propre passé afin de sauver Sirius Black et Buck (l’hippogriffe) de la mort. À la fin de l’histoire, Harry et Sirius sont sauvés par le Harry qui est retourné dans le passé.

À noter que personne ne reste coincée indéfiniment dans la boucle pour autant : la boucle fait partie de l’histoire du temps, mais une fois qu’on dépasse l’heure de la fin de la boucle, on en sort et la vie poursuit son cours. C’est simplement qu’il existe à un moment donné, deux Harry Potter qui s’influent mutuellement.

Par ailleurs, tout ce qui se passe sur la boucle dans son ensemble a toujours existé. Le cours de l’histoire n’a pas été changé et la boucle fait partie de l’histoire :

Un autre exemple assez connu est celui concernant le Titanic : certains pensent en effet qu’un grand nombre de voyageurs temporels sont allés à bord du navire pour tenter d’empêcher son naufrage. Le nombre de voyageurs temporels aurait été si important que la surcharge occasionnée a empêché le paquebot de dévier de sa trajectoire, ce qui a conduit à son naufrage.
Ici, le naufrage est donc causé par les gens du futur qui veulent tous empêcher le naufrage, mais qui en sont, du coup, responsables. Il n’y a pas de paradoxes : tout se tient et les principe de causalité sont respectés.

[...]

Selon certaines hypothèses, même, le voyage dans le temps serait seulement possible dès l’instant où l’on invente une machine à voyage dans le temps. Il ne serait alors pas possible de voyager à une date antérieure à la date où la première machine à voyage dans le temps soit inventée. Ceci semble assez logique, et un indice qui prend l’allure de preuves serait alors que nous n’ayons parmi nous aucun voyageur venu du futur…

Où qui ne l'ont jamais dit car aucun moyen de prouver ce qu'ils affirment sans que ça parte en live donc risque pour leur vie.

Cela fait plusieurs fois que j'évoque DANE TLSA sur ce shaarli. L'idée est de stocker dans le DNS, signé cryptographiquement avec DNSSEC afin de garantir l'intégrité et l'authenticité des informations, les certificats x509 que nous utilisons dans nos transactions TLS afin de fermer les failles béantes du modèle de sécurité x509. Et de pouvoir se passer des centres de concentration du pouvoir que constituent les autorités de certification (AC) qui sont des sociétés commerciales qui vendent exclusivement du vent.

Pour approfondir la théorie :

• Une excellente synthèse de DANE TLSA chez Stéphane Bortzmeyer.
  
  
• Un exposé à JRES 2011 du même Stéphane pour ceux et celles qui ne voudraient pas lire. Certains points ont évolué depuis (exemple : le nombre d'« usages » prévus) mais l'essentiel est toujours d'actualité notamment toute la partie sur pourquoi les AC sont des vendeuses de vent et pourquoi le modèle de sécurité de x509 est complètement cassé et ce, par conception, par essence.
  
  
• Pour comprendre pourquoi il faut quitter le marécage fétide des AC x509, je vous recommande un de mes shaarlis : http://shaarli.guiguishow.info/?i-OcNA . En gros : injustice dans le choix de l'incorporation des AC dans les magasins de certificats, concentration du pouvoir entre les mains de quelques acteurs commerciaux mondiaux, opacité et monde fermé, potentielles atteintes à la vie privée et pouvoir de censure accordé aux AC. DANE TLSA permet de la crypto décentralisée et de virer des acteurs inutiles.
  
  
• DANE TLSA permet également d'éviter les attaques par repli. Voir la section « Postfix » ci-dessous.
  
  
• DANE (et SSHFP, voir http://shaarli.guiguishow.info/?QWcOtQ) sont des cas d'utilisation concrets qui rendent le déploiement de DNSSEC intéressant non plus comme un service de protection de l'infrastructure mais aussi de protection de l'adminsys et des "clients".

Notons que DANE ne s'occupe pas seulement de TLS mais est beaucoup plus vaste. Exemple : le stockage des clés OpenPGP dans le DNS est normalisé, voir http://www.bortzmeyer.org/7929.html .

Je considère la théorie acquise et je n'y reviendrai pas. L'objectif est de tester DANE TLSA dans des conditions réelles sur mes serveurs persos. J'avais déjà tenté en 2014 mais j'étais restait bloqué sur la lib ldns qui ne prenait pas en charge les enregistrements DNS de type TLSA.

Rappel : lors d'un renouvellement ultérieur du certificat, attention au TTL

En effet, lors d'un futur renouvellement d'un certificat associé à un enregistrement TLSA, il faudra générer le certificat, générer son enregistrement TLSA, publier ce dernier dans votre zone DNS, attendre puis seulement ensuite mettre le certificat en production sur vos serveurs (web, mail, etc.).

ÉDIT DU 14/01/2017 À 17H45 : En fait, ce n'est pas aussi simple, comme nous le verrons de manière elliptique dans la section « Conception » ci-dessous :

• Si vous stockez l'intégralité de votre certificat dans le DNS, vous devez renouveler son l'enregistrement TLSA qui lui est associé à chaque renouvellement du certificat ;
  
  
• Si vous stockez uniquement la clé publique de votre certificat dans le DNS alors, il n'y a pas besoin de renouveler l'enregistrement TLSA tant que la clé publique utilisée dans le certificat reste la même. C'est le cas chez CaCert et chez Let's Encrypt, par exemple : chaque renouvellement est une nouvelle signature. La même paire de clés est utilisée, il n'y a que le certificat qui change.

FIN DE L'ÉDIT.

Il faut attendre combien de temps ? Cela dépend du TTL de l'enregistrement. Dans mon cas, je configure un TTL de 3600 secondes (1h) dans mes zones persos principalement parce que certaines sont hébergées à domicile, ce qui impose quelques contraintes, voir http://shaarli.guiguishow.info/?wgU1VQ.

Si vous n'attendez pas ce délai, il se peut qu'un client ait récupéré votre ancien enregistrement TLSA. Il n'arrivera pas à valider le nouveau certificat avec l'ancien TLSA. À l'heure actuelle, ce n'est pas bloquant puisque on est dans une validation "à la cool" compte-tenu du faible usage de DANE mais autant prendre le pli des bonnes pratiques qui seront nécessaires dans le futur, si toutefois DANE en fait bien partie, et avec lesquelles la connexion sécurisée échouera purement et simplement.

Conception

Avant de foncer tête baissée, réfléchissons à ce que nous voulons et allons faire.

Usage, selector et matching type

Sur un de mes serveurs, j'utilise un certificat autosigné. Ce sera donc un usage = 3, que l'on nomme aussi DANE-EE / Domain-issued certificate. Il s'agit d'une contrainte sur le certificat : le client TLS doit obtenir le même de la part du serveur TLS pour que l'échange continue. On se passe de toute l'infrastructure et de toute la validation x509 habituelle.

Sur mes autres serveurs, comme celui qui héberge ce shaarli et mon blog, j'utilise une AC perso. Ce sera donc un usage = 2, que l'on nomme aussi DANE-TA / Trust anchor assertion. Il s'agit d'une contrainte sur l'AC : le client TLS acceptera uniquement tout certificat portant mon nom de domaine et signé par cette AC. On se passe de toute l'infrastructure x509 habituelle, on demande au client TLS d'ignorer toutes les AC pré-définies dans son magasin de certificat.

Pour le selector : il faut être vigilant pour les cas d'usage 0 et 2. L'annexe A.1.2 du RFC 6698 explique les cas où l'on peut obtenir des fails : des attributs ont été ajoutés au certificat d'AC, l'algorithme de signature change, le client TLS trouve un certificat d'AC actualisé dans son magasin ou dans son cache ou dans un attribut x509 « Authority Information Access », le certificat est cross-signé par plusieurs AC et le client TLS choisi l'autre CA, Let's Encrypt où le certificat (mais pas la paire de clés !) est re-généré tous les 3 mois, etc. Dans ces cas-là, une comparaison sur l'intégralité du certificat échouera. Dans mon cas, l'AC est mienne, elle ne change pas, elle n'est pas cross-signée, bref, je n'identifie aucun problème. Donc je stockerai le contenu entier de mes certificats dans le DNS donc selector = 0.

Pour le matching type, c'est plus facile : on ne va pas stocker tout le certificat dans le DNS et SHA-256 est suffisant de nos jours donc matching type = 1.

CNAME

Lorsque je crée mes zones DNS, j'y enregistre d'abord mes machines, sous leur vrai nom genre viki.guiguishow.info. Ensuite, pour chaque machine, j'accroche les services assurés par cette machine. Soit avec les enregistrements MX et SRV quand c'est possible, soit avec des CNAME. Exemples : « @ MX viki », « shaarli CNAME viki ».

Tous mes sites web, mes virtualhosts, utilisent le même certificat x509.

La question est donc : est-ce que je dois créer des TLSA pour shaarli.guiguishow.info ou pour viki.guiguishow.info compte-tenu que le premier est un alias pointant sur le deuxième ? Est-ce que je dois avoir un enregistrement « _443._tcp.shaarli.guiguishow.info. IN TLSA [...] » ou bien un enregistrement « _443._tcp.viki.guiguishow.info. IN TLSA [...] » ?

L'annexe A.2.1.1 du RFC 6698 nous informe que les deux sont possibles (et même en même temps !) mais les implémentations demanderont « _443._tcp.shaarli.guiguishow.info. ». Ce nom doit répondre, même s'il est un alias vers « _443._tcp.viki.guiguishow.info. ». ÉDIT DU 14/01/2017 À 17H45 : pour les protocoles à indirection DNS (comme SMTP ou XMPP) les RFC 7672 et 7673 sont formels : le TLSA doit porter sur le nom du serveur, ici viki.guiguishow.info, pour faciliter l'hébergement. FIN DE L'ÉDIT.

J'ai choisi de créer un seul enregistrement TLSA par machine et autant de CNAME qu'il y a de virtualhosts. Je trouve ça lisible, je trouve que ça correspond bien à mon déploiement actuel de "un certificat x509 par machine" et ça facilitera les changements de certificats.

Trouver un logiciel qui génère des enregistrements TLSA

Oui parce que créer des enregistrements à la main avec OpenSSL, c'pas vraiment convivial.

Un logiciel plus convivial est hash-slinger. Il permet de générer des enregistrements SSHFP (voir http://shaarli.guiguishow.info/?QWcOtQ ) avec la commande sshfp, des enregistrements DANE OpenPGP (voir http://www.bortzmeyer.org/7929.html) avec la commande openpgpkey et des enregistrements DANE TLSA avec la commande tlsa. Il est même packagé dans Debian. \o/

Ce logiciel attend un root.key, c'est-à-dire un fichier contenant la clé publique de la racine DNS pour l'utiliser avec la libunbound afin d'effectuer de la validation DNSSEC locale. Dans mon cas, j'ai un serveur récursif-cache local Unbound installé sur ma machine de travail donc j'ai un fichier /var/lib/unbound/root.key. Si ce n'est pas votre cas, installez unbound-anchor et exécutez la commande sudo unbound-anchor -a /etc/unbound/root.key.

Mais, sous Jessie, l'outil tlsa s'attend à trouver la clé dans /etc/unbound/root.key. Il faut patcher /usr/bin/tlsa (c'est un script python) en changeant les valeurs des variables ROOTKEY et DLVKEY. Ce problème a été corrigé dans les dernières versions. On peut même trouver une version corrigée dans jessie-backports.

Au boulot !

Pour un certificat autosigné (+ tout le certificat dans le DNS + SHA-256)

tlsa --create --usage 3 --selector 0 --mtype 1 <hostname>

Pour une AC perso (+ tout le certificat dans le DNS + SHA-256) :

tlsa --create --usage 2 --selector 0 --mtype 1 <hostname>

Attention : il faut que le serveur (web, dans ce cas précis mais c'est valable pour tout serveur TLS) envoie le certificat de l'AC en plus de son certificat serveur. C'est la règle avec TLS + x509 (on doit fournir une chaîne complète jusqu'à un certificat que l'on suppose présent chez notre interlocuteur, une AC privée n'est pas supposée présente) mais on trouve des serveurs mal configurés. Pour vérifier ce point, vous pouvez utiliser https://www.ssllabs.com/ssltest/ : si vous avez un message « This server's certificate chain is incomplete. Grade capped to B. », ce n'est pas bon signe.

Je rappelle que pour chaîner des certificats, on fait comme cela :

cat moncertificat.crt > cert+ca.chain
cat certificatAC.crt >> cert+ca.chain

C'est le fichier .chain qu'il faut indiquer dans la configuration de votre serveur (SSLCertificateFile pour apache httpd, smtpd_tls_cert_file pour postfix, etc.).

tlsa va vous proposer chaque certificat présent dans la chaîne transmise par le serveur TLS, à vous d'accepter le bon. Exemple :

Got a certificate with the following Subject:
/C=FR/ST=Some-State/O=GuiGui's Show/CN=viki.guiguishow.info/emailAddress=[censure_no_spam]
Use this as certificate to match? [y/N] n
Got a certificate with the following Subject:
/C=FR/ST=Some-State/O=GuiGui's Show/CN=Autorite de certification GGS/emailAddress=[censure_no_spam]
Use this as certificate to match? [y/N] y

Il reste à ajouter l'enregistrement DNS créé par hash-slinger à notre zone DNS et à re-signer la zone.

ÉDIT DU 21/11/2016 À 11H50 : oui, demander à tlsa de récupérer le certificat en causant à votre serveur TLS implique que vous soyez sûr qu'il n'y a pas un attaquant actif entre vous et votre serveur auquel cas le certificat que vous mettrez dans le DNS sera celui de l'attaquant. Dans mon cas, j'utilise un VPN entre ma machine de travail qui exécute tlsa et mes serveurs. Vous pouvez également utiliser l'option « --certificate /chemin/vers/certificat » de tlsa pour lui donner localement le certificat à traiter. FIN DE L'ÉDIT.

Vérifier

Pour vérifier que tout est OK :

tlsa --verify <hostname>
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record

Il y a deux lignes car tlsa vérifie en IPv4 et en IPv6.

Pour Firefox, il y a l'extension DNSSEC/TLSA Validator écrite par les gens de nic.cz, des gens de confiance.

Si votre configuration est OK, cette extension doit vous indiquer que tous vos sites web sont désormais OK. Attention : cette extension fait elle-même la résolution DNS (histoire d'être sûre de valider les signatures DNSSEC en local) donc elle conserve son propre cache. ;) Il faut redémarrer Firefox pour vider ce cache.

Autres protocoles

Tout protocole réseau qui utilise TLS peut être protégé par DANE TLSA : SMTP, IMAP, XMPP, etc.

Exemple avec SMTP :
hash-slinger ne prend pas en charge STARTTLS. Il faut procéder différemment :

openssl s_client -showcerts -connect <machine>:25 -starttls smtp </dev/null 2>/dev/null | openssl x509 -outform PEM > mycertfile.pem
tlsa --create --usage 3 --selector 0 --mtype 1 --certificate mycertfile.pem <nom_machine>

ÉDIT DU 14/01/2017 À 17H45 : conformément au RFC 7672, <hostname> doit être le nom du serveur, celui qui est dans le RDATA (partie droite) de l'enregistrement MX, pas sur le nom de domaine pour lequel on insère un MX. FIN DE L'ÉDIT.

La commande openssl vient de là : https://superuser.com/questions/97201/how-to-save-a-remote-server-ssl-certificate-locally-as-a-file .

ÉDIT DU 21/11/2016 À 11H50 : oui, demander à openssl de récupérer le certificat en causant à votre serveur TLS implique que vous soyez sûr qu'il n'y a pas un attaquant actif entre vous et votre serveur auquel cas le certificat que vous mettrez dans le DNS sera celui de l'attaquant. Dans mon cas, j'utilise un VPN entre ma machine de travail qui exécute openssl s_client et mes serveurs. Sinon, vous pouvez directement filer le fichier contenant votre certificat à tlsa. ;) FIN DE L'ÉDIT.

Pour l'instant, mon logiciel de mail, Thunderbird, ne prend pas en charge DANE. :(

Pour l'instant, mon client Jabber, Gajim, ne prend pas en charge DANE. :(

Pour l'instant, mon serveur Jabber, ejabberd, ne prend pas en charge DANE pour la communication entre serveurs Jabber. :(

Mon serveur mails, Postfix, prend en charge DANE pour la communication entre serveurs mails. \o/ Uniquement les usages 2 et 3, ceux où on n'effectue pas la validation PKIX classique.

Postfix

Pour que votre serveur mails Postfix valide le certificat qu'il obtient auprès d'un serveur SMTP distant en utilisant DANE mais qu'il continue l'envoi du mail s'il n'y a pas d'enregistrements DNS de type TLSA, il faut activer les options suivantes dans main.cf :

smtp_dns_support_level=dnssec
smtp_tls_security_level=dane

ÉDIT DU 30/04/2020 À 13 H 35 : attention : les versions de TLS et les suites de chiffrement autorisées se définissent alors dans smtp_tls_mandatory_protocols et smtp_tls_mandatory_ciphers ! La documentation expose bien ce point : « For purposes of protocol and cipher selection, the "dane" security level is treated like a "mandatory" TLS security level ». FIN DE L'ÉDIT DU 30/04/2020.

Quand vous écrirez à un domaine qui utilise DANE, et si vous utilisez la directive de configuration smtp_tls_loglevel = 1, Postfix indiquera dans les logs quand il validera une transaction TLS grâce à DANE :

Verified TLS connection established to [censure]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Pour les domaines qui n'utilisent pas DANE, vous verrez le classique message :

Untrusted TLS connection established to [censure]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Ici, DANE TLSA offre un avantage supplémentaire : en SMTP, POP, IMAP, XMPP, on préfère utiliser STARTTLS, c'est-à-dire que l'on n'ouvre pas 2 ports différents (un pour la version claire et un pour communiquer de manière chiffrée, comme c'est le cas avec http (port 80) et https (port 443) mais que l'on utilise un seul port dans lequel on se laisse une opportunité de démarrer une conversation chiffrée. Sauf que l'initiation de cette communication chiffrée se fait avec un message « STARTTLS »… qu'un attaquant actif peut supprimer ou altérer. Ainsi, l'échange aura lieu en clair. STARTTLS protège uniquement contre un attaquant passif, un attaquant qui est uniquement en capacité d'écouter sur le réseau.

Évidemment, on peut configurer les logiciels (clients et serveurs) pour forcer l'utilisation de TLS sauf que le mail est ancien et que tout le monde a l'habitude de faire n'importe quoi. Conclusion : forcer le chiffrement, c'est ne plus pouvoir envoyer de mails sauf à ses potos crypto-anarchistes. Sur Jabber, plus récent, on a moins cette inertie (mais le problème est quand même là) donc un serveur qui force le chiffrement n'est pas isolé.

Là où DANE intervient, c'est que si Postfix récupère un enregistrement TLSA utilisable lorsqu'il envoie un mail, il voudra forcément un échange chiffré avec le serveur de mail correspondant. Un attaquant actif ne peut plus faire échouer l'initialisation d'une communication chiffrée.

Quid de la duplication d'infos dans le DNS ?

Dans la section « CNAME », nous avons vu que j'ai un enregistrement TLSA par couple port (443) + machine et que tous mes noms de sites web pointent dessus.

Mais là, nous avons besoin d'enregistrements TLSA pour le port 25. Et un jour peut-être pour les ports IMAP, POP, Jabber, etc. On ne va quand même pas avoir autant d'enregistrements TLSA dans nos zones : ça rend moins lisible le fichier et à chaque changement de certificat, il faudrait changer X enregistrements.

Sachant que, sur certains domaines que j'administre et dont je ne suis pas le seul utilisateur, j'ai des enregistrements CNAME pour aider à la configuration du logiciel mail tel que imap CNAME <machine>, smtp CNAME <machine>, etc. Je ne vais quand même pas avoir un TLSA pour chaque nom.

Évidemment, je vais utiliser des CNAME.

La question est : est-ce que je fais pointer tous les autres noms "TLSA" sur _443._tcp.<machine> ou est-ce que je crée un enregistrement TLSA générique de la forme <machine> TLSA <RDATA> sur lequel pointeront tous les autres ?

Je trouve la deuxième manière de faire plus lisible : lors d'un renouvellement de certificat x509, je cherche un enregistrement précis avec une sémantique précise et je change sa valeur. De plus, cela évite de faire penser que HTTPS est le protocole de référence pour tous les autres, ce qui n'a aucun sens.

En revanche, cette manière de faire peut conduire à des chaînes de CNAME. Si elles ne sont pas interdites dans la norme, elles sont déconseillées. Exemple de chaîne ? _443._tcp.shaarli.guiguishow.info. qui ponterait sur _443._tcp.viki.guiguishow.info. comme nous l'avons vu dans la section « CNAME » qui, lui-même, pointerait sur l'enregistrement générique viki.guiguishow.info. TLSA [...]. Un autre exemple ? _25._tcp.smtp.guiguishow.info. qui pointerait sur _25._tcp.viki.guiguishow.info. qui pointerait sur l'enregistrement générique.

En conclusion, j'ai :

• Un enregistrement générique par machine puisque j'utilise le même certificat (ou la même AC) sur tous les services fournis par une machine. Exemple : « viki TLSA [...] ».
  
  
• Un CNAME par service ou par virtualhost. Exemples : « _25._tcp.viki CNAME viki », « _443._tcp.shaarli CNAME viki ».

Chemin restant

• Plus de logiciels (clients et serveurs) doivent implémenter DANE TLSA. Et notamment les navigateurs web. Mozilla, en tant que logiciel communautaire a clairement un rôle à jouer.
  
  
• L'implémentation doit être totale, c'est-à-dire qu'un certificat x509 autosigné qui a un enregistrement TLSA associé à lui ne doit pas lever une alerte de sécurité et demander l'ajout d'une exception car cela est parfaitement normal : de la crypto décentralisée (sans tomber dans le modèle de la toile de confiance), c'est précisément l'aboutissement de DANE TLSA.

ÉDIT DU 14/01/2017 À 17H45 : ajout d'informations suite à la relecture de Stéphane Bortzmeyer. Merci. :) FIN DE L'ÉDIT.

Un bouquin écrit par François Elie (agrégé de philosophie, ancien conseiller municipal orienté NTIC d'Angoulême ;) ) qui nous présente l'économie du logiciel libre en insistant très lourdement sur ce qu'il considère être la prochaine vague c'est-à-dire la mutualisation par la demande afin que les clients de logiciels réalisent des économies et de faire émerger des logiciels métier en logiciel libre.

Ce livre date de 2009. Je l'ai acheté fin 2010 mais je ne l'avais pas encore lu jusqu'à aujourd'hui : des déménagements successifs l'avaient fait prisonnier dans des cartons durant de longues années. :D

Mon avis

Ce livre est intéressant pour quiconque ne s'est jamais vraiment intéressé au financement des logiciels libres (comme moi) et qui croit que le logiciel libre peut être financé uniquement par de l'assistance payante / double licence.

Le militantisme de l'auteur en faveur de l'émergence de la mutualisation par la demande afin de faire émerger des logiciels métier est très intéressante. Le livre explique très bien les blocages : problème d'image, problème d'intérêt à agir, etc. Je nuancerai en disant que l'auteur en attend à mon avis beaucoup trop de la puissance publique qui pourrait jouer le jeu, faisant ainsi des économies, ce qui ferait apparaître cette mutualisation par la demande.

Au-delà de ça, ce livre, qui mélange économie et parfois philosophie, est parfois un peu difficile à suivre par son côté très abstrait. Beaucoup de répétitions sont également à signaler.

Informations et analyses intéressantes :

• Dans le numérique, on confond le coût de production et celui d'une copie supplémentaire pour en arriver au mythe du tout gratuit. Si le deuxième est quasi nul (copier un PDF ne coûte rien, par exemple), la production initiale d'un livre, d'un journal, d'un film, etc. a un coût. Le numérique ne permet pas d'échapper à la question du financement de ce coût de production.
  
  
• Bonne comparaison avec les maths : Pythagore voulait des maths privatrices, ses élèves ne devaient rien dire de leur apprentissage. Aujourd'hui, on a de la R&D ouverte (universités), de la R&D privée puis publique (ingénieurs), des profs de maths et l'évidence même que les maths ne peuvent être brevetés.
  
  
• Logiciel libre : innovation, accumulation de la connaissance, recombinaison des savoirs pour produire quelque chose de neuf, résistance aux chocs par rapport aux oligopoles, possiblement renouvelé plus souvent, éviter les coûts cachés des logiciels sur mesure (passer à la caisse auprès du même prestataire qui fera chauffer la CB à la moindre demande de nouvelle fonctionnalité). Le logiciel libre sépare la solution de la prestation de service potentiellement nécessaire à son installation, intégration, paramétrage, assistance. Cela permet donc une double mise en concurrence. Le logiciel libre est un bien pérenne pour les administrateurs : l'assurance de pouvoir piloter les nouvelles fonctionnalités désirées.
  
  
• Pouvoir de demain : qui détient les moyens de production ? Est-ce que le codeur est exploité au sens marxiste du terme ? Quand on vend du service au-dessus d'un logiciel libre, on ne rémunère pas la production du code en elle-même et c'est un problème.
  
  

• François Elie analyse le "marché" du logiciel libre en trois acteurs : le développeur amateur (que l'auteur nomme hacker… … …), le marchand et le client. Tous trois poursuivent des intérêts forts différents : le premier cherche la reconnaissance, le deuxième espère un gain, le troisième espère faire des économies. Le développeur amateur et le marchand des alliés quand il faut dire au client que libre ne signifie pas gratuit. Marchand et client sont de mèche quand il s'agit de dire que bénévolat, ce n'est pas assez sérieux, qu'il faut de l'assurance, de la garantie, de la maintenance. Le développeur amateur et le client sont d'accord quand il s'agit de rappeler au marchand qu'il ne sert à rien d'être un crocodile ou un ogre. C'est de là que viennent les tensions.

  • L'auteur conceptualise 3 étapes dans la vie du logiciel libre. 3 écosystèmes différents organisés en vases communicants : au début était le libre pour le fun ensuite est apparu l'open source pour casser la barrière idéologique et ainsi atteindre les consommateurs et l'industrie puis apparaîtront les logiciels métiers pour casser les problèmes de gouvernance induits par l'externalisation de la production du code. Il n'y a pas de retour en arrière possible (l'open source ne disparaîtra pas au profit du seul logiciel libre, par exemple).
    
    
  • Derrière ces 3 étapes, on retrouve 4 formes génériques de financement dont 1 sera temporaire espère l'auteur : bénévolat, détournement du bénévolat par des marchands (temporaire), investissement classique, investissement coopératif (plusieurs clients autour de la table).
    
    
  • Plus précisément, quels modèles économiques ?
    • Bénévolat. Auquel je rajoute les dons que l'auteur passe sous silence. Pour l'auteur, ce modèle ne résiste pas au détournement, à l'appropriation par des sociétés commerciales qui ne reversent pas leur travail. L'auteur signale également que tout le monde ne veut pas bosser bénévolement (mais qu'à l'inverse, d'autres personnes ne veulent pas être payées afin de ne pas transformer une passion en quelque chose de sans intérêt si elle devient astreignante) et que la rémunération de la production de code demeure un problème.
      
      
    • Modèle de service : édition/intégration c'est-à-dire rencontre entre un client et un produit et on brode autour pour fournir des fonctionnalités supplémentaires (exemple : un logiciel comme WordPress ou SPIP est simple à installer (et livrer un installeur simple ne ruine pas l'espoir de monter un business orienté support) mais il faut un thème et des plugins pour qu'il fasse totalement ce qu'on veut) ; modèle de valeur ajoutée : on vend de la garantie ; modèle de la double licence (édition communautaire et édition corporate) qui discrimine les utilisateurs ou modèle n-1 (on livre à la communauté la dernière version qui n'est plus utilisée) ; formation, etc.
      
      
    • Mutualisation par l'offre (investissement classiques) : plusieurs acteurs mutualisent leurs efforts de R&D dans un modèle de coopétition. Cela engendre une baisse des coûts de la R&D assumée par chaque acteur. Exemple de mutualisation par l'offre : les progiciels de gestion. Avec eux, plus besoin que l'équipe informatique de chaque société commerciale code le même bout de soft.
      
      
    • Mutualisation par la demande (investissement coopératif et j'y ajoute le financement participatif) : les clients se regroupent en consortiums/associations/GIE/autre pour exprimer leurs besoins et développer ensemble les logiciels répondant à leurs besoins. Cela engendre des économies : la mutualisation de l'offre fait que les marchands vendent X fois les mêmes logiciels, les mêmes développements. Ce n'est plus possible avec des briques en logiciel libres avec une granularité fine. La mutualisation par la demande se frotte à un problème d'image : chaque société commerciale se croit unique sur son marché. Leur faire accepter l'idée d'utiliser le développement tout ou partiel d'une autre société, pouaaaaaaa, quelle idée, quel déshonneur !
• Coopétition : collaboration opportuniste entre des acteurs qui ont des intérêts divergents, qui sont des concurrents mais qui, pourtant, ont intérêt à bosser ensemble au moins sur une partie de l'histoire. Exemples : les formats de fichiers ouverts sont systématiquement les plus répandus dans des secteurs concurrentiels comme l'aviation et la pétrochimie car justement, il faut avoir la même procédure pour causer aux sous-traitants. Même chose pour l'interopérabilité : les géants ont intérêt à la prévoir dès la conception plutôt que de l'implémenter après-coup car ce deuxième cas coûtera plus cher.
  
  

• Le logiciel libre est partit des infrastructures (informatique générale pour l'informaticien) puis a conquis le middleware (informatique intermédiaire pour l'informaticien au service de quelqu'un genre genre un connecteur standard pour un SGBD). Pour les logiciels métier, c'est plus compliqué car personne n'a d'intérêt ce qu'ils soient libres à part le client : le marchand veut vendre du temps de travail donc il ne doit pas dire qu'il dispose de briques génériques pour développer le logiciel demandé et le bénévole ne voit rien de fun dans le développement d'un logiciel de gestion de la cantine scolaire ou de la gestion de stocks ou de celle d'un réseau de parcmètres, par exemple.

  • Je pense que l'auteur loupe tout un pan quand il associe les logiciels d'infrastructures au fun : pour faire communiquer des machines en réseau, il a forcément fallut fournir l'implémentation. À la fin des années 80, on voit bien que c'est la grouille sur la multitude de réseaux existants et que les informaticiens cherchent en permanence à écrire des passerelles de l'un à l'autre. Un besoin d'universalité s'exprimait très clairement. Or, on ne peut pas faire de la communication universelle à bas coût sans normes et sans implémentations communes. La question du fun ne s'est pas posée, àmha.
• Il est vain de forcer les administrations publiques à utiliser du logiciel libre : il faut qu'elles le produisent. Soit en interne, soit en se regroupant pour exprimer un cahier des charges commun et faire développer ça. Sans ça, on a un problème d'œuf et de poule : les administrations peuvent seulement utiliser les logiciels déjà existants et s'il n'y a pas les logiciels métiers bah lala, elles resteront en logiciel privateur (et c'était très précisément l'argument de la centrale d'achat de l'informatique hospitalière en 2015, par exemple ! Voir http://shaarli.guiguishow.info/?82JClA ). C'est pour cela que l'on a vu émerger des plateformes de mutualisation comme celle de l'ADULLACT.
  
  
• Pour voir l'émergence de logiciels métier, il faudra se regrouper par catégories d'acteur, pas par types de projets. Exemple : il y a environ 250 métiers dans une collectivité. Celle-ci ne va pas adhérer et prendre part à 250 consortiums/associations de mutualisation par la demande.
  
  
• Une des clés du succès de la migration de la gendarmerie nationale française vers le logiciel libre n'est-ellle pas qu'il y a eu une reconnaissance officielle des logiciels écrits en interne de manière bénévole ? Ces gendarmes informaticiens amateurs savaient au moins de quoi ils avaient besoin pour exercer.
  
  
• Dans le monde matériel, on achète un objet pour le posséder. Dans le monde immatériel, acheter peut signifier faire exister quelque chose pour les autres alors qu'ils n'ont rien fait pour que cela arrive. Et évidemment, ça pose un problème aux tenants de l'ancien monde.
  
  
• Éric Raymond imaginait déjà les "appels de demande" c'est-à-dire l'expression d'un savoir-faire : je peux mettre sur pied tel type d'infra pour tant d'argent, je peux développer tel type de soft pour telle somme. Cela me fait penser aux CVthèques sur lesquels les personnes à la recherche d'un emploi diffusent leur savoir-faire et où les recruteurs viennent piocher.
  
  
• En 2009, l'auteur identifiait 2 risques pour le logiciel libre :
  • Logiciel privateur 2.0 : puisque l'exclusivité du code ne procure plus de pouvoir, les sociétés commerciales seront attirées par la maîtrise de la roadmap, par l'arbitrage qui à le droit de commit et de piloter le projet ainsi que par l'architecture de la plateforme de collaboration. C'est ça qui générera du pouvoir et brassera de la thune. Les géants du logiciel privateur se positionneront là.
    
    
  • IaaS : faire oublier les logiciels et l'idée de vouloir les maîtriser, les modifier, tout ça. Faire de belles interfaces pour attirer les particuliers et proposer de l'externalisation à bas coût pour les sociétés commerciales et c'est gagné. Mais ça entraîne un pouvoir sur les données personnelles.

Alain Juppé (Les Républicains) écrit dans son projet présidentiel qu’il souhaite « faire pression sur les fournisseurs d’accès à Internet pour qu’ils fournissent les clés de déchiffrement des logiciels cryptés utilisés par les terroristes ».

La vidéo explicative du Monde est superficielle : oui, ça ne sert à rien car les FAI n'ont pas les clés. Mais, contrairement à ce qu'indique le Monde, aller toquer chez Telegram ou WhatsApp ou autre fournisseur de service de messagerie, c'est tout aussi inutile : il va y avoir des complications juridiques "pas le même droit applicable, coopération internationale vaseuse" et cela fera migrer les honnêtes citoyen-ne-s ET les criminel-le-s vers des services de messagerie chiffrée de bout en bout dans lesquels seul-e-s les utilisateur-rice-s ont les clés comme TextSecure ou Signal. Cela aura donc pour effet de rendre encore plus aveugle toute forme de police/gendarmerie/brigades antiterrorisme/etc.

De même que les "points en clair" (allez savoir ce que c'est vraiment) désirés par le gouvernement actuel en 2015 sont une hérésie : si le chiffrement est enlevé à un quelconque moment de la communication, alors il n'y a plus de confiance dans le système de chiffrement et on a alors une atteinte au secret de la correspondance donc nous ne serions plus dans une démocratie. C'est là le vrai problème : il est d'ordre éthique, pas technique.

Ha ouais… L'histoire des 5 millions d'euros provenant de Kadhafi collectés par Sarko pour sa campagne de 2007 se précise avec des témoignages concordants. On est loin des 50 millions d'euros annoncés mais c'est un début. Du coup, je ressors ça : http://taule.riotparis.com/ - « Est-ce qu'il va bientôt en taule ? ». :)

Le seul truc qui me fait tiquer, c'est les motivations de Takieddine : pourquoi balancer ça maintenant et pas avant ? En s'auto-incriminant. Que cherche-t-il, qu'a-t-il à y gagner ?

Dans un entretien filmé avec Mediapart, Ziad Takieddine, l’homme qui a introduit Nicolas Sarkozy auprès de Mouammar Kadhafi, avoue avoir apporté au ministère de l’intérieur, fin 2006 et début 2007, plusieurs valises d’argent liquide préparées par le régime libyen, pour un montant total de 5 millions d’euros. [...]

[...]

[...] Ziad Takieddine décrit avec précision la livraison des valises d’argent libyen au ministère de l’intérieur, place Beauvau. Il déclare les avoir remises à deux reprises à Claude Guéant, alors directeur de cabinet du ministre, dans son bureau, puis une troisième fois, en janvier 2007, à Nicolas Sarkozy en personne, dans l’appartement privé du ministre de l’intérieur.

[...]

Les valises d’argent que Ziad Takieddine s’accuse d’avoir transportées à Paris lui auraient été remises à Tripoli par l’un des chefs des services secrets libyens, Abdallah Senoussi, un proche de Mouammar Kadhafi dont il était le beau-frère par alliance.

Le même Senoussi qui torturait des opposant-e-s avec les systèmes de surveillance de masse électroniques fournis par la France.

[...]

Lors de son audition devant la CPI [NDLR : Cour Pénale Internationale ] le 20 septembre 2012 (récemment transmise aux juges français), l’ancien dignitaire libyen affirmait avoir « personnellement supervisé le transfert » d’une somme de 5 millions d'euros, « pour la campagne du président français Nicolas Sarkozy en 2006-2007 ». Il précisait que ce transfert avait été réalisé « via un intermédiaire français, en la personne du directeur de cabinet du ministre de l’intérieur » et « un second intermédiaire, le nommé Takieddine, un Français d’origine libanaise installé en France ».

[...]

Abdallah Senoussi était, côté libyen, l’un des artisans du rapprochement Kadhafi-Sarkozy. Il espérait que la France pourrait l’amnistier, ou en tout cas revenir sur la condamnation à perpétuité prononcée contre lui à Paris, en 1999, dans l’affaire de l’attentat contre le DC-10 d’UTA. Nicolas Sarkozy et son équipe en avaient non seulement accepté le principe, mais ils avaient confié le dossier à Thierry Herzog, l’avocat personnel du ministre devenu président, comme Mediapart en avait apporté la preuve ici.

Merci à Slash pour le rappel.

La légalité du décret est assise sur un ensemble législatif ancien, porteur, en lui-même, des dangers que ce fichier TES met brutalement en lumière aujourd'hui. L'article 27 de la loi dite « informatique et libertés » de 1978 laisse au gouvernement la faculté d'instituer, par un simple décret, tous traitements de données à caractère personnel pour le compte de l'État, ou touchant à la sécurité nationale. Pire, depuis 2004, les données biométriques sont soumises au même régime, au mépris de leur sensibilité extrême. De cette honteuse manœuvre, notre démocratie devrait tirer toutes conséquences : l'absence de contrôle parlementaire sur la création de fichiers concernant les individus par l'exécutif doit être combattue.

[...]

[...] Entre l'origine d'un fichier et son utilisation ultérieure, il y a systématiquement des dérives : changement de finalité, érosion progressive du contrôle, modification du champ d'application ou de l'étendue des accès à ce fichier... Même suite à des condamnations, y compris par la Cour Européenne des Droits de l'Homme, les fichiers ne sont pas, ou peu et tardivement corrigés. La France a été condamnée en 2013 par la CEDH pour le FAED (Fichier Automatisé des Empreintes Digitales) au motif que « La conservation des empreintes digitales par ce fichier s’analyse en une atteinte disproportionnée, ne peut passer pour nécessaire dans une société démocratique, et ne traduit pas un juste équilibre entre les intérêts publics et privés concurrents en jeu ». Pourtant ce fichier n’a été corrigé à la marge que deux ans après l'arrêt de la CEDH. Quant au FNAEG (Fichier National Automatisé des Empreintes Génétiques) créé pour ficher les auteurs d'infractions sexuelles condamnés par la justice, il est passé en 15 ans d'un fichier sous contrôle judiciaire et limité à un fichier policier recueillant l'ADN de toutes les personnes simplement suspectes dans les enquêtes pour les délits les moins graves, même sans condamnation et dont le refus de prélèvement est susceptible de constituer un délit.

[...]

Le choix de la centralisation du fichier est un choix dangereux : il expose un ensemble massif et précieux de données personnelles à la portée de puissances hostiles ou de criminels expérimentés. Les promesses réitérées de chiffrement robuste et de sécurisation avancée faites par le ministre de l'Intérieur seront évidemment invérifiables, et pourront difficilement compenser l'absence de résilience qu'aurait apportée une décentralisation du fichier, soit au niveau du porteur individuel de titre d'identité, soit au niveau des différentes composantes du fichier. Choisir la centralisation des données d'identification de l'ensemble des Français c'est choisir d'être une cible très alléchante, comme l'ont montré les attaques subies par des bases de données israéliennes, turques ou philippines. La question n'est donc pas : TES sera-t-il attaqué, mais : quand le sera-t-il ?

[...]

Si la volonté d'empêcher techniquement toute falsification peut sembler légitime, l'histoire nous rappelle combien la capacité à résister à des dérives autoritaires passe par la faculté d'échapper au contrôle étatique, notamment sur son identité. Les fichiers centralisés ne font pas les régimes autoritaires, mais tout régime autoritaire s'appuie sur un fichage de sa population. L'ajout de nombreux marqueurs biométriques aux éléments de filiation ou d'état civil renforce l'attachement de l'individu, par son corps, à l'État. Nul ne peut exclure des usages liberticides d'un tel fichier à l'avenir, et toute évolution vers plus d'identification devrait être discutée démocratiquement dans cette perspective.

Un problème classique du système de cryptographie OpenPGP, normalisé dans le RFC 4880 est de vérifier les clés publiques des correspondants. Les trouver, c'est relativement facile : le correspondant pense à vous les envoyer ou bien on se sert tout simplement d'un serveur de clés. Mais ceux-ci ne garantissent rien sur la clé. N'importe qui peut créer une clé marquée flotus@whitehouse.gov et la mettre sur les serveurs de clé, même si cette clé n'a rien à voir avec la Maison-Blanche. [...] Que propose ce RFC ? De mettre les clés dans le DNS (nouveau type d'enregistrement OPENPGPKEY), dans le domaine de la partie droite de l'adresse de courrier, sécurisée par DNSSEC. En gros, il s'agit de faire pour le courrier et PGP ce que fait déjà DANE (RFC 6698) pour le Web/TLS.

Les serveurs de clés utilisent le protocole HKP (jamais décrit dans un RFC). Ils fournissent un service très utile en permettant de chercher une clé, par son identificateur, ou par l'adresse de courrier associé. [...]

Ces serveurs n'offrent aucune garantie : n'importe qui peut y publier une clé, avec n'importe quelle adresse et certaines clés sont clairement mensongères. L'usage normal est de récupérer la clé et ses signatures, puis de vérifier les signatures. Si elles sont faites par des gens qu'on a validés (directement, ou bien transitivement, jusqu'à une certaine profondeur), on estime la clé correcte (c'est ce qu'on nomme le web of trust). Autrement, la clé ne vaut rien. En outre, le seul système de révocation est de signer une révocation avec sa clé privée : si on l'a perdue, on ne pourra jamais retirer la clé des serveurs de clé. Pour ces deux raisons (fausses clés, et clés devenues inutilisables), il est donc difficile d'utiliser automatiquement, depuis un MUA ou un MTA, ces serveurs.

Mouiiii… en pratique la toile de confiance est plutôt décriée car elle rend vulnérable aux vérifications effectuées par les relations en commun : comment ces personnes ont-elles signé les clés ? Selon quels critères ? Peut-on avoir confiance en leur processus ? La méthode préférée reste la signature lors d'une rencontre AFK ou lors d'une signing party.

La solution proposée dans ce RFC est, comme souvent aujourd'hui, d'utiliser le DNS, qui a montré sa fiabilité et son ubiquité. Tout le monde peut faire des requêtes DNS, même coincé derrière un pare-feu, et tout le monde peut les valider, grâce à DNSSEC (RFC 4035).

[...]

La solution de ce RFC rend envisageable de récupérer et de vérifier automatiquement une clé avant l'envoi d'un message. Mais le RFC note bien qu'elle ne remplace pas complètement le web of trust, qui reste nécessaire si on veut une vérification sérieuse.

La section 2 de notre RFC décrit le format du nouveau type d'enregistrement DNS. Chaque enregistrement contient une et une seule clé. Si un utilisateur a plusieurs clés, il doit créer plusieurs enregistrements. Le type est 61 (et enregistré à l'IANA depuis août 2014). La partie droite de l'enregistrement (les données) contient la clé et au moins un ID et une auto-signature. Les clés PGP complètes, avec des tas de signatures, peuvent être grosses, trop pour le DNS ; le RFC recommande de ne publier que des clés minimales (pas trop de signatures, par exemple, et évidemment pas les photos qu'on peut inclure dans un attribut de la clé, cf. RFC 4880, section 5.12.1). [...] gpg --export --export-options export-minimal,no-export-attributes

Le format utilisé est celui du RFC 4880, section 11.1. C'est donc du binaire qui circule sur le réseau (rappelez-vous bien que, dans le DNS, le format de présentation, celui des fichiers de zone, et de la sortie de dig, n'a rien à voir avec le format binaire utilisé sur le réseau.) [...]

Et la partie gauche de l'enregistrement DNS ? Quel est le nom de domaine utilisé ? La section 3 du RFC fixe les règles :

• Le domaine de l'adresse de courrier (partie droite de l'adresse de courrier) est celui où on met les enregistrements DNS OPENPGPKEY. La clé pour l'adresse stephane+chose@trucmachin.example sera donc dans la zone trucmachin.example.
  
  
• Le nom de domaine sera la concaténation d'un condensat de la partie gauche de l'adresse de courrier (stephane+chose, dans l'exemple ci-dessus), et du composant _openpgpkey, avec le domaine de l'adresse de courrier (trucmachin.example dans l'exemple ci-dessus). Le condensat est tronqué à 28 octets. (Le nom de domaine n'est pas utilisé dans le condensat, pour faciliter la vie des opérateurs qui proposent la même adresse dans différents domaines.)
  
  
• En fait, la règle est plus compliquée en raison des équivalences entre certains caractères (voir les exemples plus loin). Une correspondance est donc faite pour certains caractères. (Ce fut l'un des points les plus discutés dans le groupe de travail à l'IETF.)
  
  
• Par exemple, les guillemets (oui, "jipoune le meilleur"@example.com est une adresse de courrier légale) sont retirés.
  
  
• La condensation de la partie gauche de l'adresse de courrier est faite en SHA-256 (RFC 5754). Cela permet une protection limitée (cf. section 7.4) de la vie privée : même si un méchant met la main sur tout le fichier de zone, il ne trouvera pas facilement toutes les adresses (qui sont des données personnelles). Mais le but principal de cette condensation est de résoudre le problème de certains caractères qui sont permis dans la partie locale d'une adresse de courrier, mais qui posent des problèmes dans le DNS.

YOLO ! \o/

[...]

Une des difficultés pour trouver le bon nom de domaine est que les applications doivent traiter la partie gauche des adresses de courrier comme opaque (pas le droit d'analyser sa structure) et qu'elles ne connaissent pas les règles de canonicalisation qu'appliquera le domaine de destination, comme d'ignorer la casse de la partie locale (ce qui est souvent fait, mais pas toujours). Par exemple, Gmail ignore les points dans les adresses (donc foobar@gmail.com et foo.bar@gmail.com arrivent dans la même boîte aux lettres). L'émetteur qui ne connait pas cette règle va chercher la clé dans un domaine qui ne sera pas le bon. Idem avec les sous-adresses utilisées par certains domaines (en général avec le séparateur plus, comme stephane+blog, stephane+ietf, etc). Le RFC rappelle que l'émetteur ne peut pas se permettre de deviner ces règles locales, et qu'elles peuvent changer à tout moment. C'est au destinataire de se débrouiller, en publiant la clé à plusieurs noms, et en faisant attention aux variantes qu'il publie.

[...]

Autre problème de sécurité, cette fois lié à la vie privée : les requêtes DNS révèlent avec qui on veut communiquer de manière sécurisée par courrier (RFC 7626). Le fait que le nom de domaine utilisé soit un condensat de la partie locale de l'adresse de courrier limite un peu les risques, mais pas suffisamment (si on soupçonne qu'Alice écrit à bob@example.com mais qu'on n'en est pas sûr, il suffit de construire le nom où se trouve l'enregistrement OPENPGPKEY et de vérifier que ce nom est demandé, cf. section 7.4). C'est d'autant plus grave que les clients DNS actuels envoient en général le nom de domaine complet à tous les serveurs, même ceux qui n'en ont pas besoin. La minimisation de la requête (RFC 7816) limite ce problème. Le chiffrement des requêtes DNS (RFC 7858) peut faire le reste. Le cache du DNS limite un peu les risques et il est donc essentiel de ne pas faire une requête DNS externe à chaque fois qu'on envoie un message PGP à quelqu'un, cela ferait fuiter bien trop d'informations (section 7.5).

Pour limiter les risques qu'un attaquant récolte toutes les adresses de courrier du domaine, le RFC recommande de signer la zone en utilisant NSEC3 (RFC 5155).

[...]

Où en sont les mises en œuvre de ce RFC ? GnuPG contient le code pour gèrer ces clés dans le DNS depuis la version 2.1.9. Même chose pour openpgp-milter. L'outil hash-slinger permet quant à lui de générer et de vérifier des enregistrements OPENPGPKEY .

Bien évidemment, ces agents sont individuellement désignés et habilités et en théorie, leur accès est réduit à un nombre limité de finalité.

En théorie …

Car chacun sait que les premiers abus d’accès à tels traitements, viennent de l’intérieur.

Il est tout à fait humain et tentant, de consulter la fiche de son voisin avec lequel les relations ne sont pas toujours au beau fixe.

On peut aussi s’amuser à consulter des célébrités.

On peut aussi rendre un service … Après tout, ça n'est pas méchant et c’est très valorisant. En réalité, la chose ne paraît pas grave.

Il est très difficile voire quasi impossible de prévenir de tels comportements, l’abus venant de l’intérieur c’est-à-dire de ceux connaissant intimement le fonctionnement du système.

A la NSA, cette pratique a même un nom. On l’appelle la LOVEINT par référence à l’usage par lequel on utilise son accès pour son partenaire amoureux, sa compagne ou son compagnon.

Dans son livre « Data and Goliath », Bruce Schneier évoque cette pratique illégale mais qui peut ne pas être sans conséquence pour les personnes concernées.

Citant Edward Snowden et un audit de la NSA réalisé sur 12 mois entre 2011 et 2012, il révèle que cette pratique aurait été relevée durant cette période 2.776 fois.

Il ajoute que le chiffre devrait être bien plus important, car les chiffres venaient de la NSA elle-même …

Bien évidemment, plus le fichier est gros, plus le nombre de personnes autorisées à y accéder est important, plus le risque est grand de voir se développer le LOVEINT.

Il n’y aucune raison que ce type de comportements se limite d’ailleurs aux fichiers publics, et on n’ose imaginer ce qui se passe dans certaines grandes entreprises d’outre Atlantique, aspirateurs de donnée à caractère personnel venant du monde entier et renfermant toutes sortes de renseignements.

Très bon argumentaire. :)