GuiGui's Show

Émission spéciale de Data Gueule à l'approche de la COP 21. Angle d'attaque intéressant : faire s'exprimer des gens, contre-argumenter sur les préjugés habituels, laisser à nouveau la parole,...

« Que le climat change, la planète elle n'en a rien à faire du climat qui change, elle s'en fout hein, c'est nous qui avons des problèmes. »
=> Gros +1

Il y a toujours eu des changements climatiques mais celui-ci va trop vite et a des conséquences sur le vivant. Un changement climatique trop rapide est en marche, on peut éviter le pire, minimiser les dégâts mais ça prendra du temps pour revenir à ce qu'on a connu avant... sans garantie que ça soit possible (exemple : fonte des glaces pas réversible ?). Il n'y aura pas de phénomènes spectaculaires pour nous prévenir, ça va nous péter à la gueule progressivement...

Historique : avant le 18e siècle : charbon coûte cher car les mines sont noyées en permanence -> apparition du moteur atmosphérique en 1712 -> prix du charbon baisse car la production augmente -> fer devient acier et sert aux premiers rails -> UK go en Inde pour coton -> machine à tisser plus productives que les humains -> toujours plus d'usines -> crédit à la conso apparaît pour soutenir la consommation -> conso de masse -> effort de guerre 1918/1939 -> remplacer effort de guerre pour que les infras (pipelines) soient rentabilisés. Aujourd'hui, 80% de notre énergie provient toujours des énergies fossiles -> gisements gaz/pétrole s'épuisent -> on en trouve d'autre mais il faut plus d'énergie pour extraire -> heureusement (ironie hein), 40 milliards de barils de pétrole et 30000 milliards de m³ de gaz nous attendent dans l'Arctique -> guéguerre Russie versus USA portant sur l'appartenance du territoire à prévoir.

Insécurité climatique :
    * Le changement climatique a un impact sur la disponibilité des ressources naturelles et sur l'intégrité des territoires. Cela conduit à des conflits entre les États et à l'intérieur des États ;
    * Le changement climatique rend encore plus vulnérable les populations déjà vulnérables. Double peine ;
    * Le changement climatique affecte aussi l'environnement et la biodiversité ;
=> Le changement climatique est aujourd'hui perçu comme une menace à la paix et à la sécurité internationale à l'ONU.

Exemples :
    * Nigeria : changement climatique -> sécheresses -> diminution de la ressource "eau" -> des populations vulnérables dépendantes de l'agriculture doivent migrer -> foyers de gens vulnérables facilement récupérables politiquement -> instabilité politique -> Boko Haram ;
    * Syrie : changement climatique -> sécheresses -> migrations intérieures -> favorise le conflit existant -> cause principale des migrations vers l'Europe qui est aujourd'hui perçu comme étant problématique.


COP 21 :
    * Négociations en amont dans le plus grand secret (les ONG ont été priées de quitter les salles de réunion afin "d’accélérer le processus"). Les États semblent plutôt avoir peur qu'on publie leurs intentions car elles ne correspondent visiblement pas à ce qu'attend la société civile ;
    * Le travail actuel traîne. Le pré-texte actuel est sans force, sans engagement. On y retrouve les tournures floues habituelles pour noyer le poisson ;
    * Les négociateurs mandatés par les États ont des mandats extrêmement restrictifs qui ne leur permettent pas grand-chose.


Pourquoi on est réticent au changement ? La prise de décision dépend de deux parties de notre cerveau : le système cognitif, plus primitif mais plus développé et le système émotionnel. Le deuxième est rapide et sert aux décisions intuitives. Le premier est lent et a une capacité de traitement limitée mais permet d'anticiper les conséquences de nos actions/décisions. Une prise de décision efficace nécessite une bonne interaction entre ces deux systèmes. Le problème ? On n'a pas l'expérience émotionnelle d'un réchauffement climatique. D'où une appréhension difficile de la problématique. Plus généralement, comme le système cognitif a des ressources de traitement limitées, il cherche à rendre tout comportement le plus habituel possible et cherche donc en permanence à construire des habitudes. Le changement a donc un coût mental.


Le vrai problème de fond, beaucoup plus philosophique, c'est qu'on s'est mis à penser que le seul moyen de développer son humanité, c'est de consommer. Il faut changer cela. Ça nécessite de se poser des questions : qu'est-ce qu'être humain ? Vivre en harmonie avec la nature, etc.

Il faut agir et repenser l'éducation (d'un esprit de compétition vers un modèle de coopération, apprendre à apprendre, accompagner les nouvelles têtes dans leur exploration intellectuelle, développer l'esprit critique,...)... et sur la politique. Les structures politiques vont devoir évoluer. Tant que les intérêts privés seront supérieurs à tout, on n'arrivera à rien. Exemple : en parallèle de la COP 21, TAFTA/TTIP qui veut encore et toujours plus libéraliser et mondialiser les échanges commerciaux entre les deux rives de l'atlantique. Les États sont devenus des facilitateurs des échanges commerciaux donc ils ne peuvent plus rien faire car ils font partie du système à changer, de la cause du problème. Une lutte contre le réchauffement climatique est engagée et elle est en étroite relation avec un changement des systèmes éducatifs et des appareils politiques.


Mais, l'heure n'est pas au désespoir : des alternatives, des initiatives existent et d'autres voient le jour. C'est cela qui, additionner à une envie collective, changera le monde.

Merci à Karchnu et Nosheep pour avoir fait circuler ce documentaire.

« Les massacres parisiens perpétrés par des terroristes fanatiques sont politiques. La classe politique française tente, à l’aune de l’ampleur du drame, d’évacuer ses responsabilités. L’unité affichée a un objectif principal : camoufler les raisons purement politiques de cette attaque, et surtout, les racines de celles-ci.

