GuiGui's Show

Toutes ces attaques DDoS, que ça soit contre Dyn ou contre OVH me font rire jaune car la responsabilité est partagée et qu'on trouve des Picsou à tous les étages (ou presque) :

• D'un côté, on a des équipementiers (et ça date d'avant l'IOT, faut pas charrier) qui voient la sécurité comme une contrainte financière : ça coûte de l'argent de dev' de bons produits. Ça coûte de la R&D donc du blé de trouver comment faire de la sécurité sur des tout petits objets qui ont que dalle d'électricité, de RAM, de CPU, etc. C'est un monde nouveau donc on se dit qu'on peut se passer de l'expérience acquise ces 20-30 dernières années en informatique "traditionnelle" ;
  
  
• À cela s'ajoute des failles qui ne sont jamais patchées car personne n'a envie de mettre à jour ses XXXXX objets connectés ni même tous ses ordinateurs connectés à Internet de manière générale. C'est chiant, il fait beau dehors, affaire classée. Même chose pour les milliers d'équipements avec un mot de passe par défaut : c'est chiant de changer le mot de passe par défaut, faut s'en souvenir, l'utilisateur moyen ne sait même pas qu'il y en a un, bref, on veut du matos plug & forget. Et encore, là je parle des cas optimistes où il est possible de changer le mot de passe (on va y revenir au point suivant) et/ou que des mises à jour sont diffusées par l'équipementier et/ou que l'équipement puisse techniquement être mis à jour ;
  
  
• À cela s'ajoute les backdoors, les accès privilégiés que se laissent les équipementiers… avec la meilleure intention : màj auto par l'équipementier, support client simplifié, etc. C'est une partie de l'attaque contre Dyn : https://boingboing.net/2016/10/24/xiongmai.html - « That’s because while many of these devices allow users to change the default usernames and passwords on a Web-based administration panel that ships with the products, those machines can still be reached via more obscure, less user-friendly communications services called “Telnet” and “SSH.” [...] “The issue with these particular devices is that a user cannot feasibly change this password,” Flashpoint’s Zach Wikholm told KrebsOnSecurity. “The password is hardcoded into the firmware, and the tools necessary to disable it are not present. Even worse, the web interface is not aware that these credentials even exist.” » ;
  
  
• D'un autre côté, on a des sociétés commerciales (« Twitter, le PlayStation Network (PSN), PayPal, eBay ou encore Spotify, Netflix, etc. » - http://www.numerama.com/tech/203367-comment-des-cameras-de-surveillance-ont-rendu-inaccessible-une-partie-du-web.html), qui ont tout leur business sur le Net, qui comptent dans leurs rangs, des ingénieurs brillants qui savent quand même ce qu'est Internet… mais qui font le choix d'utiliser un seul et même hébergeur DNS. Allô. Internet, on essaye de ne pas créer de centre. Allô, ça fait des années et des années que les bonnes pratiques sont d'avoir plusieurs hébergeurs DNS qui utilisent des prestataires réseaux différents. Mais avoir une infra internationale redondée, ça coûte du blé. Avoir recours à plusieurs prestataires simultanément, ça fait grimper les charges sans rien apporter en produit lors d'un exercice comptable normal ;
  
  
• Mais, enfin, éviter les centres, héberger chacun-e nos moyens de communication et de diffusion des savoirs chez nous ou dans la petite structure locale n'empêchera de pouvoir réduire des petits acteurs au silence : https://benjamin.sonntag.fr/DDOS-sur-La-Quadrature-du-Net-analyse . Une prise de conscience à tous les étages, des équipementiers, aux fournisseurs de services en passant par les utilisateur-rice-s d'objets connectés kikoos ou simplement d'ordinateurs quel que soit leur format, apparaît nécessaire.

Bref, on pourra compter les DDoS, s'étonner devant leurs centaines de Mbps et aujourd'hui leurs Tbps mais ça n'aide pas : le changement à opérer est structurel et multi-acteurs. Mais, après tout : « à cœur vaillant rien d'impossible ».

[...] The botnet is having DoS attack mechanism like UDP flood, TCP flood, along with other series of attack methods, in both IPv4 and IPv6 protocol, with extra IP spoof option in IPv4 or IPv6 too.

Via https://twitter.com/bortzmeyer/status/793148787770400769

Un rapport qui se bonifie d'années en années en ajoutant des métriques intéressantes : en plus de BGP/route/RPKI+ROA et DNS/DNSSEC, on a désormais la dispersion des serveurs de mails entrants (introduit en 2014) et TLS (introduit en 2015).

L’observatoire encourage l’ensemble des acteurs de l’Internet à s’approprier les bonnes pratiques d’ingénierie admises pour les protocoles BGP [3], DNS [4], et TLS, et à anticiper la menace que représentent les DDoS [5]. D’autre part, l’observatoire énonce les recommandations suivantes :

• surveiller les annonces de préfixes et se tenir prêt à réagir aux usurpations ;
  
  
• utiliser des algorithmes supportant la confidentialité persistante, et abandonner SSLv2 et SHA-1 au profit de mécanismes plus robustes ;
  
  
• diversifier le nombre de serveurs SMTP et DNS afin d’améliorer la robustesse de l’infrastructure ;
  
  
• appliquer les bonnes pratiques notamment celles rappelées dans ce document, pour limiter les effets des pannes et des erreurs d’exploitation ;
  
  
• poursuivre les déploiements d’IPv6, de DNSSEC, et de la RPKI, afin de développer les compétences et d’anticiper d’éventuels problèmes opérationnels.

