GuiGui's Show

Avant Internet et sa réalité physique, le télégraphe.

« A l’époque, on ne parlait pas d’Internet, ni même de téléphone, mais simplement de télégrammes. Il n’empêche: même s’ils ne pouvaient transmettre qu’une dizaine de mots par minute pour la bagatelle de 100 dollars (soit 1.380 dollars d'aujourd'hui, un peu plus de 1.100 euros!), les premiers tubes sous-marins ont violemment rétréci la planète. Une lettre-type de 300 mots, qui mettait dix jours de traversée pour rallier l’autre bord de l’océan, était désormais télégraphée en 30 minutes. Personne ne le savait encore, mais ce raccourci sous-marin allait nous faire changer de paradigme. »

Via http://seenthis.net/messages/313270

« Another subtlety is that when you buy transit wholesale you typically only pay for traffic coming in (“ingress") or traffic going out (“egress”) of your network, not both. Generally you pay which ever one is greater.

CloudFlare is a caching proxy so egress (out) typically exceeds ingress (in), usually by around 4-5x. Our bandwidth bill is therefore calculated on egress so we don't pay for ingress. This is part of the reason we don't charge extra when a site on our network comes under a DDoS attack. An attack increases our ingress but, unless the attack is very large, our ingress traffic will still not exceed egress, and therefore doesn’t increase our bandwidth bill.

[...]

In CloudFlare's case, unlike Netflix, at this time, all our peering is currently "settlement free," meaning we don't pay for it. Therefore, the more we peer the less we pay for bandwidth. Peering also typically increases performance by cutting out intermediaries that may add latency. In general, peering is a good thing.

[...]

While transit is priced similarly to North America, in Europe there is a significantly higher rate of peering. CloudFlare peers 50-55% of traffic in the region, making the effective bandwidth price $5/Mbps. Because of the high rate of peering and the low transit costs, Europe is the least expensive region in the world for bandwidth.

[...]

In Europe, and most other regions outside North America, these and other exchanges are generally run as non-profit collectives set up to benefit their member networks. In North America, while there are Internet exchanges, they are typically run by for-profit companies. The largest of these for-profit exchanges in North America are run by Equinix, a data center company, which uses exchanges in its facilities to increase the value of locating equipment there. Since they are run with a profit motive, pricing to join North American exchanges is typically higher than exchanges in the rest of the world.  

[...]

In North America the combination of relatively cheap transit, and relatively expensive exchanges lowers the value of joining an exchange. With less networks joining exchanges, there are fewer opportunities for networks to easily peer. The corollary is that in Europe transit is also cheap but peering is very easy, making the effective price of bandwidth in the region the lowest in the world.

[...]

Compared with the benchmark of $10/Mbps in North America and Europe, Asia's transit pricing is approximately 7x as expensive ($70/Mbps, based on the benchmark).
There are three primary reasons transit is so much more expensive in Asia. First, there is less competition, and a greater number of large monopoly providers. Second, the market for Internet services is less mature. And finally, if you look at a map of Asia you’ll see a lot of one thing: water. Running undersea cabling is more expensive than running fiber optic cable across land so transit pricing offsets the cost of the infrastructure to move bytes.

[...]

To peer traffic in Latin America you need to either be in a "carrier neutral" data center — which means multiple network operators come together in a single building where they can directly plug into each other's routers — or you need to be able to reach an Internet exchange. We've also worked out special arrangements with ISPs in Latin America to set up facilities directly in their data centers and peer with their networks, which is what we did in Medellín, Colombia.

[...]

Australia is the most expensive region in which we operate, but for an interesting reason. We peer with virtually every ISP in the region except one: Telstra. Telstra, which controls approximately 50% of the market, and was traditionally the monopoly telecom provider, charges some of the highest transit pricing in the world — 20x the benchmark ($200/Mbps). Given that we are able to peer approximately half of our traffic, the effective bandwidth benchmark price is $100/Mbps.

To give you some sense of how out-of-whack Australia is, at CloudFlare we pay about as much every month for bandwidth to serve all of Europe as we do to for Australia. That’s in spite of the fact that approximately 33x the number of people live in Europe (750 million) versus Australia (22 million).

If Australians wonder why Internet and many other services are more expensive in their country than anywhere else in the world they need only look to Telstra. What's interesting is that Telstra maintains their high pricing even if only delivering traffic inside the country. Given that Australia is one large land mass with relatively concentrated population centers, it's difficult to justify the pricing based on anything other than Telstra's market power.

[...]

While we peer nearly 40% of traffic globally, we only peer around 20-25% in North America.  
Like in Europe, CloudFlare peers 50-55% of traffic in Asia. However, transit pricing is significantly more expensive.
While today our peering ratio in Latin America is the best of anywhere in the world at approximately 60 percent, the region's transit pricing is 8x ($80/Mbps) the benchmark of North America and Europe. That means the effective bandwidth pricing in the region is $32/Mbps, or approximately the same as Asia. »

Via http://seenthis.net/messages/308083

L'idée (et l'envie) d'installer Debian GNU/Linux sur mon ordinateur de poche Motorola Moto G 4G LTE rooté vient de Johndescs (http://jonathan.michalon.eu/).


