Stéphane Bortzmeyer a écrit 664 commentaires

Non, ce n'est pas le but du DNS. http://www.bortzmeyer.org/pourquoi-le-dns.html

« Donner une signification au suffixe, c'est n'importe quoi en terme d'ergonomie. » Savoir qu'on dépend de la loi chinoise (.cn), états-unienne (.com) ou française (.fr) n'a donc aucune importance ?

Et, surtout, qui revient à faire un nommage à plat. Pourquoi diable avoir un système arborescent, avec plusieurs TLD, si c'est pour mettre des règles aussi baroques ?

Aujourd'hui, pour l'écrasante majorité des utilisateurs, l'important n'est pas de fournir une solution techniquement parfaite (surtout contre un adversaire de la taille et de la compétence de la NSA) mais d'augmenter le niveau moyen de sécurité, qui est de quasiment zéro (poste de travail MS-Windows pourri jusqu'au trognon, et données personnelles chez des fournisseurs de cloud en PRISMland). Donc, déjà permettre à M. Michu de mettre ses données sur une machine en France, qu'il contrôle au moins un peu, ce serait un progrès.

« pas envie d'une image disque / système dédié » Le but de Cozy est apparemment de créer un truc simple à administrer, soit pour les gens n'ayant pas d'expertise admin' système Unix, soit pour ceux qui l'ont mais qui n'ont pas le temps. Un système dédié est infiniment plus simple, on sait ce qu'il y a et ce qu'il faut gérer. Installer des trucs en plus, sur des systèmes très variables, cela casse complètement le côté « n'importe qui y arrive en un clic ».

« comment on fait pour le mettre sur un host externe si on sait pas si c'est chiffré correctement ? » Ça, c'est un syndrôme courant en sécurité, et qui est largement responsable du mauvais état de la sécurité de l'Internet. C'est ne pas vouloir une solution tant qu'elle n'est pas 100 % parfaite, y compris contre un attaquant professionnel et déterminé. Aujourd'hui, si on n'est pas Linuxien professionnel à plein temps, on a zéro sécurité : tout est dans le cloud, chez Oncle PRISM. Cozy est un des outils qui pourront permettre d'augmenter la sécurité de tout le monde, pas seulement de celui qui sait utiliser PGP. Alors, oui, un Cozy chez OVH, ce n'est pas une sécurité de niveau militaire. Mais c'est déjà infiniment mieux que tout sur Gmail et Google Docs.

« Je préfère un cloud qui prend 2Go de mémoire vive pour tourner mais qui tourne bien » D'autres donneurs de conseils trouvaient que 512 Mo, c'était scandaleusement élevé…

« tout est dans le client au niveau sécurité du cloud, pas du côté serveur » Euh, les clients se font pirater aussi, il faut en être conscient. C'est évidemment le cas de toutes les machines MS-Windows mais les lecteurs de LinuxFr auraient tort de croire que leur PC Debian ou ArchLinux à la maison est protégé contre toutes les attaques…

Si :-) https://net.educause.edu/edudomain/eligibility.asp

« obliger les entreprises à réserver un nombre toujours plus grand de noms de domaine » Pourquoi « obliger » ? Personne ne les oblige. Certains se croient obligés de le faire mais ils se trompent. Après tout, plus il y aura de TLD, plus, justement, il sera difficile de vouloir enregistrer son nom dans tous les TLD.

« je me demande quelle proportion des noms de domaines sont détenus légitimement (c'est à dire à des fins non crapuleuses ou spéculatives) » Euh, c'est une définition très restrictive de la légitimité. Est légitime uniquement ce que j'approuve :-) Sérieusement, les activités spéculatives (acheter et revendre des noms de domaine) sont légales. On peut les qualifier d'inutiles ou de stupides mais « illégitime », attention, quelle Haute Autorité des Noms de Domaine va considérer si linuxfr.org est un usage légitime du DNS ou pas ?

« mais comment peut-on justifier des doublons .com, .net et .edu, par exemple? » Je n'ai pas bien compris, là. Le DNS est arborescent. linuxfr.org et linuxfr.com sont deux noms différents. Il est tout à fait normal qu'ils soient gérés indépendemment. Sinon, à quoi servirait un espace de nommage arborescent ? Et, pour répondre, .edu est réservé aux universités états-uniennes, contrairement aux deux autres. Donc, si une fac s'appelle stanford.edu et que je m'appelle Joe Stanford, il est normal que je puisse avoir stanford.com. C'est bien le but de l'arborescence.

"Un" bureau d'enregistrement, pas "le". Blackknight n'est pas le seul :-)

Un contenu qui donne faim :-)

Je pinaille un peu mais le premier était .cn en chinois. Le .jeu fait partie d'une série différente, soumise aux règles ICANN (les ccTLD ou Country-code TLD y échappant).

Ah, exact, désolé, je m'avais trompé. Ceci dit, l'algorithme n'est pas tellement détaillé.

Non, le RFC 5321 ne parle pas du tout de cette vérification très contestée (ou d'une autre). Le seul qui la documente est le 7001 http://www.bortzmeyer.org/7001.html

Je me permets d'ajouter deux conseils à ce utile HOWTO : 1) au début, bien regarder le fichier journal (/var/log/mail.log par défaut sur une Debian) pour voir si tout se passe bien. Gérer un serveur sans regarder le journal, c'est être un chirurgien qui ne opère les yeux fermés. 2) tester son serveur avec des auto-répondeurs http://www.bortzmeyer.org/repondeurs-courrier-test.html

