GuiGui's Show

Bilan provisoire du Privacy Shield :

• On n'est toujours pas sur un cadre juridique contraignant mais sur un programme d'auto-régulation et d'auto-certification déclarative comme le défunt Safe Harbor, mais attention : le gouvernement US promet qu'il veillera au grain (surveillance proactive + faire corriger les abus + les sanctionner) tout en laissant son indépendance au mécanisme… trolololololo. Surtout que les élections présidentielles US approchent : il se passe quoi, après ? ;
  
  
• Cet accord, une simple décision d'adéquation (on décide que le droit états-unien satisfait à peu près aux exigences européennes de protection des données perso) se base sur l'ancienne directive européenne sur les données perso, celle de 1995, pas sur le nouveau règlement européen de 2016, plus contraignant, qui entrera en application en 2018. Et, forcément, rien n'est prévu explicitement dans le texte du Privacy Shield pour que le nouveau règlement lui serve de base dans le futur ;
  
  
• On n'harmonise pas les conceptions US et EU sur la valeur des données personnelles (simple droit de propriété qui peut être marchandé côté USA, droit fondamental côté EU) donc forcément, ça sera toujours le boxon. Pourtant, avec TAFTA, on harmonise les normes commerciales mais, sur le sujet des données personnelles, il faut croire que ça demande trop de boulot et/ou de volonté ! Après je reconnais que c'est aussi une histoire de souveraineté : les USA ne sont pas membre de l'EU et ont bien le droit d'avoir une autre conception que nous sur tous les sujets du monde, c'est tout l'intérêt de la souveraineté ;
  
  
• Apparemment, tous les droits européens ne sont toujours pas applicables : on a le droit d'accès, le droit de rectification et un bout du droit d'opposition (opt-out sur les nouveaux usages) mais rien sur l'effacement intégral ;
  
  
• On ne met pas fin à la surveillance de masse US mais elle est faussement limitée à 6 exceptions dont l'intérêt public, source de tous les débordements législatifs de ces dernières années en matière de surveillance, et, comble du bonheur, utilisable quand la surveillance ciblée est impossible (quels critères, quels contrôles, mystère) ! Le gouvernement US a donné des « assurances écrites » que ça a une base légale, on est prié de le croire, pas de vérifier ! Réaliste, le G29 (groupement des autorités de protection des données personnelles nationales) n'a même pas demandée la fin de la surveillance de masse / collecte massive alors que c'est le fondement de l'arrêt rendu par la CJEU invalidant le Safe Harbor ;
  
  
• Chaque entité est libre d'avoir recours au Privacy Shield ou non : elle peut aussi avoir recours aux règles internes aux entreprises et aux clauses contractuelles même si c'est le flou juridique total autour de tout ça, que la CJEU va bientôt se prononcer dessus et que les clauses contractuelles impliquent de recueillir l'avis éclairé (donc pas noyé dans les CGU) des utilisateurs-rices, ce dont ont peur les gros silo US ;
  
  
• Pas de vrais recours possibles : on a un médiateur dépendant du gouvernement US, qui n'a pas de pouvoirs d'enquête et qui est non coercitif (en mode CNCTR en France, il vérifie que "tout va bien") que le citoyen EU ne peut pas saisir directement. Pour aller devant un juge US, la procédure est complexe histoire qu'il y ait un taux de non-recours (aka que 99,9 % des personnes ne fassent pas valoir leurs droits) exorbitant ;
  
  
• Quelques avancées : opt-out sur les nouveaux usages pas prévus lors du recueil du consentement ; consentement explicite pour les données sensibles (emplois, santé) ; révision annuelle du dispositif alors qu'on a laissé le Safe Harbor dépérir pendant toutes ces années. Reste à savoir si ça serait une vraie révision ou un simple rapport… ;
  
  
• Le Privacy Shield doit encore être examiné par la Commission européenne (le pouvoir exécutif de l'UE). On notera que cet accord, de par sa nature, échappe au Parlement européen qui est pourtant très critique et sceptique sur l'état actuel du texte au point d'avoir voté, à 501 voix pour, 119 contre et 31 abstentions, une résolution soulignant ses lacunes et demandant à la Comission européenne de continuer la négociation (voir http://www.europaforum.public.lu/fr/actualites/2016/05/pe-privacy-shield/index.html ). Le co-législateur le plus proche du peuple européen ne sera pas entendu… D'un autre côté, 14 pays européens (dont l'Angleterre, l'Irlande, la Pologne, etc.) plaidaient, début juin 2016, pour la fin du protectionnisme européen en matière de données personnelles. Voir : http://www.nextinpact.com/news/99963-europe-moitie-etats-membres-veulent-liberer-echange-donnees.htm
  
  
• Le mot de la fin à la commissaire européenne en charge du dossier, Věra Jourová : « Le Privacy Shield ne peut pas être parfait. Il ne le sera jamais. Il y a des raisons objectives pour lesquelles nous n'avons pas pu aller plus loin. Comment voulez-vous que nous imposions nos volontés aux constitutionnalistes américains ? ». Source : http://www.europaforum.public.lu/fr/actualites/2016/05/pe-privacy-shield/index.html .
  
  
  
  
  [...]
  
  
  
  
  http://www.lemonde.fr/pixels/article/2016/07/08/donnees-personnelles-le-privacy-shield-dans-la-derniere-ligne-droite_4966618_4408996.html :

Le Privacy Shield (« bouclier de protection des données personnelles »), un accord politique censé encadrer l’utilisation des données personnelles des citoyens Européens par les entreprises sur le sol américain, a été validé par les Etats membres [ NDLR : des représentants de ces États, comme le vaut l'article 31 de la directive européenne de 1995 qui défini et ordonne les données persos ], vendredi 8 juillet.

[...]

L’accord, entre la commission et les Etats-Unis, doit encore être validé par le collège des commissaires européens, avant son adoption définitive [ NDLR : par la Commission européenne ] qui devrait intervenir le 12 juillet prochain, après des mois d’âpres négociations. Ce n’est pas la fin du débat autour de cet accord contesté.

L’accord n’a pas fait consensus auprès des Etats membres, les diplomates représentant plusieurs pays – l’Autriche, la Slovénie, la Bulgarie et la Croatie, selon l’agence Reuters – se sont abstenus. Un moyen d’« exprimer leur méfiance vis-à-vis du texte » anticipait, jeudi lors d’une conférence, David Martinon, ambassadeur français pour la cyberdiplomatie et l’économie numérique, cité par le site Silicon.fr.

On note l'absence de l'"opposition" de l'Allemagne, que beaucoup considérent être des acharnés de la vie privée… C'est peut-être vrai au niveau citoyen mais pas au niveau des politocards.




[...]




https://www.laquadrature.net/fr/privacy-shield-bouclier-a-refuser :

Le 6 octobre 2015 la Cour de justice de l'Union européenne avait annulé l'accord du « Safe Harbor » couvrant les transferts de données depuis 2000, estimant que celui-ci permettait une collecte massive des données et une surveillance généralisée sans offrir de voies de recours effectives aux États-Unis pour les individus concernés en Europe. Aujourd'hui, force est de constater que le Privacy Shield ne répond pas non plus aux exigences de la Cour de justice.

Sur les principes de respect de la vie privée qui incombent aux entreprises couvertes par le Privacy Shield, on peut se demander l'utilité même d'une telle décision dans la mesure où celle-ci ne se substituera pas aux clauses contractuelles types ni aux règles internes d'entreprises, moins contraignantes et actuellement en vigueur, mais qu'elle s'y ajoutera. Cela signifie que si une entreprise couverte par le Privacy Shield s'en fait exclure pour non-respect des obligations qui lui incombent en matière de vie privée, elle pourra continuer à traiter des données avec les deux mécanismes internes cités plus hauts.

Ben tout comme avec le Safe Harbor. On n'a rien perdu, ni rien gagné. Demander de l'harmonisation en Droit = douce utopie.

Mais le cœur de la décision se retrouve plutôt dans le chapitre sur l'accès aux données par les autorités publiques des États-Unis. Dans le texte, il n'est pas question de « surveillance de masse » mais plutôt de « collecte massive ». Or, si les États-Unis ne considèrent pas la collecte de masse comme de la surveillance, l'Union européenne, elle, par l'intermédiaire de sa Cour de justice, a tranché sur cette question en considérant, dans l'affaire C-362/14 Schrems c. Data Protection Commissioner, que la collecte massive effectuée par l'administration des États-Unis était de la surveillance de masse, contraire à la Charte des droits fondamentaux de l'Union européenne. Cette décision avait mené à l'invalidation du « Safe Harbor », et tout porte à croire que les voeux pieux et les faibles garanties d'amélioration exprimées par le gouvernement américain ne suffiront pas à rendre la décision du Privacy Shield adéquate avec la jurisprudence européenne.

Quelle surprise ! Non mais attendez : on a l'EU, grande utilisatrice de services web américains et complice de la surveillance de masse (y'a pas que les USA qui en font, échange de données entre plusieurs pays de l'EU et des USA, etc.) qui essaye de dire "renoncez à votre surveillance de masse que vous avez mise masse de thune, de gens et d'années à construire pour qu'on continue à faire du business ensemble, svp"… Sérieux, l'EU n'a aucun poids ni crédibilité dans les négociations : elle raffole des services qui vivent de ce qu'elle dénonce ! Je ne crois pas une seconde à l'argument "les USA ne peuvent pas se passer du marché européen" et je préfère lire que les Européen-ne-s ne peuvent pas se passer des services web américains et que c'est tout là le problème.

L'une des exigences de la CJUE, des CNIL européennes, du contrôleur des données personnelles et de la société civile était que toute personne concernée par un traitement de données avec cet État tiers puisse avoir la possibilité de déposer une plainte et de contester un traitement ou une surveillance illégale. Pour pallier cette sérieuse lacune du Safe Harbor, un mécanisme de médiateur (« Ombudsperson ») a été instauré. L'initiative aurait été bonne si ce médiateur était réellement indépendant [ NDLR : et coercitif ]. Mais d'une part il est nommé par le Secrétaire d'État, d'autre part les requérants ne peuvent s'adresser directement à lui et devront passer par deux strates d'autorités, nationale puis européenne. L'Ombudsperson pourra simplement répondre à la personne plaignante qu'il a procédé aux vérifications, et pourra veiller à ce qu'une surveillance injustifiée cesse, mais le plaignant n'aura pas de regard sur la réalité de la surveillance. Cette procédure ressemble à celle mise en place en France par la loi Renseignement avec la CNCTR et, pour les mêmes raisons, ne présente pas suffisamment de garanties de recours pour les citoyens.

Même problème ici : la surveillance de masse a été bâtie sur le secret défense. Tant que la société civile n'arrivera pas à démonter ça, le reste est perdu d'avance.




[...]




http://www.silicon.fr/privacy-shield-pas-ratifie-mais-attaque-152492.html :

Il rappelle que 6 exceptions sont possibles au Privacy Shield : « La détection et la lutte à certaines activités de puissances étrangères, l’anti-terrorisme, la lutte contre la prolifération nucléaire, la cybersécurité, la détection et la lutte contre les menaces visant les Etats-Unis et les forces armées alliées [ NDLR : comprendre « intérêt public », le fameux qui permet de tout détourner ;) ) et, enfin, la lutte contre les menaces de crimes transnationaux. ». Or cet espionnage massif est contraire, selon lui, à la jurisprudence de la Cour de Justice de l’Union européenne qui impose « une sphère de confiance ».

Mais le débat est peut-être tronqué dès le début, assure maître Olivier Iteanu, avocat spécialiste des nouvelles technologies et vice-président de Cloud Confidence. « La bataille sur le Privacy Shield est avant tout sur les principes mêmes liés à la donnée personnelle. Aux Etats-Unis, les données sont perçues comme un droit de propriété que l’on peut céder commercialement à une entreprise. En Europe, la donnée est un droit fondamental protégé. Tant que nous n’aurons pas de réconciliation de ces principes, il sera difficile de trouver un terrain d’entente. Il faut que les Etats-Unis fassent un pas supplémentaire dans notre direction. »

Gros +1




[...]




http://www.lemonde.fr/pixels/article/2016/07/01/donnees-personnelles-un-accord-privacy-shield-tres-favorable-pour-les-etats-unis_4962245_4408996.html

Comme le Safe Harbor, le Privacy Shield est très souple, car il repose sur un mécanisme volontaire d’autocertification par les entreprises concernées.

La collecte des données devra correspondre aux besoins précis des entreprises, et ne pas être détournées pour d’autres usages. Les Européens auront la possibilité de bloquer l’utilisation de leurs données pour des utilisations non prévues au départ (opt out). Pour les données sensibles (emploi, santé, etc.), un consentement préalable sera exigé. Un Européen aura le droit de consulter ses données personnelles détenues par une entreprise américaine, et si elles sont erronées, il pourra exiger qu’elles soient corrigées.

Le stockage ne pourra pas excéder cinq ans – sauf exception, notamment pour les journalistes, les artistes, les chercheurs, les statisticiens… [ NDLR : oui, enfin bon, même la commissaire européenne en charge du sujet a reconnue qu'il faudra « rendre plus explicite le principe de conservation limitée des données ». ] En ce qui concerne les décisions prises automatiquement par des ordinateurs (par exemple le rejet d’une demande de crédit, ou un profilage individuel), les Etats-Unis s’engagent simplement à évaluer l’impact de ces pratiques, à l’occasion des discussions annuelles prévues avec la Commission.

Bien entendu, le Privacy Shield prévoit une exception de taille : les services de renseignement américains continueront à intercepter et à exploiter les données personnelles venues d’Europe, notamment dans les affaires de «sécurité nationale » (contre-espionnage, terrorisme, armes de destruction massive…), « d’intérêt public » et de crime organisé.

En fait, les procédures de dépôt de plainte seront multiples : le plaignant pourra contacter directement l’organisme détenant ses données ou saisir le médiateur en passant par l’intermédiaire de son agence nationale, qui transmettra le dossier à Washington. Il pourra aussi faire appel à une commission d’arbitrage paritaire. En théorie, il pourrait même porter plainte ad nominem contre un fonctionnaire américain soupçonné de pratiques abusives – à condition de trouver un magistrat américain qui jugera sa plainte recevable.

Ils remarquaient aussi que le texte se réfère à la directive européenne de 1995, et non pas au nouveau règlement sur la protection des données, plus contraignant, adopté en 2015 mais qui n’entrera en vigueur qu’en 2018.

Par ailleurs, de nombreuses entreprises américaines n’ont plus vraiment besoin du Privacy Shield, car elles utilisent un autre mécanisme juridique : les « clauses contractuelles types », des accords privés bilatéraux passés entre une société européenne souhaitant exporter ses données outre-Atlantique et un prestataire américain qui va les traiter. Dans le cas des entreprises collectant directement les données auprès du public, comme Google ou Facebook, le contrat peut être passé entre leur filiale européenne et la maison mère américaine.

[...]




Notons que ces clauses contractuelles vont peut-être bientôt se faire trancher par la CJEU : http://www.numerama.com/politique/172949-facebook-continuer-a-exporter-vos-donnees-aux-usa-cjue-devra-trancher.html :

C’est donc pour avoir un avis définitif et opposable sur la question que la Cnil irlandaise, sommée par la Haute cour de prendre position, a demandé à la Cour de justice de l’Union européenne de prendre position à sa place. C’est la CJUE qui devra dire si oui ou non, les clauses types sont utilisables.

Bah la doc', ça sert à rien, tu poses directement ta question aux gens à l'origine du projet, non ? C'pas comme ça qu'on fait ?

Une BMC, c'est une carte contrôleur greffée à la carte mère d'un ordinateur (on trouve ça plutôt sur les serveurs) qui permet le management à distance de la bécane (accès console, reboot, monitoring bas niveau,...). Super utile en cas de panne ou de fausse manip' puisque ça évite de bouger au datacenter où les machines sont hébergées pour debug.

Comme ces contrôleurs sont exposés sur Internet (adresse IP publique, interface web, SSH, etc.) et qu'ils permettent de grandes choses (reboot de la machine, accès à distance, etc.), il est important de les maintenir à jour. Cf http://shaarli.guiguishow.info/?-leLhg pour une étude du niveau actuel de délabrement.

Pour un serveur Dell PowerEdge R710 avec iDRAC6, c'est par ici : http://www.dell.com/support/home/us/en/19/product-support/product/poweredge-r710/drivers , dans la catégorie « Embedded Server Management », « Dell iDRAC Monolithic Release X.XX ».

Pour un serveur HP ProLiant DL380G6 avec un iLO 2, c'est par ici : http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=3884088&swLangOid=8&swEnvOid=4064 , dans la catégorie « Firmware - Lights-Out Management », « Online ROM Flash Component for Windows » ou pour winwin x64, ça n'a pas d'importance.

Une fois l'exécutable téléchargé, on le décompresse avec 7zip, par exemple : 7z x ESM_Firmware_J7YYK_WN32_2.85_A00.EXE.

Parmi les fichiers décompressés, on trouve :

• Pour Dell : payload/firmimg.d6
• Pour HP : ilo2_<version>.bin

Il suffit d'uploader ces firmwares en utilisant l'interface web de la BMC pour que la mise à jour se fasse.

Les BMC, c'est un truc auquel on pense rarement. Il faut donc se tenir informé par RSS ou par mail de la sortie des mises à jour, pour être sûr de ne pas zapper une mise à jour de sécurité, importante de fait. Dell et HP proposent tous deux leur service de « driver and support alerts » ou « Driver and Firmware Update notifications » :

• Chez Dell, c'est accessible en bas de la page concernant un produit, comme celle que j'ai pointée ci-dessus.
• Pour HP, il faut cliquer sur un driver/firmware depuis la page concernant un produit, genre iLO, puis descendre en bas de la page.

3 petites histoires des services de renseignement français issues du Canard du 29 juin 2016.

Des fichiers dont tout le monde se fiche

[...] À deux pas des Champs-Elysées et à trois de la Place Beauvau, deux jeunes hommes occupés à vendre à la sauvette des denrées périssables aux noctambules sont surpris par la police. Un banal contrôle de routine. Les flics du commissariat du VIIIe arrondissement vérifient leur identité.

L’un est inconnu des services. L’autre, âgé de 25 ans, se prétend entrepreneur dans la restauration. Il est surtout fiché S, pour atteinte à la sûreté de l’Etat. Il s’agit de Larossi Abballa, l’homme qui, au nom de Daech, assassinera trois mois plus tard, le 13 juin, un couple de fonctionnaires de police à leur domicile.

Les flics procèdent à son interpellation et suivent à la lettre les consignes. La fiche S précise : « prévenir le service émetteur ». Suit un numéro de téléphone de la DGSI. A deux reprises, les poulets du VIIIe téléphonent. Ils attendent qu’un collègue leur donne des ordres, leur indique la conduite à tenir. Menotter Abballa ? Le mettre au gnouf ? Le surveiller sans attirer l’attention ? Ou simplement le laisser libre d’aller et venir ? Ils n’obtiendront aucune réponse. Comme dans la chanson, à la DGSI, « y a jamais person qui répond ». Pourtant, le patron du « FBI à 1a française » ne s’appelle pas Gaston !

« Ce n’est pas la première fois que ça arrive et ce ne sera pas la dernière, déplore un haut gradé. Une fois 22 heures passées, il n’y a plus personne au téléphone a Levallois, et rarement quelqu’un avant 7 heures. C’est d’autant plus grave que la plupart des terroristes auxquels nous avons eu affaire ces derniers temps sont fichés S. »

En septembre 2013, Abballa avait été condamné à 3 ans d’emprisonnement par le tribunal correctionnel de Paris dans une affaire de f1lière pakistano-afghane. Et il était suspecté d’avoir remis le couvert récemment. Ainsi, depuis le 11 février, il était placé sur écoute. Comme il l’a confié à sa petite amie, il le savait parfaitement.

Un suspect écouté, mais qui se tait, et un service qui n’écoute pas : tout va pour le mieux, dans la police...

Limites des humain-e-s. Automatisons la police et la justice avec des algorithmes ? Je suis ironique, bien entendu.

Abdeslam, le raté

A commission d’enquête parlementaire sur le terrorisme doit rendre publiques ses propositions le 12 juillet. Durant près de 200 heures d’auditions Georges Fenech (UAIP‘) et Sébastien Pietrasanta (PS') se sont efforcés de comprendre les « loupés » de la traque antiterroriste. Ils ont ainsi établi que le « cerveau » du Bataclan, Salah Abdeslam, avait bien été contrôlé par les gendarmes, à Cambrai, le 14 novembre à 9 h 10, à bord d’une voiture de location, en compagnie de deux individus. Or, constatent les parlementaires, les services de police connaissaient, depuis 4 heures du matin, le type et l’immatriculation de la voiture louée par Abdeslam et ses complices. Encore « un trou dans la raquette ».

Erreur humaine, comme toujours.

Alerte pas très gay

Les grands chefs de la DGSI viennent d’avoir un sacré coup de chaud. Juste après la tuerie dans un club gay d’Orlando, aux États-Unis, l’une des têtes pensantes de l’état—major du « FBI à la française » s’est souvenue de tuyaux qui lui étaient récemment parvenus. Plusieurs sources assuraient que des terroristes envisageaient de frapper des clubs gays en France, symboles de l’Occident dépravé. Damned !

Ni une ni deux, l’élite des forces d’intervention est mobilisée. Durant quarante-huit heures, le week-end des 18 et 19 juin, plusieurs clubs du quartier du Marais, à Paris, sont placés sous étroite sur- veillance, et des snipers prennent même position sur les toits aux alentours. Heureusement, RAS. «Après le Bataclan, se lamente un officier de renseignement, on s’est souvenus que des prévenus avaient parlé à des flics et des magistrats d’une tuerie de masse dans une salle de concert. Après Orlando, on se rappelle avoir eu l’info d’une attaque contre les lieux gays. Nous avons les bons renseignements, mais nous ne savons pas les analyser ! »

Trop d'infos, tue l'info. Ce n'est pas tout de collecter des infos, il faut savoir les traiter au bon moment. Resortir les données collectées en masse après-coup, pour refaire l'histoire, n'est pas acceptable.

je trouve ces exemples intéressants quand on regarde après-coup la loi Renseignement et la loi sur la lutte contre la criminalité organisée et la reforme pénale : toujours plus de moyens de surveillance, de flicage, de surveillance de masse, pour les services de renseignement et pour les Magistrats. Et donc ? Tout ça pour quoi ? Les USA ont tout ça depuis le début des années 2000 et avant et ils se sont mangés des attentats et toutes sortes de tueries. Il reste les erreurs humaines, les limites des humain-e-s et le fait de donner du sens aux infos collectées…

On a donc ajouté des dangers supplémentaires à la démocratie, ceux induits par la surveillance de masse (autocensure, société du soupçon permanent donc sans confiance entre les individus ainsi que le fait que, même si les infos collectées ne sont pas utilisées au présent, elles peuvent l'être dans le futur soit pour nuire à des personnes (lanceur-ses d'alertes, entrée en politique, journaliste pénible, etc.), soit pour asseoir une version de l'histoire, soit pour prédire le passé (comme on le fait à chaque acte terrorisme, dire qu'on avait l'info pour augmenter les moyens et budgets de la surveillance), sans rien corriger des problèmes concrets du renseignement… Ça craint. :/

le sondage Ifop que l’Association des chrétiens pour l’abolition de la torture (Acat) a rendu public hier, en même temps que son rapport annuel sur le sujet (lire encadré ci-contre). Selon cette enquête, 54 % des Français considèrent comme « justifié le fait pour un policier d’envoyer des décharges électriques sur une personne soupçonnée d’avoir posé une bombe prête à exploser ». Un chiffre qui n’était que de 34 % en 2000. De manière plus générale, 36 % des sondés disent désormais « accepter le recours à la torture dans certains cas exceptionnels », contre 25 % en 2000.

[...]

Pour le responsable, la cause de ce glissement est évidente : « On ne peut que l’attribuer au terrorisme. En 2000, il n’y avait pas eu encore le 11 Septembre, les attentats de Londres, Madrid, Paris ou Bruxelles. La peur, depuis, s’est installée en profondeur. Et, avec elle, le fantasme que le recours à la violence pouvait être efficace dans la lutte contre ces menaces. » Ce que confirme un autre résultat du sondage : 45 % des personnes interrogées estiment que la torture est efficace pour « prévenir des actes de terrorisme » comme pour « obtenir des informations fiables ».

« Pourtant, c’est totalement faux, souligne Jean-Étienne de Linares. D’abord, le scénario du poseur de bombe qu’on torturerait est en réalité une escroquerie intellectuelle. Ce genre de cas n’arrive jamais, on ne vit pas dans le monde de Jack Bauer ! Et, surtout, plusieurs rapports du Sénat américain l’ont montré : les renseignements obtenus sous la torture ne sont pas fiables. Les gens parlent, certes, mais disent souvent n’importe quoi. Ce recours peut même se révéler contre-productif, car il crée des martyrs. »

[...] Une majorité de sondés estiment ainsi que les minorités ethniques ou religieuses (39 %) ou les opposants politiques (25 %) sont les premières victimes de la torture, alors qu’il s’agit en réalité des délinquants et suspects de droit commun (cités seulement par 7 %). Même confusion sur les auteurs de tortures, attribuées en priorité aux membres de groupes armés non étatiques (51 %) ou d’organisations criminelles (33 %), alors que les principaux responsables sont, en fait, les militaires (cités par 6 % des sondés), les policiers (3 %) ou les gardiens de prison (1 %).

Enfin, la part des personnes interrogées qui se disent prêtes à recourir elles-mêmes à la torture « dans des circonstances exceptionnelles » : 18 % ! Un chiffre qui grimpe à 41 % chez les sympathisants du FN… [...]

Au Nigeria, la situation s’est détériorée depuis 2009. La présence du groupe islamiste Boko Haram dans le nord du pays a entraîné une riposte violente du gouvernement, qui n’hésite pas à user de la torture contre des présumés islamistes. Second bilan inquiétant esquissé dans le rapport : le développement de la torture privée. Au Sinaï, des migrants en exil sont capturés et enfermés dans des « maisons de torture » à des fins de profits. Au Mexique, le rapport note une très nette hausse de la pratique. Depuis l’instauration, en 2006, de la politique gouvernementale de « guerre contre le crime organisé », le nombre de plaintes pour torture a augmenté de 600 %.

J-O-I-E. :'( Au sujet de l'acceptation de la torture et de son efficacité, y'a le film « No-Limit » (avec de bons gros clichés dedans, malheureusement). Je pense que les questions souffrent de l'effet « nimby » : les sondé-e-s ne s'identifient pas à un poseur de bombes, à un dealer ou à un détendu (cas utilisés dans les questions) car "je suis gentil moi, je n'ai rien à cacher" ce qui amène à penser "la torture c'est bien sur les méchants". La bonne question serait celle qui permettrait de demander au-à la sondé-e "que penses-tu d'être torturé-e ou même juste violencé-e pour un acte, quelle que soit sa gravité, que tu n'as pas commis mais pour lequel tu es soupçonné-e, peut-être sans aucune preuve ?".

Via le Canard Enchaîné du 29 juin 2016.

Le temps de l’Euro de foot, la fan-zone de la tour Eiffel. ne facilite pas la vie des riverains. Ceux qui possèdent des véhicules ont dû retirer des macarons à la mairie du VIIe arrondissement pour pouvoir circuler jusqu’à leur domicile. Mais il est des Parisiens dont le temps est si précieux qu’ils ne peuvent pas se déplacer pour aller chercher l’indispensable laissez-passer. Il en va ainsi de Jean-Pierre El- kabbach, le célèbre intervieweur d’Europe 1, qui habite le long du Champ-de-Mars.

Aussi, le journaliste n’a pas hésité à s’adresser au sommet de l’Etat pour régler son cas personnel. Serge Boulanger, le directeur de cabinet adjoint du préfet de police de Paris, s’est fendu d’un mail personnel à la mairie du VIIe, le 9 juin, pour savoir s’il était « possible de récupérer le macaron pour M. Elkabach (sic). Il a saisi les hautes autorités. Merci à vous. Si besoin, je fais envoyer un chauffeur pour le récupérer ».

La mairie ayant tardé à répondre au préfet de police, Elkabbach est monté d’un cran dans la hiérarchie et a carrément saisi la Place Beauvau. Le ministère de l’Intérieur a dépêché en urgence un fonctionnaire pour retirer en personne le macaron du journaliste et le lui faire porter.

Sous bonne escorte du Raid ou du GIGN, on l’espère.

Heu ? C'est une blague ?! On est en mode Gorafi, rassurez-moi ?! :/ Un mec lambda qui fait un boulot d'intervieweur (boulot comme un autre) a le droit à un privilège. Au moins 4 personnes ont été mobilisées pour livrer un truc absolument pas vital à un gus. Sérieux ? Ces personnes n'avaient pas mieux à faire ? Ou alors on décrète que tout citoyen-ne a le droit au même traitement de faveur.

Dans le Canard Enchaîné du 29 juin 2016.

J'utilise MATE comme environnement de bureau. Simplement parce que c'est ce qui me convient le mieux (et je suis passé par GNOME 2, KDE et un poil Xfce, sans compter les gestionnaires de fenêtre en tuile qui ne me conviennent pas du tout). Depuis mon passage à MATE, j'utilise un des thème fournis de base, blackMATE, avec quelques changements : j'utilise le sous-thème Bluebird pour le style des bordures des fenêtres. Simplement parce que c'est le plus lisible des thèmes fournis de base selon moi et que je n'ai ni le temps ni l'envie d'écumer les sites web qui proposent d'autres thèmes.

Mais ce thème à un soucis : dans Firefox, sur certains sites web genre Bing ou Youtube, le contenu des formulaires de recherche ou de saisie s'affiche en blanc sur fond blanc. Super lisible ! Remarque, parfois c'est écrit en noir sur fond noir, comme sur mon site web perso. :P Je n'ai pas ce problème avec Chromium. Ni avec mes autres logiciels graphiques habituels.

J'avais aucune idée de comment résoudre ce problème mais un moteur de recherche m'a proposé ceci :

Close (exit) all instances of Firefox.
Go to your profile folder. It is here: /home/your_name/.mozilla/firefox/randomstring.default
In there, look for a subfolder called chrome. If it doesn't exist, create it.
If chrome does exist, look for a file called userContent.css. Otherwise, create an empty file with this name in the chrome folder.
Now open userContent.css with a text editor and paste in this code:
INPUT, TEXTAREA {color: black !important; background: #aaaaaa !important; }
Save the file (as plain text) and close the text editor.
Restart Firefox.

Ça juste fait le job. :) J'ai juste remplacé « input » par « input[type="text"] » afin que ma modification ne déborde pas sur les boutons comme les boutons modifier/supprimer de shaarli. ÉDIT DU 30/07/2016 À 15H15 : sauf que dans la vraie vie, beaucoup de sites web sont codés avec les pieds et ne précise pas le type donc le style ne s'applique pas alors qu'on en a besoin. Du coup, je ne le précise plus. FIN DE L'ÉDIT.

Je me sens un peu stupide de ne pas y avoir pensé plus tôt vu que je connais l'existence de ce fichier et de ce qu'on peut faire avec genre masquer les liens commerciaux dans Google Search depuis plusieurs années…

ÉDIT DU 30/07/2016 À 15H15 : ça ne fonctionne pas avec les textarea de certains sites web genre ce qui est basé sur dokuwiki. Pour que ça fonctionne, il faut ajouter la propriété CSS « -moz-appearance: none !important; » (source : https://support.mozilla.org/en-US/questions/814083 ). Au final, mon userContent.css a la contenu suivant :

input, textarea, select {
    color: black !important; 
    background: #ffffff !important;
    -moz-appearance: none !important;
}

FIN DE L'ÉDIT.

Dans tous les emails reçus, OpenDKIM écrit « Authentication-Results [...] dkim=pass reason="XXXX-bit key; unprotected key" [...] ».

« unprotected key » ne signifie pas que la clé cryptographique utilisée est d'une taille insuffisante mais que, soit le domaine de l'émetteur n'est pas signé avec DNSSEC, soit la validation DNSSEC locale a foiré.

Pour rappel, DNSSEC c'est la signature cryptographique des enregistrements DNS. Cela permet d'en garantir l'authenticité et la non-altération (mais ça n'apporte pas la confidentialité, attention !). Dans le cas présent, si le serveur mail de destination veut vérifier la signature DKIM (que le serveur de mails émetteur a généré avec sa clé privée), il faut utiliser la clé publique associée. Comment trouver toutes les clés de tous les serveurs mails du monde ? Dans le DNS. Oui, mais cette clé publique peut être substituée par un tiers lors de sa récupération via le réseau par le serveur de mails destinataire. Ainsi, il est théoriquement possible d'émettre des mails usurpés en indiquant avec DKIM qu'ils proviennent bien du domaine usurpé, c'est-à-dire en masquant l'usurpation.

Bon, faut le dire tout de suite : on est dans une attaque de haut vol, qui cible deux canaux en même temps, etc. On est vraiment dans de l'attaque purement théorique, les spammeurs et autres arnaqueurs-ses par email utilisent des techniques beaucoup plus simples que ça, hein. D'autant plus que DNSSEC est très peu utilisé. D'autant plus que DKIM ne sert pas vraiment à grand-chose : les spammeurs savent en faire pour que leur merde passe partout. Le seul intérêt de faire du DKIM sur son serveur de mails perso est de ne pas se faire envoyer boulet par les géants du mail (Google, Microsoft, Yahoo, etc.) qui l'exigent de plus en plus.

Pour vérifier les signatures DNSSEC, on peut soit faire confiance au récursif DNS qui fait la validation des signatures pour vous, soit le faire en local. Dans le deuxième cas de figure, on peut effectuer la validation soit dans chaque programme, soit mutualiser ça dans une lib. Les devs d'OpenDKIM ont choisi d'utiliser une vérification locale, avec la libunbound (du nom du logiciel serveur récursif DNS Unbound). Le problème d'utiliser un récursif DNS validant est que, s'il n'est pas local, la validation peut être contournée. En crypto, c'est le problème du dernier kilomètre (voir http://www.bortzmeyer.org/ou-valider-dnsssec.html ).

Pour que la libunbound puisse effectuer les vérifications cryptographiques, il faut lui donner la clé publique de la racine DNS. Ainsi, on peut valider toute la chaîne, du domaine jusqu'à la racine. Un-e attaquant-e qui voudrait usurper mon enregistrement DKIM (ou autre, hein, mais je reste dans le sujet de ce shaarli) devrait le signer avec la clé privée associée à mon domaine (guiguishow.info.)… Mais il ne l'a pas. Et s'il signe avec une clé perso, le récursif validant verra que cette clé n'est pas celle que j'ai indiquée à mon domaine parent (exemple : info.) pour mon domaine (guiguishow.info.). Allez, soyons fous, l'attaquant-e refait un faux bout de la zone parente (info.). Même problème, il n'a pas la clé privée. Donc il fait encore une clé perso. Pas de bol, ça ne correspondra pas avec ce qu'il y a dans le domaine parent : la racine, « . ». Allez, il refait une clé bidon et un faux bout de la zone racine et… ça ne fonctionnera pas car le récursif DNS connaît la clé de la racine ICANN. Comment ? Elle était intégrée dans le package qui permet son installation (et OpenPGP garantit son intégrité). Il peut également la récupérer, en HTTPS, sur le site web de l'IANA ( https://data.iana.org/root-anchors/root-anchors.xml ).

Je trouve pénible et non pertinent le choix des devs d'OpenDKIM d'utiliser une lib plutôt qu'un récursif validant : dans n'importe quel système GNU/Linux, un récursif DNS est livré pré-configuré avec la validation DNSSEC activée, un exemplaire de la clé publique de la racine, le processus de rafraîchissement de la clé déjà configuré, etc. En gros : installer un tel serveur sur votre réseau local et vous êtes tranquilles. Alors qu'utiliser la libunbound impose de la configuration en plus, de mettre en place nous-mêmes le processus de rafraîchissement de la clé, etc. Sauf à installer Unbound sur la machine. No-way, je ne veux pas d'un récursif DNS sur chacun de mes serveurs de mails. Un seul sur le réseau de mes serveurs est suffisant !

Unbound et la libunbound ( cf https://www.unbound.net/documentation/libunbound-tutorial-6.html - « ub_ctx_set_option(ctx, "auto-trust-anchor-file:", "keys") (not shown in example) can be used to use auto-updated keys (with RFC5011), the file is read from and written to when the keys change. The probes have to be frequent enough to not lose track, about every 15 days. ») supportent la méthode de rafraîchissement des clés définie dans le RFC 5011. C'est pour cela qu'il est inutile de faire tourner Unbound-anchor en cron. ÉDIT DU 01/07/2016 À 15H00 : Heu, inutile si l'on fait tourner un démon Unbound mais si l'on utilise la libunbound, il faut un cronjob, la lib. FIN DE L'ÉDIT.

À côté de ça, il est conseillé d'utiliser Unbound-anchor (qui, en gros, si la clé livrée avec ne fonctionne pas, tente de récupérer la nouvelle sur le site web de l'IANA). Le manuel (https://www.unbound.net/documentation/howto_anchor.html) explique bien pourquoi : « Unbound uses RFC5011 updates to keep the anchor updated if it is changed while the computer is in operation, but the unbound-anchor tool is used if it is changed while the computer is not in operation. ». Là encore, on est sur un risque théorique qui a une faible probabilité de se produire sur un serveur qui est ON 99 % du temps mais bon, faisons les choses bien.

Allons-y pour la pratique. \o/

On installe unbound-anchor

sudo apt-get install unbound-anchor

On crée une nouvelle unit systemd qui lancera unbound-anchor, /etc/systemd/system/unbound-anchor.service , par exemple, qui contient :

[Unit]
Description=Update of the root trust anchor for DNSSEC validation in libunbound (for OpenDKIM)
Documentation=man:unbound-anchor(8)

[Service]
Type=oneshot
ExecStart=/usr/sbin/unbound-anchor -a /var/lib/dkim/dnssec.root.key
SuccessExitStatus=1

[Install]
WantedBy=multi-user.target

Cette unit est inspirée de https://bugzilla.redhat.com/attachment.cgi?id=983267&action=diff . Le dossier /var/lib/dkim doit exister. Perso, c'est là où je range la clé privée utilisée par OpenDKIM.

« SuccessExitStatus=1 » permet d'indiquer à systemd que, si ce programme quitte avec un code de retour 1, ce n'est pas une erreur. Cela s'ajoute au code de retour 0 habituel qui indique que tout s'est bien déroulé. En gros, Unbound-anchor peut sortir avec un code de retour = 0 ou 1. Et c'est conforme avec le manuel d'Unbound-anchor (http://linux.die.net/man/8/unbound-anchor ) : « This tool exits with value 1 if the root anchor was updated using the certificate or if the builtin root-anchor was used. It exits with code 0 if no update was necessary, if the update was possible with RFC5011 tracking, or if an error occurred. ». Bon, par contre utiliser le code de retour 0 pour dire à la fois que ça va bien et qu'il y a une erreur, c'est crade, vraiment. :(

On active la nouvelle unit :

sudo systemctl daemon-reload 
sudo systemctl enable unbound-anchor.service

On lance la nouvelle unit et l'on vérifie que ça a bien créé le fichier /var/lib/dkim/dnssec.root.key :

sudo systemctl start unbound-anchor

On modifie l'initscript d'OpenDKIM pour qu'il se lance après Unbound-anchor : dans /etc/init.d/opendkim, on ajoute « unbound-anchor » à la fin de la ligne « Required-Start: ».

ÉDIT DU 15/01/2017 À 16H : L'idée est bonne mais lors d'une mise à jour d'opendkim, le script postinst d'opendkim (/var/lib/dpkg/info/opendkim.postinst) invoquera update-rc.d qui sortira en erreur :

insserv: Service unbound-anchor has to be enabled to start service opendkim
insserv: exiting now!
update-rc.d: error: insserv rejected the script header

Hé oui, il n'existe pas de script d'init au format sysvinit équivalent à notre unit systemd pour unbound-anchor. Soit on décide de remettre le script sysvinit d'opendkim dans son état d'origine le temps de faire un dpkg --configure -a, soit on modifie le script postinst d'opendkim soit on créer un bête script sysvinit /etc/init.d/unbound-anchor … Perso, j'ai décidé de modifier le script postinst (et d'ajouter un divert dpkg) pour commenter la ligne update-rc.d opendkim defaults >/dev/null.

FIN DE L'ÉDIT.

On indique à systemctl de prendre en compte la modif :

sudo systemctl daemon-reload 

On vérifie que la modification a bien eu lieu :

systemctl show opendkim.service | grep -i after

« unbound-anchor.service » doit apparaître.

Pour que cette modification ne disparaisse pas lors d'une mise à jour d'OpenDKIM :

sudo dpkg-divert --add --no-rename --divert /etc/init.d/opendkim.dpkg-dist /etc/init.d/opendkim
sudo systemctl daemon-reload

On crée un cronjob dans /etc/cron.daily/unbound-anchor, par exemple avec le contenu suivant :

#!/bin/bash

logger -p user.notice -t unbound-anchor-cron "Updating DNS root key..."

/usr/sbin/unbound-anchor -a /var/lib/dkim/dnssec.root.key

exit 0

Ça ne sert à rien de vérifier le code de retour vu que 0 et 1 signifient une réussite et 0 peut signifier une réussite ou un échec, dixit le man… Grâce à la priorité (-p user.notice), syslog enverra les logs de cette tâche cron dans /var/log/user.log.

On n'oublie pas de rendre ce script exécutable :

chmod  +x /etc/cron.daily/unbound-anchor

On ajoute ce qui suit à la configuration d'OpenDKIM (/etc/opendkim.conf) :

# DNSSEC validation
ResolverConfiguration   /etc/opendkim.libunbound.conf

On crée le fichier /etc/opendkim.libunbound.conf avec le contenu suivant :

server:
        auto-trust-anchor-file: /var/lib/dkim/dnssec.root.key

On redémarre OpenDKIM :

sudo systemctl restart opendkim

Maintenant, OpenDKIM fait de la validation DNSSEC lorsqu'il récupère les clés publiques nécessaires à la validation des signatures DKIM. Dans le source des emails, il écrira : « Authentication-Results: [...] dkim=pass reason="XXXX-bit key; secure key" » à condition, évidemment, que le domaine de l'émetteur utilise DNSSEC.

Host names may contain only alphanumeric characters, minus signs ("-"), and periods ("."). They must begin with an alphabetic character and end with an alphanumeric character.

Pas de FQDN (un nom de domaine où tous les composants sont cités y compris, en toute logique, la racine, « . » final) dans /etc/hosts, OK, je savions pas. :O

« 0.0.0.1 nogo.example. » ne fonctionne pas (la libc ne trouve pas de correspondance et passe à l'annuaire suivant, le DNS (sauf configuration contraire dans /etc/nsswitch.conf, voir http://shaarli.guiguishow.info/?kYFC5w ). « 0.0.0.1 nogo.example » est la bonne syntaxe.

Si vous utilisez OpenVPN et Easy-RSA (pour gérer simplement toute la cryptographie qu'il y a derrière), alors le certificat x509 de votre serveur VPN a une durée de vie d'un an, comme le certificat d'un-e utilisateur-rice de votre VPN. Non, je ne parle pas de votre AC mais bien du serveur VPN.

Pour le renouveler :

• On suppose qu'une seule AC est utilisée, la même pour votre serveur que pour vos utilisateur-trices et on suppose que c'est une AC perso (auto-générée avec Easy-RSA) ;
• On suppose qu'Easy-RSA travaille dans le dossier /etc/openvpn/easy-rsa/ ;

• On suppose que le serveur prend ses fichiers cryptos (cert de l'AC des clients, son certificat et sa clé à lui, les paramètres DH, etc.) dans /etc/openvpn/crypto/ ;

• Révoquer le certificat actuel :

  sudo -i
  cd /etc/openvpn/easy-rsa
  . ./vars
  ./revoke-full server
  rm /etc/openvpn/easy-rsa/keys/server.*

• Mettre à jour la liste des révocations :

  cp /etc/openvpn/easy-rsa/keys/crl.pem /etc/openvpn/crypto/crl.pem

• Générer une nouvelle paire de clés et un certificat :

  ./build-key-server server

Lorsqu'easy-rsa demande « Common Name (eg, your name or your server's hostname) », saisir le FQDN de votre serveur VPN genre vpn.arn-fai.net. Accepter tout le reste.

• Déplacer le nouveau certificat (et la clé privée) à l'emplacement de l'ancien :

  cp /etc/openvpn/easy-rsa/keys/server.{key,crt} /etc/openvpn/crypto/
  rm /etc/openvpn/easy-rsa/keys/server.{key,csr}

Pas de mv car il faut conserver le crt dans l'arborescence d'easy-rsa.

• Redémarrer OpenVPN pour que le nouveau certificat soit utilisé :

  systemctl restart openvpn@udp openvpn@tcp