[...]

BGP

[...]

En 2015, à l’aide de la méthode définie dans les précédents rapports, l’observatoire a identifié 1588 AS français. Parmi ceux-ci, 1001 sont visibles dans les archives BGP, c’est-à-dire qu’ils ont annoncé au moins un préfixe pendant l’année. Un noyau dur de 869 AS actifs annonce au moins un préfixe par jour tout au long de l’année 2015, ce qui représente environ 87 % du nombre total d’AS distincts visibles au cours de l’année. Parmi les 13 % d’AS visibles restant, environ 50 % d’entre eux l’ont été pendant la moitié de l’année. Enfin, 587 AS répertoriés n’ont pas annoncé de préfixe en 2015.

[...]

[...] Pour IPv6, il est intéressant de noter que le graphe de connectivité comporte beaucoup moins d’AS qu’en IPv4.

[...]

L’Internet français dépend d’AS étrangers pour faire transiter le trafic entre certains AS français. L’enveloppe de l’Internet français contient l’ensemble des AS français et tous les AS se trouvant entre deux AS français sur un AS_PATH. La figure 1.5 montre, qu’en IPv4, leur nombre a crû lentement tout au long de l’année pour atteindre 293, un nombre légèrement inférieur à celui observé en 2014. En IPv6, comme en 2013 et 2014, une cinquantaine d’AS étrangers sont nécessaires pour interconnecter tous les AS français.

[...]

L’impact de la panne d’AS pivots est un élément important qui permet d’évaluer la robustesse de la connectivité. La figure 1.7 montre qu’en IPv4, seuls 7 AS pivots affecteraient au moins 10 AS en cas de défaillance. Il s’agit d’une légère amélioration par rapport à 2014. En revanche, l’AS pivot le plus critique aurait un impact sur 42 AS, contre 35 en 2014. Ce résultat, sans être dramatique, pointe cependant la nécessité d’être vigilant quant aux évolutions de dépendance des AS. Pour IPv6, la figure 1.8 montre qu’il existe moins d’AS pivots qu’en IPv4 [ NDLR : 4 versus 7 en IPv4 ]. Cependant, vis-à-vis de 2014, le nombre d’AS pouvant être déconnectés a augmenté. Il s’agit d’un résultat intéressant qui découle naturellement de l’évolution de l’Internet IPv6 français, et de la croissance du nombre d’AS IPv6 pivots.

[...]

En IPv6, le nombre d’AS a augmenté de 13 % en 2015, contre 6 % l’année précédente. Le nombre d’AS pivots a quant à lui légèrement augmenté. Cela semble indiquer un accroissement du déploiement d’IPv6 par les AS français.

[...]

En 2015, l’observatoire a détecté 6392 conflits d’annonces. Ils ciblent 344 AS français distincts, et 1350 préfixes. [...] Ainsi, seuls 2070 conflits anormaux seront considérés lors de l’identification des usurpations. [...] Sur les 2070 conflits anormaux, 1480 conflits correspondent à des réannonces de table globale [ NDLR : 71 %, quoi ] . [...] Au cours de l’année 2015, l’observatoire a mis en évidence 149 conflits anormaux qui correspondent à des protections contre les DDoS [...] Le filtrage basé sur la similarité des noms des AS a permis d’identifier 4 conflits entre un opérateur et sa filiale française. Celui sur les numéros d’AS a mis en évidence une erreur de configuration d’un routeur BGP ayant engendré 5 conflits distincts. Ces filtres automatiques limitent efficacement les analyses manuelles à effectuer. Seuls 89 conflits anormaux, doivent ainsi être étudiés attentivement. À l’issue des analyses automatiques et manuelles, il reste 40 conflits anormaux qui pourraient être des usurpations de préfixes. Afin de réduire leur nombre, seuls les conflits anormaux comportant des annonces plus spécifiques sont conservés. Il apparait ainsi que 26 conflits anormaux correspondent à des usurpations dont les durées vont de cinq minutes à quatre jours.

[...]

Une fois la corrélation effectuée, seuls 35 AS sont à l’origine de réannonces de table globale. Certains AS ayant fait des réannonces plusieurs fois en 2015, ces résultats correspondent à 38 réannonces de table globale dans l’année, soit plus de 3 par mois. Parmi ces 35 AS, seulement 14 ont été en conflit avec des AS français aux dates où les réannonces de table globale ont été détectées, impactant 175 AS français au total.

[...]

L’algorithme utilisé est restrictif et tend à minimiser le nombre de faux positifs au détriment du nombre de faux négatifs. Une analyse manuelle a confirmé que le nombre total de réannonces de table globale dépasse les 38 détectées.

[...]

Au cours de l’année 2015, l’observatoire a mis en évidence 149 conflits anormaux qui correspondent à des protections contre les DDoS, allant de quelques heures à plusieurs mois. Les AS français protégés sont de natures différentes, comme des hébergeurs, des assurances, ou des sites de paris en ligne. Il est intéressant de souligner qu’aucun des opérateurs spécialisés utilisés n’était français.

[...]

Début juillet, un AS russe a été à l’origine de 5 conflits distincts ciblant un AS français. Ce comportement est suspect, et similaire aux observations effectuées en 2014 liées aux campagnes de spam [17]. Durant l’année, il a annoncé près de 150 préfixes différents ne lui appartenant pas. Parmi les autres conflits anormaux, une dizaine correspond très probablement à d’autres campagnes de spam utilisant BGP. Un AS roumain identifié dans le rapport précédent a effectué ce type d’usurpations en 2015.

