Re: Cancel-Key et Cancel-Lock ne fonctionnent pas sur dodin.fr.nf (was: usage de cancel-clock)

Bonsoir,

C'est donc confirmé : il n'y a aucune authentification utilisée dans le
calcul de CK effectué par le serveur.

Ce n'est pas exact.
L'authentification (uid) EST BIEN UTILISÉE dans le calcul du CK "utilisateur" mais il y a une subtilité que je vais développer plus loin.
L'authentification n'est en revanche pas REQUISE pour le calcul du CK "administrateur" (raison pour laquelle il faut différencier les secrets utilisateur ET administrateur).
Rappel du contexte :
------------------
Dodin permet les publications ANONYMES (comme aioe). Donc, dans anonyme, il y a UTILISATEUR NON FORMELLEMENT IDENTIFIE.
Pour faire encore plus simple, pour publier, le reader n'a pas besoin de préalablement envoyer la succession des commandes AUTHINFO USER/PASS (il ne s'identifie donc pas formellement auprès du serveur).
Tout le monde suit?
OK.
Exemple de ce qui se passe dans les deux cas :
--------------------------------------------
mid = <monarticle@monserveur>
sec = un_secret_utilisateur_ou_serveur
Je m'identifie FORMELLEMENT auprès du serveur avec AUTHINFO USER/PASS, donc :
uid = franck
Le calcul de la clef sera donc :
HMAC(un_secret_utilisateur_ou_serveur, franck<monarticle@monserveur>)
Maintenant, si je ne m'identifie pas FORMELLEMENT auprès du serveur :
uid = "" (rien)
Le calcul de la clef sera donc :
HMAC(un_secret_utilisateur_ou_serveur, <monarticle@monserveur>)
Résultat des courses, n'importe qui peu annuler le message de n'importe qui, puisque tout le monde à le même uid = "" (rien)! Et c'est vraiment le cas de le dire, cet uid ne vaut rien!
Pour que cela fonctionne "à minima", il faudrait que dodin utilise comme uid l'adresse IP du client à la place du login (puisqu'il n'en demande pas).
Mais ce n'est pas une solution fiable car cet élément peut :
- Être mutualisé (Vpn etc...)
- Changer entre la publication et l'annulation.
Car OUI, en INJECTION la paire CL/CK ne suffit pas, il faut aussi que cet élément (qui identifie formellement l'auteur) soit IDENTIQUE entre l'article "cancel" et l'article d'origine sinon il ne DEVRAIT pas le traiter et encore moins le relayer!
(Ce qui n'est pas vrai pour les messages relayés puisque dans ce cas, le cancel est traité si la paire CL/CK est correcte).
Vous êtes toujours là???
Je POSTe aujourd'hui un message depuis l'IP 1.2.3.4 et demain je poste l'annulation depuis 4.3.2.1 (Soit parce que le DHCP de mon FAI m'a attribué une nouvelle IP soit parce que j'ai changé de serveur VPN).
Même si j'envoie un CK correct (ou que le serveur me le génère) et même si le CL sera forcément correct après hashage, le serveur NE DEVRAIT PAS accepter de le traiter/relayer car les deux éléments qui identifient l'auteur des articles (cancel et original) sont différents (1.2.3.4 et 4.3.2.1).
Je suis AFFIRMATIF pour le serveur que je code, je laisse Julien répondre pour INN.
Voilà, j'espère avoir été plus clair.
Franck