Analyse de la construction d’une « guerre » intérieure en cours, et des guerres extérieures fabriquées par des politiques françaises désastreuses.

[...]

Une autre origine de cette politique pro-arabe, parfaitement établie, et importante, est la spécificité française en termes d’immigration.

La France s’est servie de millions de personnes des colonies et protectorat au sortir de la seconde guerre mondiale pour reconstruire le pays, puis après les indépendances, pour assurer sa suprématie économique nécessitant une main d’œuvre nombreuse, docile et francophone. Après le choc pétrolier de 1974 la population d’immigrés issus des ex-colonies et protectorats du Maghreb était suffisamment importante pour compter, tant d’un point de vue économique que politique. Procéder à une politique pro-Israël, anti-arabe avec des millions de personnes d’origine arabe sur son territoire — et naturellement favorables aux Palestiniens colonisés, ou aux populations des pays arabes en général — est une mauvaise idée. Dont l’Etat français ne s’est pas emparée durant plusieurs décennies.

[...]

1991 aurait pu devenir un moment politique très difficile en France, de par la participation du « pays des droits de l’Homme » aux bombardements en Irak. La population française d’origine arabe voyait, en partie, d’un très mauvais œil l’ingérence française causant de nombreux morts parmi des populations arabophones irakiennes. L’invasion illégitime du Koweit par l’armée de Sadam Hussein, l’arrêt des hostilités suite à son retrait militaire permirent de calmer le jeu. Les choses en restèrent là. Mais ce fut un premier accroc dans la politique arabe de la France. L’accroc fut d’ailleurs temporairement effacé par l’intervention à l’ONU de Dominique de Villepin en 2003, refusant de faire participer la France à une guerre illégitime en Irak, ayant pour vocation de détruire un Etat arabe afin de s’y imposer. Jacques Chirac, ami des grands dirigeants du monde arabe savait très bien ce qu’il faisait. Chirac savait aussi ce qu’aurait pu déclencher sur le territoire français, au sein des population françaises d’origine arabe, un tel message politique, un tel engagement forcément meurtrier et totalement injustifié.

[...]

La loi sur le foulard musulman (et non le voile islamique), avec son débat interminable, menant à celle des « signes distinctifs religieux » en 2004, entame alors une longue et douloureuse modification en profondeur de la société française. Les émeutes de 2005 viennent marquer cette orientation,  le clivage social, politique, menant entre autres à la « poussée religieuse » des ghettos français. Si des tendances à des formes de radicalisation religieuses pouvaient exister, les provocations politiques marquées par des lois stigmatisantes et hypocrites n’ont eu qu’un seul effet : l’amplifier.

[...]

Les lignes rouges à ne pas franchir l’ont toutes été par ce président. L’accueil de Mouhamar Khadafi en grande pompe à L’Elysée en est une première : le chef d’un Etat terroriste, ennemi juré de la plupart de ses voisins arabes, dictateur infréquentable et isolé sur la scène internationale, devient l’ami de la France… Suivra Bachar El Assad, chef d’Etat autoritaire s’il en est, de confession chiite et ami des Iraniens eux-mêmes isolés par un embargo international et honnis par la France. [...] Jusqu’au sauvetage des infirmières bulgares par la visite en Libye de l’épouse du président français, avec au final, le déclenchement de la guerre… de Libye.

La France devient à cet instant, alors qu’elle tente de soutenir en parallèle le président tunisien despotique Ben Ali — jusqu’à sa destitution et sa fuite grâce à la première révolution populaire du monde arabe — un acteur de la « scène politique arabe » totalement différent. Sarkozy continue le clivage incohérent de sa politique extérieure en apportant son soutien marqué à Israël à plusieurs reprises. [...]

La création d’un djihad international bien armé dans la région du Sahel devient possible par la destruction de la Libye et de toutes ses structures institutionnelles. La France se retire et laisse dans les cendres libyennes encore fumantes se déployer des groupes armés profitant d’un chaos généralisé. Viendra la réponse militaire française, encore une fois, au Mali pour endiguer… une situation créée par l’intervention française libyenne. Mais la Syrie a déjà commencé à être déstabilisée.

[...]

La ruée sunnite-wahhabite pour déboulonner le pouvoir chiite syrien est en cours depuis 2011. Al Quaïda est de la partie, et personne, parmi les grandes puissances, France en tête, ne veut avouer cette réalité. Les massacres ordonnés par Bachar el Assad s’additionnent à ceux des factions salafistes. François Hollande, fort de ses victoires militaires au Mali, en Centrafrique, ayant approuvé l’intervention en Libye de son prédécesseur, se précipite avec l’intention de bombarder Damas suite au gazage de la population. Laurent Fabius affirme vouloir « armer les factions rebelles ». La France est en train de se mêler d’une guerre civile, religieuse et activée par ses alliés des monarchies pétrolières du Golfe… alors que personne ne lui demande rien.

Le refus de Barak Obama empêchera les bombardements français.

[...]

A l’été 2014, François Hollande soutient le chef du gouvernement israélien Benyamin Netanyahu qui ordonne le massacre de plus de 2000 civils de la bande de Gaza par des bombardements. La politique arabe de la France n’existe plus. Les relations diplomatiques et économiques avec les plus grandes théocraties du Golfe s’intensifient : les banquiers des milices intégristes de Syrie (l’Arabie Saoudite et le Qatar) sont des interlocuteurs privilégiés de la France, qui pourtant, soutient leur ennemi, Israël. La France qui soutient aussi les rebelles salafistes, mais qui devient leur ennemie lorsque ceux-ci deviennent des membres de l’Etat islamique. Le Calife auto-déclaré de l’EI avait prévenu : les pays qui se mêleraient de les attaquer, en aidant les Etats-Unis, deviendraient des ennemis à abattre.