[...]

Finalement, 15 conflits anormaux possèdent des caractéristiques semblant indiquer qu’il s’agit très probablement d’usurpations de préfixes ayant touché des AS français.

[...]

Les destructions d’objets route et objets route6 inutilisés ne sont pas systématiques et restent très marginales par rapport aux nouvelles déclarations.

[...]

RPKI+ROA

[...]

L’étude des déclarations effectuées dans le dépôt du RIPE-NCC de la RPKI montre que le nombre d’AS participants a crû au cours de l’année 2015. Au début du mois de janvier, 198 AS français avaient des ROA dans la RPKI. Au 31 décembre, la RPKI contient des déclarations issues de 237 AS français, ce qui représente une croissance de près de 20 %. On remarque que cette augmentation est bien plus faible que celle observée au cours de l’année précédente. En 2014, le nombre d’AS participant à la RPKI avait augmenté de près de 80 % entre le début du mois de janvier et la fin du mois de décembre.

[...]

Au 31 décembre 2015, environ 65 % de l’espace d’adressage est valide selon la RPKI. En parallèle, les pourcentages de l’espace d’adressage non couvert et de l’espace d’adressage invalide sont restés stables au cours de l’année. Au 31 décembre 2015, 34,4 % de l’espace d’adressage n’était pas couvert. Le pourcentage de l’espace d’adressage invalide reste, quant à lui, relativement faible au cours de l’année. À la fin de l’année 2015, ce pourcentage est de 0,4 %. En ce qui concerne IPv6, l’espace d’adressage géré par les AS français est très faiblement couvert par les déclarations de la RPKI. À la fin de l’année 2015, les ROA couvraient moins de 1 % de cet espace d’adressage. Il n’y a donc pas eu d’évolution significative de cette couverture depuis 2014.

Donc RPKI+ROA progresse mais doucement et uniquement en IPv4.

[...]

Ces résultats montrent qu’en cas de filtrage strict basé sur la RPKI, près de 12 % des AS actifs à la fin de l’année 2015 verraient l’ensemble de leurs préfixes propagé dans l’Internet. Cette proportion est comparable à la valeur observée en 2014.

DNS

[...]

Le risque d’un TLD indisponible n’est pas théorique. Par exemple, en décembre 2015, le TLD .tr a subi une attaque DDoS 7 pendant trois semaines [21], avec des périodes où l’ensemble de ses serveurs DNS étaient inaccessibles.

[...]

Le nombre d’enregistrements NS par zone déléguée reste suffisant pour permettre une bonne résilience, du point de vue de cet indicateur. En effet, moins de 1 % des zones n’utilisent qu’un seul enregistrement NS, qui pourrait donc constituer un SPOF.

[...]

[...] Le déploiement d’IPv6 sur les serveurs DNS faisant autorité a stagné en 2015. Ainsi, environ 41 % des zones ne sont accessibles qu’en IPv4.

[...]

En 2015, le nombre moyen d’AS par zone reste équivalent à celui de 2014, et stagne à 1,2. Par ailleurs, la quantité de zones hébergées par un seul AS reste stable depuis 2011, culminant à 83 % des zones étudiées.

[...]

Répartir, ou être en mesure de répartir, ses serveurs de noms dans des préfixes /24 en IPv4 et /48 en IPv6 distincts peut également constituer une bonne pratique de résilience 9 . Cela permet notamment de limiter les zones de pollution BGP et d’accroître l’agilité face aux dénis de service distribués.

Ha ouaiiiis, j'y avais jamais pensé : si l'on ne peut pas externaliser ses zones dans plusieurs AS, une dispersion par préfixe permettra de réagir, certes de manière rustique, à une attaque DDoS.

L’étude de la répartition des serveurs de noms dans des préfixes est effectuée uniquement sur les zones étant hébergées sur au moins deux adresses IP. En IPv4, la figure 2.4a montre que 87 % des zones peuvent être ou sont annoncées dans des préfixes /24 distincts. En IPv6, ce chiffre s’élève à 98 % pour des préfixes /48 distincts, comme détaillé dans la figure 2.4b.

[...]

Comme pour les années précédentes, en 2015, tant en IPv4 qu’en IPv6, près de 82 % des zones étudiées sont servies exclusivement par des serveurs faisant autorité situés dans un même pays. *En IPv4, les zones dont tous les serveurs DNS faisant autorité sont dans un même pays étranger représentent 27 % des zones étudiées. Il convient néanmoins de noter que 75 % d’entre elles sont hébergées dans un pays ayant une frontière terrestre avec la France métropolitaine. Cette situation ne présente donc, a priori, pas un risque significatif. Pour près de 20 % de ces zones, le constat est plus mitigé, ces dernières étant hébergées en Amérique du Nord.

Pour IPv6, les zones hébergées dans un seul pays étranger représentent 30 % des zones ayant des serveurs DNS accessibles en IPv6. Parmi celles-ci, près de 85 % sont hébergées dans un pays ayant une frontière terrestre avec la France métropolitaine.

[...]

DNSSEC

[...]

Un peu moins de 9 % des zones étudiées mettent en œuvre DNSSEC en 2015. La croissance est essentiellement due à la création de nouvelles zones en 2015.

On voit le poids de l'inertie mais aussi la centralisation : il suffit qu'un gros hébergeur DNS propose une option "DNSSEC en 1 clic" et lala.

[...]