Pourquoi installer Debian GNU/Linux sur son ordinateur de poche ?
  - Parce qu'on peut le faire \o/
  - Parce que c'est plutôt fun
  - Pour avoir un vrai GNU/Linux bien foutu (respect complet de Filesystem Hierarchy Standard (FHS), sysvinit, ...)
  - Pour avoir des outils qui fonctionnent. Non parce que l'implémentation Busybox des outils standards, c'est pas toujours ça. Exemple : la commande whois qui contacte http://whois-server.net/ - 193.46.236.105 dont le démon whois est dans les choux au lieu de contacter les serveurs whois kivontbien/kisontlegit (ceux de l'AFNIC pour un domaine fr. par exemple).


On va faire cette installation (et usage au quotidien) avec Debian-kit qui est un script qui mâche le travail. Notons qu'il ne s'agit pas d'un chroot : « Debian Kit utilise une approche différente : il monte (bind) [ndlr : et merge] les répertoires classiques de Debian directement sur la racine Android [ndlr : à partir d'une image disque ou d'une partition dédiée qui contient le système de fichiers Debian], ce qui permet aux deux systèmes de communiquer sans aucun souci vu qu'ils se partagent le même filesystem. ». On a donc accès à l'intégralité des montages Android depuis Debian. \o/ Notons tout de même que cette cohabitation provoque quelques blocages. Exemple : sur mon ordinateur de poche, je ne peux plus activer/désactiver le WiFi une fois Debian lancé.


Je vais compléter le tutoriel pointé par ce shaarli avec mes conseils et les problèmes que j'ai rencontrés. Ce shaarli est donc complémentaire, il ne se substitue pas au tutoriel qu'il faudra donc lire et suivre en grande partie.


Mon premier conseil sera de mettre votre ordinateur de poche en mode avion afin de ne pas être dérangé par un appel téléphonique pendant que vous taperez les commandes nécessaires à l'installation de Debian. Non, ce n'est pas du vécu mais j'ai pensé ensuite que j'ai eu de la chance car ça m'aurait bien troublé et gonflé vu le debug à faire (retaper/relancer les commandes plusieurs fois sur un clavier minuscule).


Le script d'installation a changé d'URL : http://www.wdowiak.me/debian-kit/ et http://www.wdowiak.me/debian-kit/debian-kit-1-6.shar pour le lien direct.


La première erreur que j'ai rencontrée est intervenue durant la phase « Unpack to /data/local/deb » : « Included busybox failed. ». Juste avant cela, un chmod ne fonctionne pas (on voit l'aide s'afficher). Le tar (compris dans le « .shar ») est néanmoins extrait mais d'autres erreurs arrivent en cascade par la suite lors de la vérification des sommes de contrôle des fichiers extraits.

