Stéphane Bortzmeyer a écrit 655 commentaires

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

En effet, ce serait tout à fait inutile. Le shell interactif de l'utilisateur n'est pas le problème (puisqu'on exécute le script avec ses privilèges), le problème est le /bin/sh du système, qui est appelé à des tas d'occasions.

Tous les script-kiddies de la planète sont à l'attaque depuis hier soir, notamment contre les sites Web : https://gist.github.com/anonymous/929d622f3b36b00c0be1

Quand on signale une faille de sécurité, cela vaut vraiment la peine d'indiquer le CVE. Cela permet de retrouver plus facilement. Donc, CVE-2014-6271

En effet, et un nouveau CVE a été attribué pour suivre cette vunérabilité dans la vulnérabilité, CVE-2014-7169. Attendez vous à un patch du patch http://seclists.org/oss-sec/2014/q3/685

Je peux dire en tout cas pourquoi j'utilise Twitter :

• le fait que ce soit public est un avantage Pas de réglages très compliqués de la vie privée (Facebook…) que personne ne comprend, et que de toute façon Facebook change quand il veut et viole encore plus souvent (PRISM…) Avec Twitter, le modèle de sécurité est simple à expliquer : tout est public (j'ignore les DM, assez peu utilisés).

• la limite de taille est plutôt un avantage. Cela évite les longs bla-blas et la créativité s'épanouit bien quand il y a des contraintes (alexandrins, haikus, limericks…)

"Reiter complained of having to wait weeks for an external mail server to be set up just so that he could get mail on his smartphone" Bon, si c'est vrai, il faut changer les informaticiens d'urgence, mon smartphone fait du courrier avec un serveur Debian et ça m'a pris une heure…

Il me semble que ces difficultés d'échange avec le reste du monde sont justement un très fort argument pour passer sur Linux. Cela illustre bien le manque d'indépendance de l'informatique par rapport à Microsoft, et la nécessité de secouer le joug.

Bien sûr que si, qu'OTR v3 demande toujours une authentification. Autrement, on serait trivialement vulnérable aux attaques de l'homme du milieu. La nouveauté d'OTR v3 est simplement d'ajouter une nouvelle possibilité d'authentification, fondée sur un secret partagé (les deux premières étant question/réponse et vérification du condensat de la clé publique). Il faut donc se mettre d'accord sur un secret commun (en utilisant un canal de communication sûr !), ne pas le perdre, etc. Pas vraiment Michu-compliant. https://securityinabox.org/en/pidgin_securechat#3.3

BitMessage est un protocole spécifique. On ne peut parler qu'aux utilisateurs de BitMessage. CaliOpen utilise les normes de l'Internet (IMF, SMTP, etc) et on peut donc parler aux gens qui n'utilisent pas CaliOpen.

C'est normal, on était au même atelier aux RMLL :-)