Stéphane Bortzmeyer a écrit 665 commentaires

"transférables de manière assez standardisée" Ça sent le type qui a transféré deux .com et croit que ça va être pareil partout. Non, bien au contraire, le transfert est très différent d'un registre à l'autre.

En effet, je n'ai fait aucun effort et je le clame. C'est le principe du Web : on publie le contenu, la présentation est du ressort du navigateur.

islamic-news.info est en panne depuis au moins dimanche, même sans censure.

Au fait, c'est Tor. Thor est un dieu nordique :-)

Le premier argument, l'échange de clé, est curieux. J'ai envoyé des SMS chiffrés et je ne ne me souviens pas d'avoir eu à faire une opération manuelle, quelle qu'elle soit.

Celui sur les méta-données serait plus convaincant si les auteurs n'oubliaient pas de dire que les méta-données sont toujours en clair (par définition, elles sont nécessaires pour l'acheminement). Au lieu qu'elles soient connues d'Orange ou de SFR, elles seront connues d'OpenWhispers.

Oui, Free fait cela et pas mal d'autres résolveurs d'enterprise également. C'est pour empêcher les attaques par changement

Le temps passé a surtout été pris par des discussions au sein du comité technique… Le problème est très complexe (même si, sur LinuxFr, Jean-Kevin explique volontiers que c'est trivial).

Non. Sur chaque site, tous les opérateurs (et tous les types de ligne) sont testés.

Quel serait l'intérêt de les placer chez un particulier plutôt que chez IP Label (la boîte qui fait les mesures) ? Cela aurait par contre un gros inconvénient, la difficulté à contrôler l'environnement (contrôle qui est nécessaire pour faire des comparaisons sur le long terme).

Euh, non les points de mesure ne sont pas proches du DSLAM. C'est bien expliqué dans le rapport mais, évidemment, il faudrait le lire, ce qui est fatiguant.

Financé par les FAI (qui décident donc, au final).

Autrement, ce premier commentaire est en effet du niveau de café du commerce que j'attendais…

Pour faire une mesure, on peut en effet choisir d'avoir peu de points avec du matos perfectionné ou plein de points avec du matériel douteux (machine Windows bourrée de virus qui la ralentissent, WiFi qui rame…)

La législation utilisée n'a guère d'importance puisque n'importe quelle AC (pas forcément celle dont on est client) peut émettre un vrai/faux certificat pour votre site et il sera accepté. C'est la plus grosse faiblesse de l'usine à gaz X.509 (ce que les journaliste appellent les « certificats SSL »).

Un exemple, l'émission d'un faux certificat gmail.com par une AC française dont Google n'était pas client
http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html

Mais, jusqu'à présent, je n'ai rien vu qui indique pourquoi cette nouvelle AC serait plus acceptée (par exemple par Microsoft…) que CAcert.

Si les gens de HTTP tenaient le même raisonnement, on n'améliorerait jamais la vie privée sur l'Internet… Heureusement, ils sont comme nous, ils règlent les problèmes de leur protocole (par exemple, dans HTTP 2, avec le chiffrement automatique, même quand l'URL n'était pas https) et les gens du DNS en font autant. Si chacun fait son boulot, les choses s'amélioreront. (Les gens de TLS sont au boulot, aussi, pour chercher une solution au problème de SNI qui envoit le nom du serveur en clair.)

Ne pas oublier aussi (ce point est marqué dans l'Internet-Draft) que les serveurs DNS ne sont pas forcément sur le chemin habituel. Quelqu'un qui visite le site Web du claoude souverain https://www.cloudwatt.com peut ne pas se rendre compte que ses requêtes DNS sortent de France et vont chez l'entreprise US Verisign.

Si cette analyse était exacte, l'IETF pourrait économiser pas mal de ressources humaines en laissant tomber tout le projet « DNS privacy ». Malheureusement, elle est fausse. « ça contient peu d'information » ? En effet, juste le fait que je m'intéresse au nom de domaine du Front National, de Daesh, des Alcooliques Anonymes, où tout autre domaine que je n'ai aucune raison de garder privé. Sans compter le client BitTorrent qui diffuse dans le DNS qu'il cherche son tracker. Certainement, on n'a aucune raison de cacher le fait qu'on utilise BitTorrent. « ça n'est pas nominatif » Si. Le nom demandé peut l'être (j'ai vu passer pc-de-philippe.example.com dans tcpdump) et l'adresse IP source également (si on utilise un résolveur qui a peu de clients, voire un résolveur individuel).

« les requêtes qui sortent du serveur de cache (voire du cache de Firefox) doivent être hyper-minoritaires » Pourquoi ne pas tester, plutôt que de supposer ? La seule page d'accueil de cnn.com déclenche l'envoi de 100 requêtes DNS (oui, 100). « pas de quoi constituer une base de données exhaustive, loin de là » Des tas de gens le font et constituent de telles bases. Ce n'est pas vraiment un secret, à chaque conférence sur les botnets, le malware ou le DNS (comme par exemple à l'OARC) il y a un exposé sur de telles collectes.