En lisant le script « .shar », on voit qu'un chmod a lieu sur un Busybox local (extrait dans /data/local/deb/ par le script quoi) pour le rendre exécutable : « chmod 755 ${DEST}/armel/busybox ${DEST}/i386/busybox ». Sans droit d'exécution, l'appel à ce Busybox local échoue (« BUSYBOX=$( ${DEST}/i386/busybox ash -c "echo ${DEST}/i386/busybox" 2>&- || ${DEST}/armel/busybox ash -c "echo ${DEST}/armel/busybox" 2>&-) ») d'où l'erreur non-bloquante « Included busybox failed. » et la variable $BUSYBOX qui n'est pas remplie (elle reste vide). C'est donc les implémentations ash/sed/tar du Busybox global (que j'ai installé moi-même suite au rootage de mon ordinateur de poche) qui sont exécutées dans la suite du script (exemple : « ${BUSYBOX} sed -e '1,/^### TAR ARCHIVE STARTS ###/d' ${0} | ${BUSYBOX} tar -C ${DEST} -xvz ») ... sauf que je n'ai pas la commande md5sum dans mon Busybox global, ce qui explique l'erreur "en cascade" constatée. Cette erreur étant bloquante (« || exit 1 »), ça explique l'arrêt de l'installation à cette étape.

Le chmod échoue car l'implémentation que j'en ai ne supporte pas le passage de plusieurs fichiers en paramètre. Il faut donc réaliser ce chmod sur les deux fichiers en deux temps. Pour cela, on modifie le script sur notre desktop :
$ sed -i 's%chmod 755 ${DEST}/armel/busybox ${DEST}/i386/busybox%chmod 755 ${DEST}/armel/busybox ; chmod 755 ${DEST}/i386/busybox%' debian-kit-1-6.shar
Puis on met le script sur la carte SD de l'ordinateur de poche (ou autre méthode de transfert genre USB+MTP, ça marchera tout aussi bien).

Sur mon ordinateur de poche, le script se trouve sur la carte SD donc dans /storage/sdcard1. /storage/sdcard0 et /sdcard sont des liens symboliques vers /storage/emulated/legacy qui est juste une partie de la mémoire interne de mon ordinateur de poche et surtout pas la carte SD. Donc pour lancer l'installation, j'utilise la commande :
# sh /storage/sdcard1/debian-kit-1-6.shar


Cette fois-ci le chmod, l'extraction du tar et la vérification des sommes de contrôle se font sans problèmes. Mais le script (/data/local/deb/autorun cette fois-ci) m'indique qu'il va créer l'image disque de mon Debian dans /storage/emulated/legacy/debian.img ... Comme expliqué ci-dessus, cet emplacement se situe dans la mémoire interne de mon ordinateur de poche alors que je veux mettre l'image Debian sur ma carte SD ! Le script indique néanmoins que si je veux forcer un autre emplacement, je peux lancer le script /data/local/deb/mk-debian manuellement.

Faisons ça. Ctrl-c pour quitter le script actuel. La commande « sh /data/local/deb/mk-debian -h » permet d'avoir les options qui nous seront utiles (quel système on veut installer ? Quelle taille d'image ? Quel emplacement pour l'image ?). Au final, la commande qui correspond à mes désirs est la suivante :
# sh /data/local/deb/mk-debian -i /storage/sdcard1/debian-wheezy.img -d wheezy -s 1024

Attention ! Si vous utilisez Netfilter et un frontend pour le configurer comme Afwall+ par exemple, il faudra autoriser temporairement « (root) - Applications qui fonctionnent en tant que root » sinon debootstrap ne pourra pas se connecter à un miroir Debian et échouera. Si ça vous arrive : supprimez l'image disque (/storage/sdcard1/debian-wheezy.img dans mon cas) et recommencez l'appel à mk-debian.


