Path: ...!3.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!news.mb-net.net!open-news-network.org!aioe.org!Y6xw0Zqn2YbQSV4xFX801g.user.46.165.242.91.POSTED!not-for-mail
From: Franck <franck@email.invalid>
Newsgroups: fr.comp.usenet.serveurs
Subject: Re: Cancel-Key et Cancel-Lock ne fonctionnent pas sur dodin.fr.nf
 (was: usage de cancel-clock)
Date: Sat, 10 Sep 2022 17:50:59 +0200
Organization: Aioe.org NNTP Server
Message-ID: <tfibp3$19c2$1@gioia.aioe.org>
References: <tfers7$g3o$1@ns507557.dodin.fr.nf> <tfg2ei$1ocg$1@gioia.aioe.org>
 <tfhjf7$2vm$1@ns507557.dodin.fr.nf> <tfhm4f$nvd$1@shakotay.alphanet.ch>
 <tfhq15$420$1@ns507557.dodin.fr.nf> <tfhvq7$26r$1@shakotay.alphanet.ch>
 <tfi0ls$5fv$1@shakotay.alphanet.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="42370"; posting-host="Y6xw0Zqn2YbQSV4xFX801g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.2
Content-Language: fr
X-Notice: Filtered by postfilter v. 0.9.2
Bytes: 4288
Lines: 91

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