« je n'ai pas compris en quoi ça concernait les gens qui n'hébergent pas leur serveur DNS chez eux » Je suppose que cette phrase concerne le résolveur. Auquel cas, héberger le sien permet justement de diminuer l'information envoyée au résolveur du FAI. Et, même si on fait confiance au résolveur utilisé, on peut être inquiet des gens sur le trajet qui écoutent (le trafic DNS étant en clair, c'est trivial).

« je veux connaire l'IP du serveur connu comme www.google.com" est une donnée privée » Mauvais exemple (car tout le monde utilise Google, le « anonymity set » est donc très grand). Plutôt « je veux connaître l'adresse IP de www.npd.de »

Ironiquement, les tutoriels « le DNS pour les nuls » (par exemple cette vidéo erronée) font en général la même erreur (ils sont faits par des gens qui ne connaissent pas le DNS). Par contre, Wikipédia est correct

Il y avait deux raisons à ce choix de transmettre la requête (le QNAME pour « query name ») entier. Il faut d'abord se rappeler qu'un client DNS ne sait pas forcément où est le « zone cut », la frontière de zone. Par exemple, rien dans la syntaxe n'indique si gouv.fr est dans la même zone (et donc les mêmes serveurs) que fr.

1. Autrefois, il était fréquent qu'un serveur héberge une zone parente et des zones filles (par exemple, certains serveurs de la racine étaient également serveurs de .com). Envoyer la requête entière économisait quelques aller-retours.

2. Trouver le « zone cut » n'est pas complètement trivial pour un résolveur DNS ordinaire. S'il fait du DNSSEC, tout le travail est déjà fait (un résolveur DNSSEC doit connaître les « zone cuts » pour savoir où envoyer la requête DS). Mais, lorsque les résolveurs DNSSEC n'existaient pas, ce code n'était pas toujours intégré.

Ces deux raisons ne sont plus valables (et la première depuis très longtemps), donc cela justifie de passer à la « QNAME minimisation ».

On ne l'a pas fait exprès :-) Les lieux des réunions IETF sont choisis très longtemps à l'avance.

Le vrai travail « vie privée » à l'IETF avait commencé à Vancouver.

Le mieux est de lire l'Internet-Draft qui devrait, normalement, servir de base au travail du nouveau groupe DPRIVE.

Je ne suis pas d'accord avec l'approche défaitiste « de toute façon, c'est fichu, il y a plein de fuites partout » Le travail de l'IETF est justement de boucher toutes les failles identifiées. J'ai cité le DNS parce que c'est un sujet que je connais mais d'autres personnes à l'IETF travaillent sur le reste.

En 2014, un hébergeur de courrier qui n'a pas TLS ? Cela me parait une raison largement suffisante pour en changer.

Et, en français, un excellent article sur LinuxFr https://linuxfr.org/news/une-faille-nommee-shellshock

Maintenant que c'est un peu calmé, on peut lire quelques bons articles :

• Une très bonne explication par le découvreur de la faille lui-même, ainsi qu’une discussion de ce que bash aurait dû faire pour ne pas nous mettre dans cette situation,
• Une autre discussion technique sur comment réparer le problème proprement, argumentant qu’ajouter automatiquement toute fonction contenue dans une variable d’environnement quelconque était de la folie,
• Pour éviter d’avoir cinquante mille PoC (Proof of Concept, une exploitation de la faille pour montrer qu’elle est réelle), un projet les regroupe toutes sur Github.

Euh, si l'attaquant peut écrire le script à volonté oui, mais, en pratique, dans une attaque à distance, l'attaquant n'a pas le choix, il doit exploiter les scripts existants sur le serveur :-)

Ou d'autres bons articles techniques comme http://lcamtuf.blogspot.fr/2014/09/quick-notes-about-bash-bug-its-impact.html ou https://news.ycombinator.com/item?id=8361574