Stéphane Bortzmeyer a écrit 617 commentaires

Je suis preneur de plus de détails sur les NAS en question. Sans même parler de leur licence (beaucoup sont des boîtes noires), il y en a vraiment qui font le courrier, la messagerie instantanée, le blog, et tout ce qui fait une "présence en ligne" ?

FreedomBox est loin d'être prête. Et puis, ce n'est pas sur le même créneau : c'est moitié client et moitié serveur, et ça met surtout l'accent sur l'ultra-sécurité (chiffrement, routage en oignon, etc).

NSEC3 est normalisé dans le RFC 5155 et n'est pas du tout un "certificat de révocation". Une introduction en français à NSEC3 : http://www.bortzmeyer.org/5155.html badfe11a n'est pas un hash mais un sel.

Il manque l'URL :-) http://www.redfoxcenter.org/Internet/index.html ?

LISP peut aussi être déployé sur des sites finaux.

Sans tunnels, il existe d'autres solutions, comme ILNP http://www.bortzmeyer.org/6740.html mais qui ne sont pas soutenues par de gros acteurs (ILNP, comme HIP, vient du monde des machines terminales, LISP du monde des routeurs ; pas le même point de vue).

Quant à l'encapsulation dans UDP, on voit bien que vous n'avez jamais essayé de déployer un nouveau protocole de transport (indications : middleboxes, pare-feux).

Il n'y a pas de crypto dans LISP-the-protocol :-)

Si mais s'ils réagissent tous aussi mal que l'auteur de libcurl, ça promet…

Plus précisement (parce que Stenberg nie bêtement le problème, en jouant sur les mots et en prétendant qu'il n'y a pas de paramètres booléens dans libcurl), le paramètre est un long (libcurl n'utilise effectivement pas bool) mais qui prend deux valeurs, 0 pour "non" et 1 pour "oui". C'est donc un quasi-booléen et l'erreur des programmeurs qui ont passé "true" à une autre fonction de libcurl est tout à fait excusable (même si BFG les prend de haut).

Le problème n'est donc pas dans cURL, mais bien chez les développeurs qui ne lisent pas les documentations

Avec une telle mentalité, on aura encore des failles de sécurité pendant longtemps. Peut-être que les abonnés à LinuxFr ne mettent jamais de bogues dans leurs programmes mais, dans le monde réel, avec les contraintes de délai et le PHB qui demande qu'on livre le code avant-hier, les bogues arrivent. Comme le rappelle très justement Gof dans son commentaire, le rôle d'une API n'est pas de tendre des pièges subtils, pour pouvoir ricaner ensuite de l'incompétence des programmeurs qui sont tombés dedans, c'est de rendre l'erreur difficile.

qui à mon avis cherchent à faire du sensationnel plein de superlatifs

Je ne sais pas ce qu'il vous faut : des dizaines de programmes vulnérables à une attaque triviale (et pas des petits scripts PHP écrits par Jean-Kevin Boulet dans son coin pour son usage personnel, non des codes utilisés par des dizaines de milliers de gens pour des usages critiques, par exemple du paiement en ligne), et ça ne vous suffit pas ?

C'est un obstacle qu'on rencontre souvent dans le monde du logiciel privateur, le vendeur qui nie les failles de sécurité parce que cela le gonfle de corriger. Apparemment, ce mal frappe aussi le logiciel libre.

Non, Stenberg ne dit pas ça du tout. Il dit que lui n'a pas été contacté (rappelons que libcurl n'avait pas de faille).

Désolé, mais c'est vrai. Les auteurs de libcurl n'ont pas été contactés tout simplement parce qu'il n'y a pas à proprement parler de faille dans libcurl, juste une API dangereuse.

Euh, non, Go, Ada ou Java, pour ne prendre que trois exemples de langages typés, n'accepteraient pas un booléen là où on attend un entier. (A fortiori, ils ne le convertiraient pas.)

Les vulnérabilités citées dans l'article ont évidemment été signalées aux auteurs de logiciels avant la publication de l'article et plusieurs sont donc aujourd'hui corrigées.

Coded TCP est une idée géniale : quand le lien est mauvais (perd des paquets), ajouter des données (ben oui, ya pas de miracles, les codes correcteurs d'erreurs fonctionnent en ajoutant de la redondance).

Tout à fait et c'est pour cela que la comparaison avec IPv6 Mobile est erronée. Mais c'est la faute de l'article original qui, curieusement, mettait davantage l'accent sur la résilience (que SCTP fournit déjà) plutôt que sur la répartition de trafic.

Le groupe de travail a déjà sorti un RFC d'architecture : http://www.bortzmeyer.org/6182.html

Il n'y a plus de recommandation officielle sur la longueur du préfixe à allouer aux utilisateurs finals depuis le RFC 6177 http://www.bortzmeyer.org/6177.html

Une bonne lecture sur la question de la rénumérotation est le RFC 5887 http://www.bortzmeyer.org/5887.html

Pourquoi est-ce que le PI est important ? Si on n'a qu'un FAI, pas trop, sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).

Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.

L'affirmation « il suffit » est quand même assez ridicule. D'abord, la plupart des chiffres qu'on trouve sur le Web au sujet des adresses IPv4 allouées mais non utilisées sont faux. Il ne faut pas se fier à ce qu'on trouve sur le Web. Les gens qui produisent ces chiffres confondent en général « non annoncé dans la DFZ - Default-Free Zone - BGP » avec « non utilisé ». Une entreprise a très bien pu utiliser son /8 en interne, sans l'annoncer à l'extérieur.

Ensuite, si vous pensez qu'Apple ou HP ont tort de faire cela et devraient rendre leur /8 (qui n'est pas inutilisé), prévoyez des frais d'avocats considérables… Les allocations des /8 ont été faites informellement et, pour prouver devant un tribunal qu'elles doivent être rendues, face aux avocats d'Apple, vous allez avoir du mal. La rénumérotation a un coût et Apple ne se laissera pas faire.

Mais c'est amusant de voir les efforts que les gens sont prêts à faire pour ne pas migrer vers IPv6…

Pour tester, c'est simple :

Site qui a v6 :

    % curl -v -6 http://www.afnic.fr/ > /dev/null
* About to connect() to www.afnic.fr port 80 (#0)
*   Trying 2001:67c:2218:2::4:20...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* connected
* Connected to www.afnic.fr (2001:67c:2218:2::4:20) port 80 (#0)

On voit les adresses v6, c'est bon.

Site qui n'a pas v6 (il a bien une adresse mais v4 seulement) :

% curl -v -6 http://www.fleurpellerin.fr/ > /dev/null     
* getaddrinfo(3) failed for www.fleurpellerin.fr:80
* Couldn't resolve host 'www.fleurpellerin.fr'
* Closing connection #0
curl: (6) Couldn't resolve host 'www.fleurpellerin.fr'

Bas niveau : getaddrinfo() en C

Haut niveau : libcurl ou libneon en C

Et tous les équivalents dans les autres langages (le problème est largement spécifique à C)

Ben, le NAT protège contre des attaques très rares (attaques par connexion directe, comme du temps de SQL Slammer) et ne protège pas contre les attaques qui sont de loin les plus fréquentes aujourd'hui (attaques par charge utile). Donc, il sert à quoi ?

Bof, cette sécurité est largement illusoire. http://www.bortzmeyer.org/nat-et-securite.html

Sur ce point, le RFC 6092 (recommandations aux auteurs de boxes) est une bonne lecture http://www.bortzmeyer.org/6092.html