Pour SPF, l'enregistrement nommé SPF n'a quasiment jamais été utilisé. Comme noté dans le RFC 6686, qui faisait le bilan de SPF, le type d'enregistrement DNS recommandé est TXT.

http://www.bortzmeyer.org/6686.html

Plutôt Web de données, non ? (Web sémantique : pipeau, Web de données : concret).

Je ne sais pas trop mais, oui, il y a au moins un rapport avec FOAF.

C'est tellement résumé que cela n'a aucun sens (par exemple, ECDSA et RSA sont du chiffrement asymétrique tous les deux et la force de leurs clés est incomparable, à nombre de bits égaux).

Tout à fait, et j'en profite pour signaler cette excellente conférence pour les parisiens :

SSL/TLS, Benjamin Sonntag
associé gérant et directeur technique d'Octopuce,
co-fondateur de La Quadrature du Net

Vendredi 20 septembre 2013, 19h
La Cantine
151 rue Montmartre, Passage des Panoramas (Paris, 2ème arrondissement)

La réponse d'Adrien est excellente (la plupart des failles sont des attaques contre les pratiques - le mot de passe sur un post-it - pas contre les mathématiques). Une précision : 128 bits, c'est vraiment très court pour RSA (il existe des attaques meilleure que la force brute), la taille recommandée est 2048 bits.

En effet, ces articles sont sensationnalistes et souvent faux. (De toute façon, quand quelqu'un dit "crypter" au lieu de "chiffrer", c'est clair qu'il ne connait rien à la crypto.) Du travail de journaliste classique ("Mme Michu ne comprend pas les nuances, il faut simplifier.")

Donc, non, la NSA ne peut pas tout déchiffrer. Néanmoins, ils peuvent faire beaucoup de choses donc il ne faut pas croire non plus que la crypto est une solution magique à tous les problèmes. Par exemple, les logiciels états-uniens ont des portes dérobées et il ne faut donc pas utiliser Windows (mais je pense que pas mal des lecteurs ici le saveient déjà).

Mais si, l'écoutant sait des choses, même avec TLS, comme le fait qu'il y a une communication, combien d'octets sont échangés et même (avec la reprise de session) si ce client était déjà passé.

Le RFC se focalise sur la discrétion des protocoles. La question de la protection du contenu est déjà bien connue, celle des protocoles semble avoir été pas mal négligée.

Et en quoi est-ce que TLS va protéger la vie privée ? Il y aura la requête DNS, les adresses IP utilisées et même (cf. mon article, qui notait ce point du RFC) le fait que cette machine s'était déjà connectée… Bref, TLS ne protège que le contenu, ce qui est déjà pas mal mais n'est pas le sujet du RFC, qui se focalise sur les méta-données, bien plus dures à protéger.

DNSSEC garantit l'authenticité des requêtes, mais ne fait rien pour la confidentialité.

Quant à IPv6, non, il a pile la même sécurité qu'IPv4 http://www.bortzmeyer.org/ipv6-securite.html

Il faut lire le RFC (ou mon résumé) qui justement explique cela. Indication : il n'y a pas que les données, les méta-données sont très sensibles aussi.

Un exemple est fourni par IP lui-même. Le mode non-connecté fait qu'il faut mettre l'adresse IP source dans chaque paquet (il faut bien que les réponses et les avis de non-remise soient transmis). Donc, le destinataire connait l'adresse IP source. Ce n'était pas obligatoire. X.25 avait un autre système où le réseau établissait la connexion et où le destinataire ne connaissait pas forcément le numéro de l'appelant (merci à Rémi Desprès pour ses explications à ce sujet).

Mon but n'est pas de dire qu'il faut revenir à X.25 :-) simplement de montrer qu'il y a eu des choix, qu'ils n'étaient pas obligatoires (« une autre technique est possible ») et que ces choix ont des conséquences pour la vie privée. C'est le thème principal de ce RFC : un protocole n'est pas purement technique.

Autre exemple, le DNS : le résolveur transmet au serveur faisant autorité la totalité de la requête, pas juste le domaine pour lequel le dit serveur fait autorité. Le serveur de la racine sait ainsi qu'on regarde linuxfr.org. Il y a des bonnes raisons pour cela (le problème est en effet complexe, ici, la bonne raison, c'est le fait que le résolveur ne connaisse pas les "zone cuts") mais d'autres protocols faisaient différemment.

Le "il suffit" est trop court. Il faut aussi être sûr du logiciel, donc, au minimum, logiciel libre, sinon, aucune sécurité.

Oui, j'ai peut-être eu tort de mentionner PRISM, c'était pour attirer l'attention mais, en effet, techniquement, c'est un problème différent.

Par contre, c'est tout à fait faux de dire qu'il y a déjà "pas mal de matière sur le sujet [les protocoles]" ou alors il faut citer des références. Pour le DNS, par exemple, je n'ai jamais rien vu.

Enfin, "cryptage" n'est pas le bon mot http://www.bortzmeyer.org/cryptage-n-existe-pas.html

L'utilisation des backticks dans ce script m'interpelle. À quoi peuvent-ils bien servir dans ce cas ?