Près de 92 % des zones étudiées mettent en œuvre l’algorithme de hachage SHA-1, jugé insuffisant d’après les bonnes pratiques actuellement admises en cryptographie. À l’inverse, près de 98 % des zones étudiées utilisent bien l’algorithme de hachage recommandé SHA-256 pour créer la chaîne de confiance DNSSEC.

Parce que c'est les bureaux d'enregistrement qui poussent en SHA-256 de manière automatique, peut-être ?

[...]

SMTP

[...]

Un seul relais de messagerie est renseigné pour 38 % des zones déléguées. Le risque d’impossibilité de recevoir de nouveaux messages électroniques est donc accru par la présence d’un SPOF.

[...]

Un unique enregistrement MX ne signale pour autant pas la présence d’un SPOF au niveau du plan d’adressage. En effet, plusieurs adresses IP peuvent être indiquées pour un même nom de domaine ou une IP peut être annoncée sur l’Internet en employant la technique de l’anycast. De même, une adresse IP peut être virtuelle et répartie sur plusieurs serveurs physiques, grâce à des répartiteurs de charge.

[...]

IPv6 reste peu déployé. Ainsi, pour près de 89 % des zones, aucun des noms de serveur contenus dans les enregistrements MX n’a d’adresse IPv6 associée. Parmi les 11 % restants, pour 81 % de ces zones, un seul nom contenu dans les enregistrements MX peut être résolu en une unique IPv6.

Ainsi, IPv6 progresse au niveau routage mais on ne voit pas encore de répercussions au niveau service (DNS et SMTP) ?

[...]

Jusqu’à 86 % des zones étudiées introduisent au moins un SPOF dû au choix des noms de leurs relais de messagerie. En particulier, 64 % des zones étudiées créent deux SPOF en utilisant des noms situés dans un nom public situé sous un unique TLD tiers.

[...]

[...] En particulier, 71 % des relais de messagerie sont hébergés par quatre opérateurs. Cette concentration peut parfois aider à la mutualisation des moyens. Cela peut présenter un intérêt pour la défense contre certaines attaques en déni de service. Le filtrage du courrier indésirable peut également être partagé. Il convient de noter, néanmoins, un risque de défaillance collective en cas d’incident affectant les composants mis en commun.