[...]

Les Français qui ont massacré plus de 130 personnes à Paris vendredi 13 novembre ont lancé un message politique : sur l’action de François Hollande en Syrie et plus globalement sur la politique étangère de la France dans le monde arabe. La revendication du Califat vient appuyer les mots des tueurs. Une infime fraction de la population occidentale s’est fanatisée, puis vassalisée à un projet politique, celui du Califat islamique. Les dirigeants français ont choisi, depuis plusieurs années, de pratiquer une politique étrangère similaire à celles des Etats-Unis, basée sur l’ingérence, la manipulation diplomatique avec des parties opposées, et la domination étrangère par l’action militaire.

Le risque d’engendrer des réponses violentes et aveugles, lorsqu’un pays participe lui-même à des actions violentes et aveugles pour renforcer ses seuls intérêts, est grand. Si jusqu’alors l’ennemi était lointain, ne pouvait réagir, ce n’est plus le cas aujourd’hui. Les forces radicales de l’islam politique wahhabite ont trouvé des failles. Et celles-ci sont simple. Elles s’appellent le désespoir. La rage. La folie meurtrière. L’aveuglement. La conviction de « partager un projet commun », même s’il est destructeur et monstrueux. Toutes ces possibilités présentes dans une partie de la jeunesse occidentale, la plus influençable, la plus manipulable.

Les prêcheurs de mort du wahhabisme sont financé par les mêmes à qui l’on déroule le tapis rouge à l’Elysée. L’argent des wahhabites fait vivre une partie des agents terroristes intérieurs (et leurs proches), des agents illuminée, prêts à se sacrifier au nom de leur « cause ». Le message du Califat est terriblement clair. Les citoyens devraient demander à leur classe politique de faire son devoir d’inventaire. Pactiser avec le diable ne peut que vous jeter en enfer.

Un enfer de balles et de sang, qui comme d’habitude en politique, ne touche que la population, innocente et impuissante. »

« Amesys s’installe un peu plus au Canada et l’on apprend que l’entreprise bénéficie de fonds publics là-bas aussi (après la BPI via Bull en France). Tout va bien, continuons le business, il ne s’est rien passé.

En France, surprise, qui est invité à discuter de la transformation numérique au sein de la DigiWorld Week à Montpellier ? Thibaut Bechetoille lui-même. Le patron de Qosmos. Tout sourire… »

