Stéphane Bortzmeyer a écrit 645 commentaires

L'Atlas ne fait pas de mesures de capacité (pour éviter de consommer des ressources réseau chez son hébergeur).

Le gros problème de Grenouille, c'est le fait qu'on teste surtout le PC sur lequel il tourne : un gros travail, un virus (je sais, pas sur Linux…) et les mesures sont moins bonnes. Pour mesurer le réseau, il faut des sondes matérielles dédiées (Atlas, SamKnows, Bismark, etc).

Il faudrait voir cela avec le RIPE car c'est tout à fait anormal. L'Atlas ne fait pas de tests de capacité (contrairement à la SamKnows) et consomme donc très peu. Aucun autre hébergeur d'Atlas n'a signalé cela.

Non, on ne faisait pas autrement dans les années 90. On ne faisait rien. Les FAI/hébergeurs/etc ne mesuraient pas depuis l'extérieur, ou alors seulement depuis deux ou trois points installés chez des concurrents ou copains.

Depuis que les boîtes sérieuses mesurent leur réseau avec des trucs comme les Atlas (5 000 points de mesure dans le monde, c'est énorme, aucun service commercial n'a l'équivalent), on s'est aperçu qu'on était rarement bien joignable depuis 100 % de la planète. L'Internet est de plus en plus fragmenté.

Donc, oui, les mesures des sondes Atlas sont réellement utilisées. L'un des cas où cela m'avait été le plus utile, dans mon métier, avait été en testant la connectivité depuis le monde entier, de découvrir un routeur défaillant à AMS-IX qui perdait quelques paquets (cela ne se voyait pas depuis la France, car ce routeur n'était jamais sur notre chemin). Les Atlas ont servi pour l'affaire du réseau 128 sur les Juniper http://www.bortzmeyer.org/reseau-128.html pour regarder la répartition des clients d'un serveur DNS racine https://labs.ripe.net/Members/stephane_bortzmeyer/the-many-instances-of-the-l-root-name-server pour étudier les bavures de la censure chinoise sur le TLD allemand https://labs.ripe.net/Members/pk/denic-case-study-using-ripe-atlas etc.

En effet, l'explicaton de XMPP est confuse et, je soupçonne, fausse. XMPP est un système fédéré (comme le courrier) et donc (heureusement !) il n'y a pas besoin d'un compte sur le système destination.

Damned, j'avais donc cafouillationné par négligence excessive et paresse ? Merci au chaton pour la correction.

Le CVE a été publié bien après l'alerte.

Si, c'est bien CloudFLare qui a publié trop tôt sur la bogue, avant que tout le monde ne soit prêt https://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities

Il n'y a rien de Bitcoin dans Bitmessage. Pas le code, mais aucune idée non plus (personne n'a jamais pu me citer un concept de Bitcoin qu'on retrouve dans Bitmessage). Donc, se réclamer de Bitcoin (qui est très connu et très populaire), ce n'est pas honnête.

On peut en effet toujours redéfinir le vocabulaire comme on veut et appeler centralisé ce qui ne l'est pas. C'est comme si Microsoft décidait tout à coup que Windows est du logiciel libre, en argumentant qu'on peut lancer Word ou IE, au choix, on est libre.

N'avoir qu'une adresse IP en ayant deux connexions (ce qui, au passage, aurait des conséquences pas forcément agréables pour la vie privée) est l'idée de séparation de l'identificateur et du localisateur. Vieux projet, mis en œuvre dans des techniques comme ILNP, HIP ou LISP, mais qui n'a rien à voir avec le caractère centralisé ou pas.

.dns, c'est les gens d'okTurtles.

Non, aucun rapport.

Hmmmm, ce commentaire utilise un vocabulaire très approximatif. D'abord, les adresses IP : leur distribution n'est pas centralisée (je viens d'allouer 2a01:e35:8bd9:8bb0::bad:dcaf tout seul sans demander à personne). Elle est arborescente, ce qui n'a pas du tout les mêmes conséquences. Ensuite, le routage, lui, non seulement n'est pas centralisé mais il n'est même pas arborescent. La phrase « la manière dont les table [sic] de routage sont établie [sic] » est donc incompréhensible.

Quant au DNS, lui aussi est arborescent et non centralisé (Benoit peut créer foobar.linuxfr.org comme il veut sans rien demander à personne).

Quant à « essaye de promouvoir namecoin pour le DNS », cela n'a pas non plus de sens puisqu'il s'agit de deux protocoles différents. C'est comme écrire « essaye de promouvoir Linux pour Windows ».

Je précise ces points car je pense qu'une des raisons du peu de succès des techniques « alternatives » est justement le manque de rigueur technique de leurs promoteurs.

Non, contrairement à ce qui est écrit dans le journal, les deux systèmes n'ont aucun rapport. Certains promoteurs de BitMessage ont juste malhonnètement tenté de profiter de la notoriété de Bitcoin.

Non, je le répète, "fr" est une zone DNS comme les autres.

S'il y a des problèmes précis de configuration de DNS, faut les indiquer (avec les messages d'erreur de Zonecheck ou d'un autre outil de test), ici ou sur la liste dns-fr. « Ça marche pas » n'est pas un message utile.

Le test avec Zonecheck n'est plus obligatoire depuis (sauf erreur) un an et demi.

Non, c'est tout à fait faux. Le TLD "fr" est un TLD comme un autre et n'a rien de particulier.

Quant aux affirmations comme quoi le registre de "fr" aurait la main sur votre config… c'est du délire, tout simplement.

djbdns est à fuir absolument. Logiciel non maintenu et à qui il manque la plupart des fonctions utiles (DNSSEC, IPv6, etc).

Euh, je veux bien, mais cela n'a aucun rapport avec le journal, qui parlait de TLS sur SMTP…

Question fichiers de conf' tous faits, il y avait ceux de mon exposé à IEUFI. Mais, évidemment, cela dépend des cas.

Pour le reste, franchement, en l'absence des messages d'erreur, je ne peux rien faire. « Ça ne marche pas » n'est pas un message d'erreur :-) Prenons un exemple concret, le TLD cambodgien :

% zonecheck kh
ERROR: Unable to find nameserver IP address(es) for kh.cctld.authdns.ripe.net

Là, on peut agir : la zone "kh" liste parmi ses serveurs de noms un kh.cctld.authdns.ripe.net qui n'existe pas (comme on peut le vérifier avec dig). Il faut remplacer par le nom correct.

Dans le journal, j'ai donné l'URL du texte écrit (pas un discours) du gouvernement.

Moi, j'ai compris (mais je ne suis pas sûr qu'Ayrault ait compris ce qu'il demandait) qu'il fallait en effet chiffrer en TLS entre serveurs (RFC 3207). D'où le titre de mon journal.

Ah, je ne prétends pas être capable de lire la pensée du gouvernement :-) Comme le projet de Merkel d'un Internet européen, c'est en effet le plus grand flou.

Il faut aussi noter qu'il est très important, pour la sécurité de l'Internet, d'avoir au moins deux mises en œuvre libres de TLS, au cas où…

Les enregistrer dans le doute me parait très dangereux, cela peut vous faire passer dans la catégorie « stocke des données personnelles » (et doit donc faire des formalités à la CNIL).

Et, pendant qu'on en est au flicage, il faudrait aussi stocker le numéro de port :-) http://www.bortzmeyer.org/6302.html

lut.im a un plugin Shutter et Shutter a une fonction très jolie de floutage (Shutter est le logiciel de capture d'écran recommandé).

Visible par les routeurs ? Mais non, pas du tout, si on utilise HTTPS.

Euh, cela n'a rien à voir. Là, on discutait de ce qu'on pouvait faire lorsqu'on est la victime d'une attaque ou bien lorsqu'on est le réflecteur. BCP 38 est ce que peuvent faire les opérateurs qui hébergent l'attaquant. C'est certainement très important mais, en attendant que tout le monde le fasse, il faut bien prendre des mesures contre les réflecteurs, et pour protéger les victimes.

Autre opérateur qui a communiqué sur ces attaques (et ne vend pas de solutions anti-dDoS), Renater