L'erreur suivante est survenue lors de l'installation de andromize (« andromize va bricoler un peu l'installation Debian de base pour la rendre compatible avec Android en parallèle. Ça va aussi installer un démon qui change automatiquement les paramètres réseau de Debian en fonction de ce que vous faites sur Android (androresolvd). ») : « groupadd: failure while writing changes to /etc/group ».

Heureusement, on trouve de la documentation sur les interwebz : https://unix.stackexchange.com/questions/145553/groupadd-failure-while-writing-changes-to-etc-group et https://android.stackexchange.com/questions/54577/how-can-i-change-selinux-from-enforcing-to-permissive-on-samsung-galaxy-note-3 . En effet, mon ordinateur de poche a été fourni avec Android 4.4.3 donc KitKat donc SELinux.

On quitte le shell "Debian", on désactive temporairement SELinux (il sera réactivé au prochain reboot de l'ordinateur de poche mais ça ne sera pas bloquant), on retourne dans le shell "Debian" et on relance l'installation d'andromize :
# exit
# setenforce 0 ; deb
# apt-get install andromize


On peut ensuite continuer la préparation du minimum pour avoir un shell via SSH (plus pratique pour la saisie, sans avoir besoin d'une "application" tierce pour faire office de sshd comme SSHDroid) :
# apt-get install andromize openssh-server sudo
# adduser guigui
# usermod -aG sudo guigui
# exit
# deb u ; deb s


L'accès via SSH se fait de manière classique avec le compte que nous venons de créer puis sudo pour passer root.


On peut utiliser un autre miroir Debian que ftp.us.debian.org, plus local toussa. Ça se passe dans /etc/apt/sources.list.d/sources.list. Ne pas oublier le apt-get update habituel.


On installe quelques packages en plus (oui, sl, cowsay, funny-manpages et fortunes-fr c'est juste pour le fun et pour faire style ; most c'est pour avoir les pages de manuel en couleur ; lsb-release c'est pour la commande lsb_release -a pour montrer facilement que c'bien du Debian toussa) :
# apt-get install telnet netcat whois mtr-tiny tcpdump bwm-ng curl most htop sipcalc vim lsb-release sl cowsay funny-manpages fortunes-fr

Pour utiliser most : export PAGER=most dans vos .bashrc (/root/ et /home/<votrelogin>/). Pour que sl/cowsay/fortunes soient disponibles avec le compte root (pour ne pas être obligé de faire su <votelogin> sur votre ordinateur de poche pour juste une petite démo) : export PATH=$PATH:/usr/games/ dans /root/.bashrc

ÉDIT du 18/11/2014 à 20h50 : problème curieux avec fortune :
  Depuis mon ordinateur de poche, en root :
    fortune: /usr/share/games/fortunes: No fortune files in directory.
    fortune:/usr/share/games/fortunes not a fortune file or directory
    No fortunes found

  Depuis mon desktop, en SSH sur mon ordinateur de poche, en root : ça fonctionne.

  Depuis mon ordinateur de poche ou via SSH, en utilisateur normal : ça fonctionne.

Réponse : depuis l'ordinateur de poche, le shell (/bin/bash) est instancé par debian-kit (env affiche « SHELL=/tmp-mksh/tmp-mksh »). Ce dernier ne lit pas le fichier /etc/default/locale. $LANG est donc vide. Comme j'ai installé uniquement fortunes-fr, fortunes ne trouve aucune fortune dans /usr/share/games/fortunes car elles sont rangées dans /usr/share/games/fortunes/fr. Ça marche via SSH ou après avoir su <votrelogin> depuis votre ordinateur de poche car PAM est exécuté et il source /etc/default/locale. La solution est donc de sourcer /etc/default/locale dans /root/.bashrc . FIN DE L'ÉDIT.


On modifie /etc/hosts pour ajouter l'association entre le hostname défini plus haut et ::1 / 127.0.0.1


Et on a fini (pour l'instant) \o/


J'ai encore une erreur lors de chaque lancement du Debian : « Cannot access system properties via ANDROID_PROPERTY_WORKSPACE environment setting ». Je ne sais pas encore quelle en est l'origine mais elle n'est pas bloquante.


Rappel des commandes utiles :
  deb tout seul pour démarrer Debian et obtenir un shell Debian.
  deb s pour démarrer Debian et le serveur SSH (parce qu'il faut bien avouer que pour configurer Debian plus avant, ça va être plus sympa de le faire depuis votre PC).
  deb S pour arrêter le serveur SSH (mais pas Debian). Notez la différence de casse du S.
  deb u pour arrêter Debian complètement. Si problème (des process qu'il n'arrive pas à éteindre) faites deb k pour tout tuer et arrêter Debian.

Mouais, c'est plutôt décevant comme explication/présentation de la neutralité des réseaux :
  - cette vidéo traite exclusivement des sites web alors que la neutralité des réseaux englobe tous les usages, toutes les applications, tous les contenus, tous les protocoles. Bref, Internet dans sa globalité et son universalité, justement.
  - cette vidéo traite uniquement de facturation différenciée des fournisseurs de services par les opérateurs réseaux (dont les FAI) et très brièvement de censure (sans préciser si elle est de droit privée donc totalement inacceptable ou issue d'une décision judiciaire dans le cadre d'un procès équitable donc bénéficiant déjà d'une légitimité relative). Quid des libertés fondamentales (expression, information, libre entreprise, libre concurrence) ? Quid de la surveillance ? Quid de l'altération de contenus ? Quid du bridage ? Quid de l'innovation ? C'est aussi tout cela la neutralité des réseaux.

Après si, tout comme la vidéo de John Oliver (http://www.slate.fr/economie/87935/neutralite-net-chiant-video-john-oliver) ça peut servir à éveiller des prises de conscience et constituer une toute première approche des problématiques sous-jacentes à la neutralité des réseaux, pourquoi pas mais je suis dubitatif.

« J’ai récemment déménagé à Lausanne, en Suisse. Le coût de l’accès à Internet est plus élevé qu’en France. Alors que Free propose un accès FTTH à 1 Gbps1 pour environ 38 € (TV et téléphone inclus), Swisscom fournit le même service pour environ 200 €2. Mon appartement est éligible à l’offre fibre de Swisscom. J’ai opté pour le forfait de 40 Mbps sans ligne téléphonique pour environ 80 €.

[...]

Je ne décris ici que les éléments spécifiques à Swisscom (ainsi que la QoS).

[...]

Le boîtier Internet est fourni avec un SFP 1000BX de marque Siligence [

Il y a deux références sur le SFP : SGA 441SFP0-1Gb et OST-1000BX-S34-10DI. La transmission se fait sur la longueur d’onde 1310 nm et la réception sur 1490 nm.]. La réception et la transmission se font sur la même fibre en utilisant des longueurs d’onde différentes pour chaque direction.

Plutôt que d’investir dans une carte avec un port SFP, j’ai opté pour un switch Netgear GS110TP qui dispose de 8 ports cuivres et de 2 ports SFP. C’est un switch assez économique disposant de pas mal de fonctionnalités intéressantes comme les VLAN et LLDP.

[...]

La connectivité IPv4 est fournie sur le VLAN 10. Un client DHCP est obligatoire pour l’obtenir. Il est nécessaire de publier l’option DHCP « vendor class identifier » (option 60) lors de la demande de bail.

[...]

Swisscom fournit IPv6 à travers le protocole 6rd. Cela fait partie des mécanismes pour faciliter la migration vers IPv6 sans changer le cœur de réseau. Un tunnel est mis en place au-dessus d’IPv4. [...] Pour configurer IPv6, il faut obtenir le préfixe à utiliser et l’IP de la passerelle 6rd. Certains FAI fournissent ces valeurs dans la réponse DHCP (option 212) mais ce n’est pas le cas de Swisscom. La passerelle est 6rd.swisscom.com et le préfixe est 2a02:1200::/28. Après avoir ajouté l’adresse IPv4 au préfixe, il reste 4 bits pour créer des sous-réseaux internes.

Swisscom ne fournit pas d’IPv4 fixe. On ne peut donc pas construire à l’avance son préfixe IPv6. Le script suivant, à placer dans /etc/dhcp/dhclient-exit-hooks.d/6rd, met en place le tunnel

[...]

Swisscom utilise le même MTU pour tous les clients. Certains sont en PPPoE et donc le MTU à l’intérieur du tunnel est de 1472 et non de 1480.

[...]

Il y a très très longtemps, la mise en place d’une QoS efficace était plutôt compliquée. Le script Wonder Shaper était souvent utilisé pour obtenir une configuration honnête. Aujourd’hui, grâce au travail du projet Bufferbloat, il y a deux étapes très simples pour obtenir quelque chose de raisonnable

[...]

Réduire la taille de la queue de transmission des périphériques réseau. Une valeur de 32 paquets aide TCP à détecter rapidement les problèmes de congestion sans brider un lien gigabit.

[...]

Utiliser fq_codel comme qdisc par défaut. [...] fq_codel est un algorithme combinant une gestion équitable des flux et la minimisation des latences. Une gestion équitable des flux signifie que tous les flux sont égaux quant à leur possibilité d’émettre des paquets. Autrement dit, un flux au débit très élevé ne monopolisera pas la carte réseau. Minimiser les latences s’obtient en s’assurant que la taille de la queue de transmission est limitée en supprimant des paquets d’autant plus agressivement que la latence augmente. »

« Je comprenais mal Git, m’emmêlais dans les notions de branches, de fork et de commit. J’ai demandé des explications à Julien. J’ai mis ça en images et avec mes mots. Je vous le partage (CC by SA), des fois que ça vous serve aussi. »

http://nissone.com/GitPourLaNulle/GitPourLaNulle.pdf

Via http://seenthis.net/messages/310469#message310946

« conntrack provides a full featured userspace interface to the netfilter connection  tracking  system  that  is  intended  to  replace  the  old /proc/net/ip_conntrack  interface.  This  tool  can  be used to search, list, inspect and maintain the connection  tracking  subsystem  of  the Linux  kernel.   Using  conntrack  ,  you  can dump a list of all (or a filtered  selection of) currently tracked connections, delete connections from the state table, and even add new ones.

[...]

TABLES

       The connection tracking subsystem maintains two internal tables:

       conntrack:
              This is the default table.  It contains a list of all  currently
              tracked  connections  through  the  system.   If  you  don’t use
              connection tracking exemptions (NOTRACK iptables  target),  this
              means all connections that go through the system.

       expect:
              This   is   the  table  of  expectations.   Connection  tracking
              expectations  are  the  mechanism  used  to   "expect"   RELATED
              connections  to  existing ones.  Expectations are generally used
              by "connection tracking helpers" (sometimes  called  application
              level  gateways  [ALGs]) for more complex protocols such as FTP,
              SIP, H.323.

[...]

       -L --dump
              List connection tacking or expectation table

       -C, --count
              Show the table counter.

       -S, --stats
              Show the in-kernel connection tracking system statistics. »

Pour les états NAT :
«       -n, --src-nat
              Filter source NAT connections.

       -g, --dst-nat
              Filter destination NAT connections.

       -j, --any-nat
              Filter any NAT connections. »

L'erreur « Can't open /proc/sys/net/netfilter/nf_conntrack_count » signifie que le module « nf_conntrack » n'est pas chargé, probablement car vous n'avez aucune règle netfilter qui utilise les états/le suivi des connexions.

Ces messages indiquent que c'est le bordel du côté de la pile OpenGL qui ne sait pas sur quelles libs se positionner. Cela arrive lorsque plusieurs drivers (nvidia, mesa par exemple) sont installés, notamment dans des configs bi-GPU comme Optimus.

Pour voir et définir quelles libs (de quel driver donc) seront utilisées par la pile OpenGL : update-alternatives --display|--config glx

De très bonnes remarques :

« il affirme que les gros silos comme Google sont incontournables. Mais ce n'est pas vrai. Autant le FAI est un intermédiaire obligé (à part les projets très expérimentaux et très limités de réseaux « mesh »), autant l'usage de Gmail n'est pas obligatoire. On peut envoyer et recevoir du courrier sans Gmail, on peut louer des machines virtuelles ailleurs que sur Amazon, on peut stocker et distribuer des fichiers sans Dropbox. Cela fait une énorme différence entre les FAI et les gros silos : s'il est légitime de protéger la neutralité de l'Internet contre les abus des intermédiaires, rien ne dit que cela doive forcément être le cas pour des « plateformes » qu'on n'est pas obligés d'utiliser. »
-> monopole de fait (FAI) versus monopole consenti.

« Ce n'est peut-être pas un passage obligé, mais c'est un quasi-monopole et la régulation s'impose donc. Mais le problème avec cette attitude est qu'elle est de résignation. Je suis d'accord que la place excessive prise par les GAFA dans les services sur l'Internet est dangereuse : ces silos stockent des données personnelles sans vergogne, savent tout de vous (alors que vous ne savez rien d'eux), et transmettent les informations à la NSA (programme PRISM, entre autres).

[...]

Mais la solution est-elle d'imposer à ces silos des règles protégeant (sans doute fort mal) leurs victimes ? On entrera alors dans une logique dangereuse, où on laisse ces entreprises vous exploiter, en mettant simplement quelques garde-fous (l'expression, révélatrice, est du CNN : « Il est donc crucial de développer des garde-fous adaptés aux dynamiques de plateformes afin de protéger les usagers et l’innovation lorsque le passage d’une logique ouverte à une logique fermée se produit »). Pour reprendre les termes de Bruce Schneier, les silos sont des seigneurs féodaux : on obtient d'eux quelques services et, en échange, ils sont vos maîtres. Faut-il limiter les excès des seigneurs, leur imposer des garde-fous ? Ou bien faut-il plutôt passer à un régime post-féodal ? »

« Mais il y a aussi des raisons politiques : le pair-à-pair a été activement persécuté et diabolisé, sur ordre de l'industrie du divertissement, jetant ainsi des millions d'utilisateurs dans les bras des silos centralisés. Et puis, les ministres aiment bien râler contre Google mais, au fond, ils sont très contents de sa domination. Ils sont bien plus à l'aise avec quelques grosses entreprises privées qu'avec des millions d'internautes libres. »

RIen de neuf sur DNSSEC ... Parcours des zones avec NSEC, augmentation du facteur d'amplification dans les attaques par réflexion (la sécurité n'est jamais sans coût), la gestion des clés cryptographiques n'est jamais triviale.

Je suis contre l'idée que des enregistrements DNS soient privés. C'est un non-sens. Pour "cacher" des sous-domaines qui permettent d'accéder à des zones privées de votre infra, il existe le mécanisme des vues ! Quand l'article parle de NSEC3, ils nous disent que NSEC3 offre la confidentialité tant que les noms sont difficiles à deviner (attaques par dico). Donc si ces noms sont faciles à trouver (mail., www., private., ...) c'est sûrement que NSEC3 n'a aucun intérêt, non ? ;) Ces noms seront quand même tentés par l'attaquant indépendamment de savoir si DNSSEC est déployé et donc indépendamment de savoir si c'est NSEC ou NSEC3 qui est utilisé.

« DNSSEC also works over UDP » C'est un non-sens d'écrire ça puisque DNSSEC ne sont que des extensions cryptographiques apportées au DNS. Ça ne casse pas le protocole, ça ne remet pas en cause les notions de base, ...

La conclusion de ce publi-reportage est croustillante : « CloudFlare is aware of the complexity introduced by DNSSEC with respect to zone privacy, key management, and reflection/amplification risk. With smart engineering decisions, and operational controls in place, the dangers of DNSSEC can be prevented. » -> tkt gros, on gère :D

Via http://shaarli.cafai.fr/?YtYkAw