:((((

« C’est bien sous cet angle particulier que nous avons étudié la proposition de régulation de l’ARCEP sur le marché des RIP en fibre optique.

Notre réponse insistera sur trois points, qui nous paraissent essentiels. Nous commencerons par rappeler la nécessité d’offres activées, puis nous avancerons nos souhaits en termes de tarification, pour finir par l’analyse des conditions d’accès aux RIP pour les petits opérateurs.

[...]

La Fédération FDN considère que la disponibilité de ces offres activées est une nécessité. D’une part les textes européens encouragent les RIP à proposer des offres activées et permettent au régulateur d’intervenir. D’autre part l’ARCEP a pu constater que le marché seul ne fait pas apparaître ces offres sur les zones très denses ou les zones AMII. Il est donc nécessaire que le régulateur intervienne comme les textes européens le prévoient.

[...]

Il est indispensable que la technologie mise en œuvre dans le cadre d’une offre activée ne soit pas de nature à interdire la réplication des offres d’autres FAI sur le réseau. Par exemple, limiter les offres activées à 100Mbps là où des offres GPON sont possibles, ou bien imposer exclusivement une offre « clé en main », qui ne permettrait pas aux FAIs de jouer leur rôle et ce sans surcoût infondé. Dit autrement, il ne s’agit pas seulement de proposer des offres activées, il faut aussi que celles-ci soient techniquement comparables pour l’utilisateur final à d’autres offres. Sans quoi, ce dernier se détournera naturellement à terme des offres activées proposées dans le cadre du RIP et se tournera vers d’autres.

[...]

Un catalogue de référence au niveau national serait l’occasion de mettre en place un SI commun pour les tests d’éligibilité et un mécanisme générique pour la gestion de commandes/résiliations de lignes sur le territoire. Le traitement de la portabilité dans le mobile peut servir de modèle en ce sens : le système imposé par l’ARCEP a permis de fluidifier le marché.

[...]

Une telle plateforme nationale, nécessaire, doit être capable d’accueillir la commercialisation des offres des zones denses et très denses des opérateurs qui le souhaitent. Elle constitue un incitatif puissant à faire apparaître des offres activées sur l’ensemble des réseaux, et une bonne incitation à la normalisation des échanges. Elle pourrait par exemple servir de base de travail pour l’ensemble des échanges entre opérateurs, et apporter à terme plus de choix pour l’utilisateur final.

[...]

Donner aux petites structures locales la possibilité d’opérer sur des réseaux de ce type permet en effet de soutenir leur activité, la concurrence (il n’y a pas qu’un opérateur présent sur le réseau mais quatre ou cinq). C’est également un outil nécessaire à l’existence d’une économie numérique locale : les grands opérateurs ne vont pas installer leurs équipes d’ingénierie IP dans toutes les régions de France, les compétences en matière de réseau ne peuvent être présentes sur un territoire que s’il y a des acteurs économiques. Les FAIs sont au nombre des acteurs nécessaires.

La Fédération FDN n’est actuellement présente sur aucun RIP. Les raisons sont de deux ordres : ou bien relevant des difficultés administrativo-politiques, ou bien relevant des problèmes tarifaires.

[...]

Malgré nos demandes, de nombreux opérateurs refusent encore d’entrer en relation commerciale avec de petits opérateurs (associatifs ou non), qui sont vus comme « peu crédibles » malgré leur statut d’opérateur L33-1 et leurs actions sur le terrain, ou leur longévité. Ceci passe par le refus de transmission du catalogue de service, par l’absence de réponse aux sollicitations commerciales, ou encore par la mise en avant de solutions intégrées inadaptées et qui ne font pas partie du catalogue public. Ces cas de refus sont le plus souvent le fait du délégataire, et ne sont possibles que par absence de contrôle du déléguant et/ou du régulateur.

[...]

À l’heure actuelle, de nombreux RIPs pratiquent de manière plus ou moins discrète des tarifs, certes identiques pour tous les acteurs, mais qui sont des tarifs d’éviction. Même dans le cadre d’une offre passive, une clause qui stipule qu’un opérateur doit acheter de la présence dans tous les NROs de la zone suffit, par la masse de l’investissement qu’elle demande, à évincer les petits acteurs.

De la même manière, l’introduction de coûts cachés, le plus souvent en marge du catalogue officiel public du RIP, permet de rendre inutilisable une offre activée. Ainsi, un délégataire qui ne peut faire la livraison que dans ses propres locaux, et y loue l’emplacement du routeur de collecte à un prix, hors catalogue du RIP, déraisonnable, ou qui se retrouve en situation de monopole sur les liens de raccordement pour la remontée du trafic ; peut unilatéralement évincer de ce marché les clients-opérateurs qui n’ont pas son aval. C’était la norme sur les RIPs ADSL.

[...]

L’analyse des grilles tarifaires des RIPs devrait se faire, pour chaque offre, avec un critère supplémentaire, qui permet de rendre plus lisibles au régulateur certains phénomènes. Ce critère est celui du coût, tout compris, du raccordement de la première prise du premier abonné.

Ainsi sur un RIP qui ne fournit que des offres passives, avec un minimum de commande, et qui demande l’équipement de dizaines de NROs à l’ouverture du contrat, tous ces coûts sont pris en compte, et ce ticket d’entrée indique bien que ce n’est pas seulement le nombre d’abonnés potentiels qui est à prendre en compte, mais bien la capacité de poser quelques millions d’euros sur la table le premier jour. Une PME locale, même avec une excellente croissance et une excellente gestion, ne pourra pas arriver sur cette offre. Une association non plus.

De la même manière, sur une offre activée, les frais de location de la porte de collecte, et les coûts cachés (raccordement du point de livraison, location de l’emplacement en baie de la porte de collecte, minimum de facturation de tel ou tel élément, éléments imposés par le délégataire qui ne figurent pas au contrat de DSP, etc) forment ce prix de la première prise.

Ce n’est pas le seul élément d’analyse des offres, bien entendu. Mais c’est un critère utile. Et c’est par ailleurs un critère qui peut être contrôlé par la suite. L’analyse faite par l’ARCEP de la grille tarifaire d’un RIP, nécessairement rendue publique selon nous, permet aux acteurs locaux de repérer que l’offre présentée au régulateur n’était pas sincère quand certains coûts imposés ne sont pas présents dans l’analyse.

[...]

Ce critère permet de calculer de manière directe le point de convergence avec les offres grand public : connaissant le ticket d’entrée, et la différence de prix entre le tarif collecté et le tarif grand public, combien d’abonnés 2 faut-il pour absorber ce ticket d’entrée ? Cet indicateur là permet d’avoir une idée de la taille moyenne des acteurs qui peuvent exister sur ce marché. Si la convergence se fait sur plusieurs dizaines de milliers d’abonnés, alors aucun acteur local ne verra le jour. Si la convergence se fait sur quelques dizaines, on peut espérer voir de nombreux acteurs, de tous types, y compris hyper-spécialisés. Pour comparaison, les offres de collecte habituelles destinées aux petits opérateurs ont un point de convergence qui oscille entre 50 et 300 abonnés. »

« The init script /etc/init.d/snmpd will kill all processes with the name  snmpd in stead of killing by PID from /var/run/snmpd.pid which has as effect the killing of the daemon on all LXC containers. »

Malgré la fin de ce thread, ce mauvais comportement continue avec Jessie (et même avec Stretch...).

Solution élégante : passer à systemd avec cette unit qui juste fonctionne au poil : https://github.com/haad/net-snmp/blob/master/dist/snmpd.service que l'on met dans /etc/systemd/system/ puis systemctl enable snmpd.service.

Mais avant de faire ça, on dézingue l'initscript :
    * sudo update-rc.d snmpd remove
    * sudo rm /etc/init.d/snmpd
    * sudo dpkg-divert --add --rename --divert /usr/share/snmp/snmpd.initscript /etc/init.d/snmpd

La dernière ligne fait en sorte que dkpg ne remette pas l'initscript à sa place en cas de mise à jour du paquet snmpd. Voir https://www.debian-administration.org/article/118/Replacing_binaries_with_dpkg-divert . dpkg stockera l'initscript dans /usr/share/snmp/snmpd.initscript.

Note : j'ai personalisé cette unit en remplaçant l'ExecStart par « ExecStart=/usr/sbin/snmpd -f -LS6d -Lf /dev/null -u snmp -g snmp -I -smux,mteTrigger,mteTriggerConf ». Exécution sous l'username/usergroup snmp/snmp, log de niveau info envoyés dans syslog.

« This paper presents the results of a laboratory study involving Mailvelope, a modern PGP client that integrates tightly with existing webmail providers. In our study, we brought in pairs of participants and had them attempt to use Mailvelope to communicate with each other. Our results shown that more than a decade and a half after Why Johnny Can’t Encrypt, modern PGP tools are still unusable for the masses.
We finish with a discussion of pain points encountered using Mailvelope, and discuss what might be done to address them in future PGP systems.

[...]

Demographics
We recruited Gmail users for our study at a local university. Participants were two-thirds male: male (13; 65%), female (7; 35%). Participants skewed young: 18 – 24 years old (18; 90%), 25 – 34 years old (2; 10%). We distributed posters broadly across campus to avoid biasing our results to any particular major. All participants were university students, 4 with the majority being undergraduate students: undergraduate students (17; 85%), graduate students (3; 15%).

[...]

During the study, participants were asked to role-play a scenario regarding completing taxes. Participant A was told they needed Participant B’s help with filing taxes. Participant A was also told they since they were sending sensitive information (e.g., SSN) that they should encrypt this information using Mailvelope. 5 Participant B was told to wait for his friend to send him the necessary sensitive information (e.g., SSN). Once Participant B had received this information, he was instructed to use Mailvelope to respond to Participant A with a confirmation code (encrypted using Mailvelope) to conclude the task.

After the instructions were given, Participant A was provided with the the Mailvelope website and instructed to begin the task. 6 While participants waited for email from each other, they were told that they could browse the Internet, use their phones, or engage in other similar activities. This was done to provide a more natural setting for the participants, as well as to avoid frustration if participants had to wait for an extended period of time while their friends figured out how to use Mailvelope.

[...]

Of the ten participant pairs, nine were unable to successfully complete the task. In two of the nine pairs, participants A never figured out how to use Mailvelope to send any message. In another two pairs, Participant B was completely mystified by the encrypted PGP email and was unaware that they needed to install Mailvelope to read the message. Only one of the nine pairs actually traded public keys, though this pair was still confused about what to do after sharing their public keys.

The one pair that did complete the task required the full fortyfive minutes to do so. The successful pair was unique in that they were the only pair of participants where one of the participants had previously learned about public key cryptography. It is likely that this heavily influenced their ability to finish within the time limit.

[...]

Mistakes
All participant pairs made mistakes. The most common mistake was encrypting a message with the sender’s public key. This occurred for seven of the participant pairs, including for the participant pair that was eventually successful. Three of the participant pairs generated a key pair with their friend information, and then tried to use that public key to encrypt their message. One participant modified the PGP block after encryption (while still in the PGP compose window), adding their sensitive information to the area before the PGP block. Finally, one participant eventually exported his private key and sent it along with his keyring password to his friend so that his friend could decrypt the message he had received. In this case, even though the participants had transmitted the required information, they were informed that they needed to try some more and accomplish the task without sending the private key.

[...]

Mailvelope clearly failed to help the majority of participants encrypt their email. All participants expressed frustration with Mailvelope, with the most comical expression of this frustration coming from M3A: “Imagine the stupidest software you would ever use, and that was what I was doing.”. The difficulty also led several participants to indicate that in the real world they would have given up trying to use Mailvelope long before they did during the study. For example, M3A also said, “After five minutes, I would have just given up and called.”

[...]

Nearly all participants indicated that they wished Mailvelope had provided instructions that were integrated with the Mailvelope software, and would walk them through, step-by-step, in setting up Mailvelope and sending their first encrypted email.

[...]

The only participant pair that successfully completed the study task likely did so because one of the participants in the pair had previous knowledge related to public key cryptography. Additionally, the only other pair that made progress did so because they realized that they needed each other’s public keys, but even that pair did not know how to then use those shared public keys. For the remaining eight participant pairs, the post-study interview made it clear that they did not understand how public and private keys were used. To help address this, a simple explanation of PGP needs to be created that is accessible to the masses. »


Étude intéressante même si :
    * Focalisée sur Mailvelope ;
    * Un panel peu représentatif (des universitaires de sexe masculin entre 18-25 ans provenant tous/toutes de la même université...). Lors de cryptos-party, j'ai été témoin de personnes du 4e âge plus débrouillardes et ayant compris Enigmail et les principes cryptos sous-jacents alors que des futurs ingénieurs en 4e année d'école d'ingé en informatique galéraient alors bon...

On remarque que les cryptos parties et les OpenPGP Box (boîtes en carton pour expliquer la crypto asymétrique et quelques concepts des mails chiffrés (comme le fait que le sujet n'est pas chiffré), voir https://github.com/shiromarieke/shiro_tutorials/blob/master/gpgboxENG.pdf) ont de l'avenir : la connaissance de la crypto asymétrique a donné un avantage inégalé à un binôme de cette étude !

On valide que la masse attend une solution miracle qui soit sécurisée, facile à utiliser avec une prise en main immédiate... Ça ressemble à un triangle de Zooko, on n'est pas arrivé. :S On remarque que Caliopen est dans la bonne voie puisque le constat sur lequel se base le projet est vérifié : personne ne veut prendre plus de 5 minutes pour sécuriser ses communications... Donc il faut faire naître l'intérêt via un système de grade/jeu...

Via https://twitter.com/aeris22/status/665100132183105536

Petit défi utile que je me suis lancé : en cas d'urgence, comment me connecter, via SSH, à mes serveurs persos et à ceux d'ARN depuis le taff ?

Sachant que :
    * J'amène rarement mon ordi portable perso au taff car c'est pas commode dans les transports ;

    * Je ne suis pas root sur mon desk@taff (j'ai un wrapper python setuid root pour install/remove des softs et start/stop des services, rien de plus, même la modification de fichiers de conf dans /etc m'est interdite). En revanche, une team entière est root sur mon desk ;

    * Hors de question d'amener ma clé privée SSH au taff, même sur une clé USB : root pourrait me la voler. Conceptuellement, c'est une connerie : la clé privée ne transite pas sur un ordi sur lequel vous n'êtes pas le seul root, que ça soit un ordiphone perso ou un desk@taff ;

    * Pas d'authentification par mot de passe sur mes serveurs, je n'ai pas envie de lutter contre l'océan nommé bruteforce à coup de fail2ban & co.


Idée : utiliser la fonctionnalité smartcard GPG de ma Yubikey Neo (https://www.yubico.com/products/yubikey-hardware/yubikey-neo/) + gpg-agent qui simule aussi le ssh-agent. Auth par clé tout à fait standard, simplement la clé privée est stockée sur la Yubikey et ne peut en être extraite (les spécs ne prévoient pas cette opération, une attaque physique reste sûrement possible mais demande temps et compétences, ça exclu donc 99,9% des attaquants potentiels). En cas de perte/vol de la clé, il y a un PIN avec 3 essais possibles (l'admin PIN peut reset l'user PIN, 3 essais là aussi) + je vire la partie publique des authorized_keys de mes serveurs à coup d'Ansible dès que je constate la disparition (même temporaire) de ma Yubikey. Oui, root@taff peut encore capturer mon PIN avec un keylogger... C'est hors scope : s'il y a un keylogger sur mon desk@taff, j'aurai d'autres problématiques dans le sens où root aura capturé beaucoup d'autres choses...

La Yubikey ne permet pas d'utiliser des clés RSA plus longues que 2048 bits (ÉDIT DU 28/11/2015 À 02H30 : ce n'est plus vrai avec les Yubikeys 4, https://www.yubico.com/products/yubikey-hardware/yubikey4/, qui supportent des clés RSA 4096 bits < 3 FIN DE L'ÉDIT ), ce qui est un peu juste de nos jours (le Référentiel Général de Sécurité de l'ANSSI admet 2048 comme taille minimale, 3072 comme taille recommandée, voir http://www.ssi.gouv.fr/entreprise/reglementation/administration-electronique/liste-des-documents-constitutifs-du-rgs-v-2-0/, document B1). Conséquence : ce n'est pas ma "vraie" clé GPG que je stockerai sur ma Yubikey, ma Yubikey me servira uniquement pour de l'auth SSH sur mes serveurs et ceux d'ARN, elle ne sera donc pas publiées sur les serveurs de clés pour ne pas embrouiller les personnes qui voudraient m'envoyer des mails chiffrés.

Il est également possible de générer une clé primaire et des sous-clés (pour un rappel sur le principe de fonctionnement des sous-clés, voir https://wiki.debian.org/fr/Subkeys) et de stocker les sous-clés sur la Yubikey en gardant la clé primaire à la maison. Je n'ai pas besoin de cette complexité dans mon cas d'utilisation. Si vous pensez en avoir besoin, d'autres tutos sont plus adaptés.


Pour la mise en pratique, on suit et on adapte pour Debian GNU/Linux Jessie le tutoriel pointé par ce shaarli.

ÉDIT DU 28/11/2015 À 3H15 : les étapes 1 à 4 sont facultatives sur une Yubikey v4 car elles sont livrées avec l'interface smartcard activée. FIN DE L'ÉDIT. ÉDIT DU 28/11/2015 À 13H45 : ça me semble aller de soi mais les étapes 1-8 sont des étapes de préparation, à faire une fois et @home, les étapes 9-13 sont à effectuer sur les machines à partir desquelles vous voulez vous authentifier sur vos serveurs et autres. FIN DE L'ÉDIT.
1) sudo apt-get install yubikey-personalization

2) La première fois, ykinfo -v retournera « USB error: Access denied (insufficient permissions) » et il faudra ajouter une règle udev pour autoriser votre user en lecture+écriture dans /etc/udev/rules.d/99-yubikeys.rules : « ACTION=="add|change", ATTR{idVendor}=="1050", OWNER="guigui", MODE="0600" » (remplacez « OWNER="guigui" » par votre username. À la prochaine insertion de la yubikey, les permissions seront OK.

3) ykinfo -v
version: 3.3.0

4) On active l'interface smartcard en plus de la fonctionnalité OTP (le man de ykpersonalize explique les différentes configs possibles) :  ykpersonalize -m82 . L'interface smartcard sera activée à la prochaine insertion de la Yubikey et elle apparaîtra avec un gpg --card-status.

5) Changer l'user PIN et l'admin PIN : gpg --change-pin .

6) On génère les paires de clés directement sur la carte : gpg --edit-card puis « admin » dans le prompt GPG puis « generate ». Je n'ai pas gardé une copie des clés sur ma machine. J'ai mis une période avant expiration d'un an. Attention : cela veut dire que le seul exemplaire existant de la clé privée se trouve sur la yubikey et n'est pas extractible et les clés publiques se trouvent uniquement sur la machine utilisée !

7) Récupérer le fingerprint de la clé d'authentification : gpg --card-status | grep "Auth". À partir de là, il faut récupérer l'ID long (64 bits) de cette clé : il s'agit des 16 derniers chiffres (en hexa A-F sont des chiffres ;) ). Il faut virer les espaces.

8) gpgkey2ssh <ID_long_de_l'étape_précédente>. On récupère donc ce qu'il faut mettre dans l'authorized_keys de nos serveurs. :)

9) Si ce n'est pas encore fait, il faut virer le fake agent-gpg de GNOME/MATE : http://shaarli.guiguishow.info/?LazlWw.