Concentration SMTP aussi forte que DNS (70 % des zones hébergées par 4 hébergeurs DNS en 2013 selon le même rapport.

[...]

L’essentiel des relais de messagerie des zones étudiées est localisé en France, tant en IPv4 qu’en IPv6.

[...]

La concentration des relais de messagerie entrants sur quelques opérateurs réseaux est significative. En IPv4, un opérateur est responsable de la connectivité de 47 % des relais des zones étudiées. En IPv6, ce chiffre monte à 69 %.

[...]

TLS

[...]

Les mesures de l’observatoire se sont concentrées sur les ressources web accessibles à travers l’Internet français. Elles concernent plus spécifiquement les ressources exposées via le port 443, traditionnellement alloué par les serveurs aux échanges HTTPS. Les enjeux liés aux ressources de messagerie en ligne diffèrent en plusieurs points [45] et ne sont pas abordés dans le présent rapport.

Les noms de domaine issus du registre maintenu par l’Afnic 5 ont été préfixés de www. avant d’être résolus. Par exemple, les mesures effectuées sur le domaine afnic.fr correspondent à l’adresse IPv4 résolue pour www.afnic.fr. Lorsque le port 443 du serveur interrogé était ouvert, l’observatoire a envoyé différents stimulus ClientHello, dont les variations visaient à évaluer plusieurs capacités du serveur, telles que sa prise en charge de la confidentialité persistante ou encore sa tolérance envers des versions obsolètes du protocole.

[...]

L’extension SNI 6 [41] n’ayant pas été utilisée au sein des ClientHello, les mesures ne réunissent pas l’ensemble des ressources exposées via HTTPS sur la zone .fr. En interrogeant de ce fait un serveur par nom de domaine résolu, un sous-ensemble de 61 216 serveurs accessibles a ainsi été interrogé en juillet 2015, contre 26 261 en février 2014.

[...]

75 % des serveurs sont aptes à négocier une session TLS 1.2, en nette augmentation par rapport aux 54 % de 2014.

[...]

TLS 1.2 est couramment pris en charge par les serveurs de la zone .fr en 2015. TLS 1.0 est présent à égale mesure, mais clients comme serveurs devraient privilégier la version la plus récente du protocole.

[...]

En 2015, l’offre de confidentialité persistante s’est généralisée sur la zone .fr. Les serveurs doivent privilégier cette méthode auprès des clients qui la prennent en charge.

On passe de 50 % à 74 %.

[...]

En 2015, de nombreux serveurs tolérant SSLv2 sont apparus. Cette version de protocole doit être abandonnée au plus vite.

WTF sérieux…

[...]

Le tableau 3.1 fait état du nombre de certificats distincts relevés au cours des deux campagnes de mesure lancées sur la zone .fr en 2014 puis 2015. À près de dix-huit mois d’écart, la proportion de certificats auto-signés de 41 % est restée inchangée.

Comme quoi, Let's Encrypt partout, ce n'est pas le mot d'ordre de tout le monde (et à juste titre selon moi, voir http://shaarli.guiguishow.info/?i-OcNA ).

[...]

Mi-2015, le taux de présence de SHA-2 est monté à 55 %, et le taux de présence de SHA-1 est descendu en conséquence à 44 %. [...]

Jusque-là, speech-dispatcher, dont tous les modules sont sous licence libre, supportait déjà de nombreuses solutions: Espeak, Mbrola, Svox Pico, Festival, ibmtts, Flite, pour ne parler que de celles connues. Malheureusement, la qualité de ces outils restait franchement moyenne pour des utilisateurs lambdas, débutants, voire non informatisés. Le grand public, âgé ou en situation de handicap, à qui on montre GNU/Linux avec Espeak recule. Précisons que parmi ces outils, peu sont libres, puisque les meilleurs ne le sont pas totalement (mbrola, ibmtts, svox, Pico). Espeak a de réels atouts, mais reste réservée à un public résistant à la voix robotique.

Or, d'autres synthèses (certes peu) ont déjà un support sur GNU/Linux. Elles ne sont pas libres non plus, mais leur qualité est supérieure en naturel et intelligibilité. Il ne restait donc qu'à les faire supporter par Speech-dispatcher pour que les gens y aient accès et découvrent un GNU/Linux sympathique dès le premier abord (eh oui, sauf à être sensibilisé, si le premier abord échoue, le grand public n'y revient pas, surtout vu l'exigence des populations pour qui l'informatique est un bien précieux au quotidien).

Depuis aujourd'hui, un patch a été soumis pour que Speech-dispatcher intègre un nouveau module. Il s'agit de Kali. Ce module, libre, permettra :

• d'accéder à 3 voix francophones supplémentaires, plus naturelles et intelligibles ;
• d'accéder à deux voix supplémentaires en anglais ;
• d'entendre l'ordinateur avec une voix féminine ou masculine.

Certes, pour profiter de cette synthèse vocale, il en coûtera près de 85 euros. Le module Speech-dispatcher la faisant tourner sur GNU/Linux est libre, mais pas la synthèse elle-même. Il faut cependant préciser que les chercheurs qui travaillent sur ce produit depuis plus de 30 ans sont de loin plus accessibles que les grands services de R&D des entreprises faisant autorité sur le secteur. L'ouverture de ce code n'est peut-être pas si loin malgré tout.

Je pense que cette sortie offre à ceux qui recherchent l'amélioration de la qualité vocale de nouvelles perspectives. Les personnes aveugles ou malvoyantes s'y intéresseront particulièrement. Grâce à ce module, Orca, le logiciel leur permettant de savoir ce qu'affiche leur écran, pourra leur parler avec une voix plus jolie. Et qui articule!

Je voulais revenir sur ça à tête reposée.

Très bonne analyse de Reflets.

Tuerie de San Bernardino -> le FBI veut accéder au contenu de l'iPhone d'un des auteurs de la tuerie sauf qu'il est intégralement chiffré -> le FBI exige la coopération d'Apple pour procéder au déchiffrement. Sauf qu'Apple n'a pas la clé car elle est unique à chaque iPhone et elle n'est pas stockée en dehors du téléphone. Apple ne veut pas produire un outil générique de contournement (qui serait signé avec la clé privée d'Apple donc qui serait lancé par le bootloader de tout appareil Apple et qui permettrait de ne pas activer la destruction du contenu après 10 essais de mdp infructueux et de simplifier le bruteforce du bouzin en autorisant la transmission des tentatives autrement qu'en les tapant sur le clavier) au motif qu'il sera utilisé par les autorités dans absolument tout type de dossier et par les criminels et par les dictatures et par les gouvernements de tout poil contre les ONG ou autre. -> le FBI traîne Apple en justice puis se désiste bien avant une décision définitive.

• Magnifique rôle de défenseur de la vie privée pour Apple… Sauf qu'Apple ne cause quasi pas du droit à la vie privée dans son mémoire adressée à la Cour de justice. C'est juste de l'esbroufe pour les médias ;
  
  
• Malgré le chiffrement intégral du téléphone, des données peuvent être récupérées via le cloud si la synchronisation entre le téléphone et le cloud a été activé, compte-tenu qu'Apple a la main sur ses serveurs. C'était visiblement le cas ici ( https://www.aclu.org/blog/free-future/one-fbis-major-claims-iphone-case-fraudulent ). Après, quand on me dit que le FBI aurait pu tout faire tout seul en sauvegardant la clé en dessoudant la puce flash du PCB, je suis dubitatif : faire une restauration tous les 10 essais en plein bruteforce, ça va prendre masse de temps donc le recours à Apple pour l'obtention d'un mécanisme plus rapide reste recevable sans que la thèse d'un "complot" soit plausible, àmha ;
  
  
• Malgré tout ça, une faille reste toujours possible. Il n'y a pas de sécurité dans l'absolu. Sauf qu'avec le petit jeu de dupes Apple/FBI, d'un côté on apprend que la faille est connue par des hackers (en dehors du cercle Apple/FBI initial, donc) et qu'Apple n'en aura jamais connaissance, ce qui remet en cause la sécurité de tous les utilisateur-rice-s de produits Apple… Quand tu affaiblis le chiffrement, c'est pour tout le monde, même pour le secteur de "l'économie numérique" ;
  
  
• Les autres fournisseurs de systèmes mobiles ne (s|f)ont pas mieux : http://www.nextinpact.com/news/97441-google-peut-deverrouiller-a-distance-terminal-android-sans-chiffrement-integral.htm pour Android et http://www.numerama.com/politique/164232-cle-maitre-detenue-police-canada-blackberry-assume.html ;
  
  
• Quand les autorités, US comme EU comme FR, assertent que le chiffrement, c'est l'impunité des criminels, c'est faux : un appareil chiffré et/ou des communications chiffrées ne sont jamais les seuls éléments d'une enquête, voir http://www.liberation.fr/futurs/2015/09/13/cryptographie-la-justice-cherche-la-cle_1381801 . D'ailleurs, le FBI a obtenu les données de connexion auprès de l'opérateur téléphonique, ce qui permet déjà de retracer les contacts, la localisation géographique, etc. Sans compter que ce téléphone était le téléphone pro de l'assassin, et qu'il avait détruit son téléphone perso ce qui laissait peu d'espoir dd'y trouver quelque chose ;
  
  
• … et, surprise, le téléphone en question ne contenait effectivement rien d'exploitable dans le cadre de l'enquête. Voir http://www.numerama.com/politique/165489-iphone-cracke-fbi-aurait-paye-plus-dun-million-de-dollars-rien.html et http://www.nextinpact.com/news/99482-iphone-deverrouille-pression-retombe-mais-questions-restent.htm ;
  
  
• On sait déjà que la trouvaille sera utilisée pour autre chose que des enquêtes portant sur des actes de terrorisme : http://www.nextinpact.com/news/99340-smartphones-verrouilles-fbi-est-loin-den-avoir-fini.htm et https://www.aclu.org/blog/speak-freely/map-shows-how-apple-fbi-fight-was-about-much-more-one-phone ;
  
  
• Tout cela laisse fortement à penser que le FBI cherche à avancer ses pions dans l'ère post-Snowden tout en ayant peur des décisions définitives que pourraient prendre la justice : http://www.numerama.com/politique/166085-apple-fbi-lappel-du-jugement-de-new-york-naura-pas-lieu-non-plus.html . Et je trouve ça plutôt positif : toute cette affaire nous montre que les autorités reconnaissent partiellement la nécessité du chiffrement et qu'elles ne sont pas sûres de pouvoir l'abolir comme ça taktak.

In November 2016, an investigation by journalists from the German TV channel NDR showed that WOT collects, records, analyzes and sells user-related data to third-parties, allowing third-parties to identify individual users, despite WOT's claims they would anonymize the data.[18][19][20] The data obtained was traceable to WOT and could be assigned to specific individuals.[21][22] The investigation was based on freely available sample data, and revealed that sensitive private information of more than 50 users could be retrieved.[19] This information included the visited web-sites, account names, mail addresses and other data potentially enabling the tracking of browser surfing activity, travel plans, illnesses, sexual preferences, drug consumption, and reconstruction of confidential company revenue data of a media house as well as details regarding ongoing police investigations.[18] WOT chose not to comment on the findings when prompted by German media with the results of the investigation prior to the publication of the report.

LALA.

Via http://sebsauvage.net/links/?wn8OPQ .

J'ai zappé de faire tourner cette info. L'implémentation OpenPGP des Yubikeys 4 (les séries précédentes ne sont pas concernées mais gèrent uniquement des clés jusqu'à 2048 bits) est du code privateur bien fermé. :(

Technically it's not running any applet, as the YK4 does not have a JavaCard environment. It's running a proprietary implementation of the OpenPGP card specification. [...]

[...]

The implementation is not open source, that is correct. We have both internal and external review of our code to ensure that it is secure. It's important to remember that open source code is no guarantee that bugs/vulnerabilities will be detected as the bug you've linked to demonstrates quite well. The bug was inherited from the upstream project which ykneo-openpgp is based on, and was NOT detected by any audit of the source code. It was interaction with the device itself which lead to it's discovery.

We're all for open source, and we try to open source as much of our code as possible when and where it makes sense, but in this case it was determined not to be so. One reason is that on the YubiKey NEO, each applet runs in its own sandbox, isolated from the rest of the system and can be audited/reasoned about on its own. This is not the case on the YubiKey 4, where each part of the system interacts with several others. Another reason that ykneo-openpgp was implemented as an open source project (aside from being able to leverage an existing project) was that it was useful for others, as it can run on a variety of devices. Again, this is not the case for the implementation running on the YubiKey 4.

Via https://twitter.com/aeris22 , si ma mémoire est bonne.

Y'a des services qui refusent de démarrer au boot quand on leur demande d'écouter sur une ou plusieurs IPs (v4 ou v6) spécifiques. C'est typiquement le cas d'Unbound, de BIND et d'OpenVPN.

Ces services s'attendent à trouver les IP configurées sur une interface réseau dès leur lancement. Or, même s'ils sont lancés après le réseau par l'init, en IPv6, il y a une vérification automatique que l'IP n'est pas déjà utilisée sur le réseau. Pendant cette vérification, le noyau n'indique pas aux applications qu'une IPv6 est associée à l'interface réseau, ce qui entraîne l'arrêt des services sus-mentionnés.

Le meilleur moyen de résoudre ce problème est de vérifier si le logiciel n'a pas une option pour re-scanner les interfaces réseaux. BIND dispose de interface-interval, NTPd dispose de -U, par exemple.

Si ce n'est pas le cas, il est toujours possible de désactiver la détection d'IPs dupliquées en ajoutant la ligne suivante dans la définition de l'interface réseau dans /etc/network/interfaces :

pre-up /sbin/sysctl -w net.ipv6.conf.$IFACE.accept_dad=0

ÉDIT DU 1/11/2016 À 22h55 : non, « dad-attempts 0 » ne permet pas de résoudre ce problème. FIN DE L'ÉDIT.

Entretien avec Stéphanie Bortzmeyer par Camille Paloque-Berges et Valérie Schafer le 23 avril 2015 dans le cadre du projet WEB90. http://web90.hypotheses.org

Le but du projet de recherche WEB90 est de comprendre et documenter les années 1990 en matière de numérique.

Quelques notes :

• Parcours : études de physiques -> il se retrouve dans un labo avec un nouveau système d'information dont il doit s'occuper -> il trouve l'informatique très amusante -> il laisse tomber son doctorat. Pénurie accrue donc on recrute sans diplôme à l'époque. Il poursuivra ses études au Cnam mais il ne les terminera pas. Il commence sa carrière à l'INED en 1986.
  
  
• Paysage de l'époque : l'INED n'était même pas encore connecté à EARN/Bitnet, réseau orienté éducation/recherche basé sur des technos IBM et qui fournissait des services type messagerie. D'autres réseaux existaient : UUCMP (pour mail, news, transfert de fichiers). L'éducation nationale utilisait Decnet. Beaucoup de réseaux différents dans tous les sens et surtout : rien de standard. À l'époque, il se codait beaucoup de passerelles entre ces réseaux. La première expérience d'Internet pour Stéphane remonte à 1991, quand il entre au CNAM en tant qu'adminsys.
  
  
• Les réseaux "pré-Internet" permettaient déjà de découvrir la coopération, l'auto-régulation, la technique. Tout cela existait avant Internet et UNIX. Il y avait des communautés : communauté UUCP, communauté DECUS, communauté Atari, etc. C'était toute la différence entre IBM et DEC : l'échange pair-à-pair de la doc' et des protips pour le second, référent commercial pour le premier.
  
  

• À l'époque :

  • les services les plus utilisés étaient la messagerie, les news, le transfert de fichier et IRC. Transfert de fichiers = l'époque du FTP anonyme qui ne l'a jamais vraiment était : il était normal, par convention, de filer son adresse de courrier en guise de mot de passe. Cela permettait le debug. Les considérations opérationnelles passaient avant la vie privée.
    
    
  • la majorité des discussions politiques avaient lieu sur Usenet.
    
    
  • les modèles de facturation se cherchaient. Exemple : AFNet (ex-AFU) qui facturait à l'usage en imposant des contraintes techniques. La distinction entre utilisateur et administrateur était plus floue : il fallait bidouiller soi-même.
    
    
  • Le CNAM a été le premier établissement français connecté à Internet. Premier serveur HTTP de France de peu (l'INRIA "suivra" juste après).
    
    
  • À l'époque, on faisait circuler des listes de serveurs FTP avec les IPs. On n'avait pas confiance dans la fiabilité et la pérennité du DNS. :D Au début du web, il y avait aussi un annuaire actualisé de tous les sites web.
    
    
  • La majorité des discussions de l'époque s'apparentait au milieu des radios-amateur : elles étaient destinées à faire fonctionner le système. Il y avait les journées messagerie : réunions des universitaires, qui deviendront plus tard les JRES. Rien qu'à l'intitulé, on sent qu'on était obstiné à faire tomber en marche le service messagerie.
    
    
  • Pour la petite anecdote : c'est dans une journée messagerie que Stéphane suivra son premier cours sur le DNS et n'y comprendra rien. :D À cause d'un mélange de politique et de technique aka on prétend une contrainte technique qui n'en ait pas pour justifier des choix tout à fait politique.
    
    
  • L'expérience utilisateur était rude et faisait dire aux détracteurs d'Internet que "ça ne fonctionnera jamais". Comme si on avait jugé le succès de l'automobile avec les voitures des années 1900 qui avaient des sièges en bois, une manivelle pour l'allumage et qui subissaient l'absence de station services.
    
    
  • Internet était sous le radar des institutions et des médias. Il est apparût nécessaire de convaincre le public. C'est ça, l'objectif des stand informatique à la fête de l'Huma dès 1991/1992 puis des fêtes de l'Internet.
• Citation de Laurent Chemla : toute nouvelle technique de communication a toujours été un succès parce que l'humain est un animal communicant. C'est pour ça qu'il n'y avait pas besoin d'être voyant-e pour prédire le succès d'Internet.
  
  
• Le nommage des machines a un peu changé. À l'époque, l'admin donnait un nom à sa machine car il y avait une relation affective découlant de la rareté. Aujourd'hui, on a xx ordinateurs par foyer donc cette relation n'existe plus vraiment. Dans le monde pro, les noms sont devenus plus utilitaires : les parcs comprennent beaucoup de machines, surtout avec la virtualisation donc le nom est un identifiant qui dit lieu physique + identifiant local ou nommage selon le service que rend la machine. Dans les 90's, le nommage était déjà un sujet d'engueulades : qui distribue, qui peut utiliser tel nom, etc.
  
  
• On ne pensait pas à la vie privée, pas tellement parce qu'osef ou hippies mais plutôt parce qu'on avait assez de problèmes à gérer sans cela : il fallait que le réseau tourne. La fin des années 80 et le début des années 90 marque le déclin de l'informatique partagée.
  
  
• BBS : accès distant, via un modem (en composant donc un numéro de téléphone) à un ordinateur qui donnait accès à messagerie, téléchargement, forums, etc.
  
  
• Service d'accès à distance du CNAM : service mis en place par Stéphane qui permettait d'accéder au net via le CNAM. 10 modems posés sur une étagère en bois. Les étudiants en ont peu profité car ils n'avaient pas forcément d'ordinateurs à la maison et qu'il fallait un modem "agréé" car les autorités françaises avaient décrétées que les modems étrangers, c'était le danger. Sauf que c'était du protectionnisme bidon qui justifiait de vendre les modems agréés 10 fois plus cher. Des modems étaient ramenés en douce lors de voyages aux US. En revanche, le service avait beaucoup plu en dehors du CNAM et la majorité des comptes créés l'ont été pour des externes genre des personnes du monde UUCP/BBSSS qui voulaient se connecter à Internet. Cela à contribuer à diffuser Internet et ses usages en France.
  
  
• Le site web de Nicolas Pioche, nommé "le Louvre" puis "web louvre" puis "web museum" suite à des fights avec le Louvre, qui proposaient des photos de tableaux a été important car cela a montré que le web pouvait être utilisé pour des sujets d'intérêt général et pas uniquement pour transmettre de la doc'.
  
  
• Fallait-il créer des associations spécifiques ? Les droits et libertés humaines, le droit de la consommation, c'est générique. D'un autre côté, des gens comme Barlow prétendaient qu'Internet est un nouveau monde totalement différent. Ce qui a justifié les assos, c'est que les structures existantes (partis politiques, par exemple) n'en avaient rien à faire d'Internet, il fallait donc que les informaticiens de l'époque fassent eux-même. Exemple de combat : l'Internet Society (ISOC) en partie montée pour faire tomber les marques « Internet » illégitimes (oui, des sociétés commerciales avaient vraiment déposé la marque « Internet » :- ).
  
  
• Assos : AUI pour les utilisateurs. AFU (AFNet) très corporate avec de claires visées économiques. ISOC France, "filiale" (de fait) de l'ISOC sans réel succès puisque l'ISOC impose des contraintes strictes pour monter des relais locaux.
  
  
• Premiers problèmes : racisme trash sur tous les groupes francophones sur Usenet, affaire Altern/Estelle Halliday, vente d'objets nazis aux enchères sur Yahoo (https://fr.wikipedia.org/wiki/LICRA_contre_Yahoo!).
  
  
• AOL, Infonie, Calvacom, etc. posaient déjà la question d'un Internet ouvert versus des réseaux fermés qui se vantaient d'être contrôlés, vérifiés, "on sait ce qu'il y a dessus", etc. C'était un argument marketing. L'histoire a tranché. :)
  
  
• Toute organisation humaine tend à créer de la politique (au sens noble) quand elle passe d'un petit groupe homogène (techniciens fan de science-fiction) à un groupe hétérogène plus vaste.
  
  
• Particularités française :
  • Fin du réseau Cyclades en 1979, tué par les X-Mines qui expliquaient que le datagramme, ce n'est pas sérieux alors que ce réseau était au même niveau technique qu'ARPAnet. Cela a conduit à une cécité française, y compris dans les formations : aux USA, les formations étudiaient plusieurs réseaux alors qu'en France, on étudiait une forme de réseaux sans avenir. Le Minitel a eu un impact négatif car on a eu un égo surdimensionné : "le monde entier nous envie" qui conduit à un repli sur soi ("pas la peine d'aller voir ce que font les autres et comment car on est trop géniaux". Mais le Minitel a aussi permis à Niel de se faire du blé pour ensuite aller proposer autre chose dans le secteur fermé des télécoms. Exemple de cécité : en 1993, RENATER 1 était connecté à Internet mais il ne fallait pas le dire. Il ne fallait pas dire TCP/IP. Et il a fallu déployer X.25 (et forcément, déployer deux protocoles de si bas niveau, ça coûte).
    
    
  • Attendre que le chef tranche. En ce sens, le discours de Jospin à Hourtin en 1997 et le plan gouvernemental en 1998 ont été importants car ils ont donné des ordres aux personnes qui en attendaient.

Comme Youtube et les vidéos coupées, c'est le mal, je mets à disposition une version complète et dans un format libre (webm / VP8 / Vorbis) : http://www.guiguishow.info/wp-content/uploads/videos/Web90-Stephane_Bortzmeyer-15-04-2015.webm

L’accord validé le 12 juillet 2016 par la Commission européenne vient remplacer un précédent document datant de 2000. La Cour de justice de l’Union européenne avait alors sanctionné sur l’autel de la vie privée ce Safe Harbor, qui permettait jusqu’à présent aux entreprises installées outre-Atlantique d’importer les données des internautes européens. Les révélations Snowden et la mainmise de la NSA sur ce flux et ce stock ont poussé la CJUE à considérer que les États-Unis étaient tout sauf un port sûr, de niveau équivalent un État membre européen.

Et pour la Quadrature, FDN et FFDN le même reproche peut être adressé à l’accord de Privacy Shield.

[...]

De la même manière, l’accord négligerait de limiter l’exploitation des données au strict nécessaire de l’ingérence dans la vie privée. L’utilisation de ce vivier sera limitée à six motifs. Il y a certes l’espionnage, le terrorisme, les armes de destruction massive, mais également « les menaces pour la cybersécurité ». Pour les trois organisations, on serait bien loin des exigences de la CJUE, à savoir « des fins précises, strictement restreintes et susceptibles de justifier l’ingérence ».

Le mécanisme en outre violerait le droit au recours effectif pourtant exigé par la Cour de Luxembourg, en ne prévoyant pas des règles aussi protectrices que celles en vigueur de ce côté de l’Atlantique.

Enfin, les requérants se souviennent de l’arrêt Digital Right Ireland. En avril 2014, la CJUE avait épinglé la directive sur la conservation des données parce que justement elle avait oublié d’imposer l’intervention d’une autorité indépendante pour limiter l’accès à ces précieuses informations.

[...]

Le front des trois structures n’est pas le seul ouvert contre le Privacy Shield. Digital Right Ireland a également attaqué ce document afin de solliciter son annulation.

À suivre. :)