Stéphane Bortzmeyer a écrit 655 commentaires

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 ?

Mais je ne crois pas que les créateurs de SeenThis l'aient jamais présenté comme un Twitter-Like, complet avec toutes ses fonctions, y compris la porte vers PRISM. La dépêche originale de cette discussion parlait effectivement de Twitter mais c'est maladroit et cela ne se retrouve pas sur le site de SeenThis.

Oui, ce serait un vrai truc intéressant. Yakafokon.

Non, pas du tout, l'objectif n'était pas de copier Twitter. Déjà, c'est du shortblogging, pas du microblogging. Ensuite, c'est plus orienté Web qu'API. Et il doit y avoir plein d'autres différences. À commencer par la plus énorme : les conditions d'utilisation. Lisez-les avant d'utiliser Twitter.

Un article de chercheurs intéressant, qui explore les mêms thèmes : http://arxiv.org/abs/1202.4503

L’article « A Critical Look at Decentralized Personal Data Architectures » est un court résumé des problèmes que pose la conception d’un rézosocio décentralisé ou réparti. Les auteurs notent à juste titre que le problème est difficile et que les projets issus d’un bistrot et spécifiés en cinq minutes sur un coin de table n’avaient aucune chance d’affronter réellement Facebook ou Twitter. L’article décrit bien ces difficultés et les problèmes que cela pose (dans mon exposé à Pas Sage en Seine, je mentionnais uniquement le problème de la découverte mais il y en a d’autres). Ils notent également que les propriétés qu’on attend d’un rézosocio sont souvent contradictoires et qu’il va falloir faire des choix.

Les auteurs critiquent à juste titre la confusion fréquente qui est faite entre caractéristiques techniques d’un système et les valeurs qu’on défend.

L’article étant assez court, pas mal de points ne sont traités que sommairement. Par exemple, les auteurs critiquent les systèmes décentralisés comme obligeant M. Michu a installer et à gérer son propre serveur, oubliant complètement qu’on peut parfaitement utiliser des serveurs gérés par d’autres (associations, entreprises à but lucratif, groupes de copains, etc). Tous les systèmes décentralisés (à commencer par le courrier électronique) avaient pourtant cette possibilité depuis longemps.

L’article erre aussi parfois vers la caricature lorsqu’il explique qu’on ne peut jamais avoir un contrôle complet sur ses données, laissant entendre que, dans ce cas, autant laisser tomber et aimer Facebook. L’idée qu’on puisse vouloir limiter les dégâts (sans pour autant avoir un contrôle complet) ne semble pas mentionnée.

Autre manque, l’idée d’éducation et d’évolution. Pour les auteurs, la mentalité actuelle de M. Michu semble une loi naturelle, non susceptible de changement (« M. Michu s’en fiche de la vie privée »).

« On est sur le web, il faut faire court » On n'a pas la même conception du Web. La page « Seenthis, c'est quoi » fait 5500 caractères. Si c'est trop long à lire, c'est que l'humanité est foutue et doit être remplacée par une espèce supérieure.

Non, SeenThis a une architecture centralisée. Il n'est pas prévu de communication, à part celle que permet déjà le Web (les liens). Le cahier des charges de SeenThis n'était pas du tout de faire une Nième tentative ratée de rézosocio décentralisé.

Excellente idée (XMPP). J'attends le code source avec impatience.

J'attends avec impatience les superapplications Web libres qui vont, je n'en doute pas, être développées avec ces merveilleuses technologies.

Comme je ne programme pas du tout en PHP, je ne vais pas répondre sur la technique mais sur le projet : SeenThis est avant tout un projet éditorial. Son but est le contenu, l'interaction, etc. Les auteurs disent ouvertement que ce n'est pas le code qui les intéresse.

À mon humble avis, il serait donc bon de ne pas discuter que de la technique mais aussi des choix sociaux, de l'interaction etc.