10) On active le support SSH de l'agent-gpg : echo "enable-ssh-support" >> ~/.gnupg/gpg-agent.conf

11) On installe le support des smartcard pour GPG : apt-get install scdaemon

12) Fermer la session et revenir. Le bon agent GPG sera lancé, avec le support SSH. ssh-add -l doit montrer la clé présente sur la yubikey.

13) J'ai remarqué que la règle udev n'est plus nécessaire (probablement depuis l'étape 4 mais sans certitude) : la clé fonctionne directement sur n'importe quelle machine GNU/Linux. Tout est donc dans $HOME et le seul droit dont nous avons besoin est installation de logiciels. Achievement unlocked ! \o/

ÉDIT DU 28/11/2015 à 18h05 : On peut aussi utiliser la fonctionnalité PIV pkcs11 comme moyen d'authentification pour SSH. Voir http://shaarli.guiguishow.info/?rftZjA FIN DE L'ÉDIT.


À partir d'ici, mes serveurs peuvent m'authentifier à partir de ma yubikey... mais comment puis-je être sûr de l'identité du serveur en face (DNS menteur, hijack routing...) ? Il faut vérifier la fingerprint de la clé publique du serveur la première fois puis c'est stocké dans known_hosts... Sauf que là, je ne suis pas le seul root... Le fichier known_hosts n'est donc pas fiable. Comment faire ?
    * Soit amener la fingerprint de chacun de mes serveurs persos/assos sur un morceau de papier. Ça se loge dans mon porte-feuilles donc c'est OK pour moi. Avant chaque connexion, il faudra supprimer le fichier know_hosts existants (il a pu être altéré entre deux connexions à mes serveurs).

    * Soit DNSSEC + SSHFP + un récursif cache local à la machine validant. Voir http://shaarli.guiguishow.info/?QWcOtQ . Achievement unlocked ! \o/

Toutes les autres idées que j'ai eu foirent :
    * Signer un known_hosts valide chez moi avec la yubikey. Pour valider la signature, il faut la clé publique. Comment on la récupère de manière sûre ?
        * On ne peut pas récupérer la clé publique depuis la smartcard ni la dériver de la clé privée car ça nécessite de gpg --import la clé privée (puis de gpg --export)... Ce qui n'est pas possible avec une smartcard. Voir : https://lists.gnupg.org/pipermail/gnupg-users/2006-March/028281.html .

        * On a dit qu'on ne mettait pas notre clé sur les serveurs de clés vu sa faiblesse et la possibilité de confusions.

        * Sur une smartcard (et donc une yubikey), il est possible de stocker une URL où récupérer la clé (gpg --card-edit + « admin » + « url » pour définir, gpg --card-edit + « fetch » pour récupérer la clé) mais alors il faut vérifier la clé (root a pu MITM, même avec TLS puisqu'il contrôle la liste des AC x509 reconnues sur le desk@taff)... Retour au problème initial.

        * Clé USB ? Il faut avoir une clé de plus dans sa poche. Si on stocke la clé sur le desk@taff, root peut la remplacer (ainsi que le known_hosts) par une paire qu'il a généré lui-même avec une identité avec mon nom/prénom. C'est donc la fingerprint qu'il faut vérifier.

    * On pourrait chiffrer un known_hosts valide et l'amener au taff et même le stocker au taff : il faudrait forcément la yubikey pour le déchiffrer. Si GPG accepte de déchiffrer sans mon PIN -> problème. Néanmoins, pour que ça fonctionne, il faut garder la clé publique... privée (car toute personne en sa possession pourra chiffrer un fake known_hosts), ce qui va à l'encontre du principe de Kerckhoffs (seule la partie privée doit être considérée comme secrète, tout le reste (algo, partie publique) doit être considéré d'office comme étant public ! ) et est donc une idée à oublier tout de suite.


Pour les autres usages de  la Yubikey, notamment l'OTP (pour PAM, site web, ...), voir https://numaparis.ubicast.tv/videos/pses-yubikey/ . On peut aussi l'utiliser avec LUKS.

Merci à Aeris (https://imirhil.fr/) pour son avis sur la partie vérification de l'identité du serveur SSH.

« As Paris reels from terror attacks that claimed at least 128 lives, fierce blame for the attack is being directed toward American whistleblower Edward Snowden and the spread of strong encryption catalyzed by his actions.

[...]

Fox News hosts Greg Gutfeld and Dana Perino, George W. Bush's former press secretary, took to Twitter to directly blame and even curse at Snowden.

[...]

In response to the Charlie Hebdo attacks that hit Paris in January of 2015, France adopted one of the most aggressive surveillance laws in the Western world. That was not enough to stop these attacks.

[...]

On television in America, on-screen experts quickly began speculating that encryption, as well as more precise knowledge of the West's intelligence capabilities, could have played a role in the attacks.

[...]

There is no public information about the planning behind the attack, so any suggestion that Snowden or encryption are to blame is conjecture. The pointed speculation against Snowden attracted criticism as well.

Ils sont mignons. :') Mais c'était à prévoir...

Via http://korben.info/news/les-abrutis-de-cnn

Nombre de réseaux IP d'opérateurs télécoms historiques en Europe sont structurés de la même manière : un réseau pour les accès résidentiels (qui regroupe les clients de l'opérateur dans son pays d'origine avec lequel les autres gros opérateurs du pays peuvent peerer) et un réseau de transit IP internationale (qui revend donc de la connectivité au réseau résidentiel).

Exemples (format : réseau résidentiel - transitaire) :
Orange DCIO AS3215 - Orange OpenTransit (OTI) AS5511
Telecom Italia Sparkle - Seabone AS6762
Deutsche Telekom AG AS3320 - T-Systems AS34086
UPC (PL AS20947, NL AS8209, CH,...) - Liberty Global AS6830
De même pour Telefonica en Espagne même si la séparation est moins visible sur les contrats...

Les chiffres que je vais présenter sont biaisés :
    * Ils concernent un FSI euro-centré et un FAI associatif basé à Strasbourg, soit deux profils bien typés ;
    * Ce sont des moyennes, j'ai viré les exceptions afin de ne pas fausser la moyenne ;
    * Ils ne tiennent pas compte des contrats supplémentaires qui peuvent parfois être signés pour la zone Asie dont le transit coûte plus cher (7x d'après CloudFlare, voir http://shaarli.guiguishow.info/?LbrkoQ).


NRC/FAS/OTC (frais d'install, quoi) pour un port :
    * Avec un gros transitaire international bien connu (Telia, Tata, Level3, Cogent, Tinet, Interoute,...) :
        * 100M : ~ 350-700€ ;
        * 1G : ~ 1000€ ;
        * 100G : ~ 10-13k€

    * Pour une PNI (interconnexion privée payante, pas peering gratos) : ~ 1000-1500€ pour 10G

MRC (engagement 1 an) :
    * Pour un transit burstable chez gros transitaire international bien connu (notons que ça dépend de l'endroit de livraison... le prix n'est pas le même à Paris qu'à Strasbourg, par exemple) :
        * 50M : 3-4€/mbps ;
        * 100M : 2-3€/mbps ;
        * 50G en 2014 : ~0,70/mbps ;
        * 100G en 2015 : 0,4-0,5€/mbps.

    * Pour une PNI (soit l'opérateur facture le port entier, soit à l'usage donc au 95e percentile) : 0,45€/Mbps pour n*10G (je n'ai pas tenu compte des opérateurs qui facturent une PNI à prix symbolique...)

Dans une config avec plusieurs ports (dans plusieurs PoP), le modèle de facturation est agrégation de tous les ports puis 95e percentile mais certains opérateurs calculent le 95e percentile par port puis la somme totale.


Liaisons transatlantiques :
    * NRC (engagement 3 ans) : ~12k€
    * MRC (engagement 3 ans) : ~32k€
Ajoutez ~5k€ aux chiffres ci-dessus pour un engagement d'un an seulement.


Notons que ce qui peut également coûter dans une interconnexion, c'est le prix de l'interconnexion physique dans le datacenter entre les deux opérateurs. Le modèle de facturation varie grandement : est-ce que l'opérateur du datacenter autorise les connexions directes entre baies (TH2, par exemple) ou uniquement les connexions via une Meet-me-room (Netcenter SFR de Strasbourg) ? Y-a-t-il juste des frais d'install ou aussi un récurent mensuel, ou les deux ? En Amérique du nord, le modèle de la facturation mensuelle domine. En Europe, c'est moins clair. Cuivre ou fibre uniquement ? Évidemment, les prix fluctuent tout autant entre les datacenters selon leur position géographique, leur réputation,...

Pour se faire une idée : au Netcenter SFR de Strasbourg, pour une liaison fibre, on parle de 1360€ NRC + 25€ MRC pour aller du patch panel de ta baie en MMR puis 650€ NRC + 50€ MRC pour câbler ta position en MMR à celle de l'opérateur avec qui tu veux t'interconnecter. Notons que tous ces prix sont gonflés puisqu'on ne traite pas directement avec SFR mais avec un revendeur puisque la vente ne peut se faire que si l'entreprise dispose d'un contrat d'hébergement auprès de l'opérateur du datacenteur.


Pour les personnes qui se demandent ce qu'est une MMR (Meet-Me-Room, suivez un peu ! :P ) : c'est juste une salle d'interconnexion one-to-one passive : une position en MMR = un opérateur. Donc vous avez plusieurs segments : patch panel de votre baie <-> votre position en MMR puis votre position en MMR <-> la position en MMR de l'opérateur avec qui vous voulez vous interconnecter puis position de l'opérateur en MMR <-> patch panel de l'opérateur dans sa baie. Il n'y a pas de multiplexage (d'où c'est passif) : une fibre entre vous et la MMR ne sert que pour une seule position de la MMR donc pour joindre un seul opérateur. Selon votre taille, le mieux est donc de faire tirer n fibres/cuivre entre votre baie et la MMR. Tout est ainsi précâblé, il restera à payer le morceau de câble entre les deux positions en MMR lors du setup d'une nouvelle interconnexion


Points d'échange, pour 100G (ici, on paye le port en entier, pas l'usage) :
    * France IX, dont j'ai parfois du mal à voir l'intérêt quand je vois nombre de gros opérateurs français l'éviter au profit de DECIX/AMSIX : 5000€ NRC ; 5500€ MRC
    * DECIX, Allemagne, qui est en train de devenir the place to be en Europe, notamment pour peerer avec les réseaux de l'est/chinois : 0€ NRC ; 9500€ MRC
    * AMSIX, Pays-Bas, même trafic que le DECIX à l'heure actuelle : 0€ NRC, 5000€ MRC
    * LINX, Angleterre : 850£ NRC, 6185£ (LAN Juniper) ou 4700£ (LAN Extreme) MRC
On est donc inférieur à 10 centimes du mbps, comme on pourrait s'y attendre.

Notons qu'il existe des points d'échange inconnus qui brassent quand même pas mal (à mettre en perspective de DECIX/AMSIX avec leur 2 Tbps en moyenne et 4 Tbps en pointe)... ainsi que des IX plus inattendus :
    * PLIX, Pologne, 250Gbps en moyenne, pics à 500Gbps. On parle d'environ 2500€ de NRC et 7000€ de MRC pour un port 100G
    * TPIX (avec Orange derrière), Pologne, 100Gbps, pics à 200Gbps. On parle d'environ 5000€ NRC et MRC pour un port 100G
    * CERN Internet eXchange Point (CIXP), Suisse, 2Gbps, 4Gbps en pointe