Path: ...!news.mixmin.net!aioe.org!eG/dTHymUD4LZnrZkp+EBw.user.46.165.242.91.POSTED!not-for-mail
From: Franck <franck@email.invalid>
Newsgroups: fr.comp.usenet.serveurs
Subject: Re: usage de cancel-clock
Date: Fri, 9 Sep 2022 20:59:30 +0200
Organization: Aioe.org NNTP Server
Message-ID: <tfg2ei$1ocg$1@gioia.aioe.org>
References: <tfers7$g3o$1@ns507557.dodin.fr.nf>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="57744"; posting-host="eG/dTHymUD4LZnrZkp+EBw.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: 6507
Lines: 164

Le 09/09/2022 à 10:01, jdd a écrit :

> Bonjour,
> 
> Je n'ai sans doute pas cherché assez, mais je n'ai pas trouvé comment un 
> simple utilisateur pas forcément doué en informatique peut utiliser 
> cette procédure :-(
> 
> merci
> jdd

Bonjour jdd,

Je vais essayer d'être le plus clair possible tout en essayant de faire 
simple, mais bon, le CL/CK reste technique dans sa mise en œuvre.


Commençons par les abréviations que je vais utiliser :
----------------------------------------------------

CL : Cancel-Lock
CK : Cancel-Key
sec : secret (Clef de cryptage pour l'algorithme de hashage)
mid : Message-ID
uid : Identifiant de l'utilisateur authentifié.

Hash : Algo de hashage (principalement SHA1 et SHA256).
Hmac : Type de code d'authentification de message basé sur un algo de 
hashage et un secret.
Base64 : Type d'encodage de caractères.


Allons-y pour la musique :
------------------------

Un serveur dispose de deux secrets (sec) pour générer les CL/CK, un 
"utilisateur" et un "administrateur" (il est le seul à les connaître).

Le premier permet de générer des CL/CK pour les utilisateurs qui 
utilisent un client qui ne sait pas les générer, le second permet 
principalement à l'administrateur de pouvoir supprimer les articles qui 
sont POSTés sur SON serveur.


Comment ça fonctionne ?
---------------------

Le serveur appose (ou étend) l'entête "Cancel-Lock" (Lors d'un POST 
uniquement) avec deux CL (utilisateur et administrateur) en sha256 et 
sha1 (pour compatibilité). Ce qui fait qu'un article se retrouve 
(généralement) avec une entête "Cancel-Lock" contenant quatre CL.


Comment calcule-t-on un CL ?
--------------------------

Tout simplement en commençant par générer le CK avec la formule suivante :

K = HMAC(sec, uid+mid)

Une fois "K" calculé, on y applique la formule magique :

CL = Base64(hash(Base64(K)))

C'est ce CL qui sera ajouté dans l'entête "Cancel-Lock".


Pour calculer "K", il y a deux façons (recommandées) de le faire :

- Pour un reader, l'uid doit être vierge.

- Pour un serveur :

     1°) Pour le CL utilisateur, l'uid doit correspondre à l'identifiant 
qui permet d'identifier le POSTeur sur le serveur.

     Nota : Un serveur NE DOIT PAS APPOSER de CL utilisateur S'IL N'EST 
PAS EN MESURE D'IDENTIFIER FORMELLEMENT L'UTILISATEUR sinon n'importe 
qui pourrait émettre un "cancel" ou un "superseedes" valide (puisque le 
serveur génère automatiquement le CK pour les readers qui ne savent pas 
le faire!).


     2°) Pour le CL administrateur, l'uid doit être vierge.


Comment ça fonctionne ensuite ?
-----------------------------

C'est simple, lorsqu'un serveur reçoit un "Cancel" ou un "Superseedes" :

     - Sans CK lors d'un POST : le serveur crée le CK pour le client 
S'IL EST EN MESURE DE L'IDENTIFIER FORMELLEMENT comme étant l'auteur de 
l'article qui est ciblé par le cancel ou superseedes.

     - Avec un CK : Il récupère alors le contenu de l'entête 
"Cancel-Key" dans CET article et applique la formule 
Base64(hash(Base64(K))) pour chaque CK qu'elle contient.


Dans les deux cas, il vérifie ensuite que le CL de l'article CIBLE 
correspond à au moins un de ceux qui ont été calculés précédemment 
(grâce au hash du CK).

Pour finir, si c'est bon le serveur traite le cancel ou le supersedes 
sinon il ne fait rien.


That's all.
(Il y a encore quelques subtilités mais je n'irai pas plus loin ici).


Pour conclure, même si CL/CK n'est pas infaillible (notamment si la RFC 
n'est pas scrupuleusement respectée), cela permet un certain niveau de 
sécurité. Grâce à eux :

- Un article pourra être supprimé par l'utilisateur :

    1°) En utilisant le secret qu'il est le seul à connaitre (cas d'un 
reader qui sait générer les CL/CK),

    2°) Grâce aux CL/CK qui sont ajoutés par le serveur aux articles 
POSTés par un utilisateur IDENTIFIE (Cas d'un reader qui ne sait pas 
générer les CL/CK). Ici, le serveur étant le seul à connaitre son secret 
"utilisateur", personne ne pourra générer de CK valide sauf à être 
FORMELLEMENT identifié par le serveur.

- Un article pourra également être supprimé par l'administrateur, 
puisque un CL "administrateur" est ajouté à chaque article POSTé sur le 
serveur. Le CK pourra être généré par un outil qui utilise le secret 
"Administrateur" du serveur. (Pour INN c'est gencancel).

- Un administrateur ne peut pas générer de CK correct pour un article 
qui n'a pas été POSTé sur SON serveur car il ne connait que SON secret 
"administrateur" et pas celui des autres serveurs (heureusement!)


---


Voilà, j'espère que cela pourra aider à la compréhension du 
fonctionnement des CK/CL même si je le concède, ce n'est pas forcément 
simple d'en appréhender toutes les subtilités!


Tout ceci sera transparent (0 script, 0 programme externe) avec le 
serveur de news (sous Windows) que je finalise et qui sera disponible 
très prochainement (Avec également la possibilité de restreindre l'ajout 
d'entêtes "Approved", "Control" et "Superseedes" en fonction des 
utilisateurs).


Pour se faire une idée de ce à quoi cela ressemble, vous pouvez vous 
connecter sur mon serveur de tests : news.spitfire-nntp.fr:119

- Hiérarchie "fr" en lecture.
- Newsgroup "local.test" en écriture pour tester les publications.
- Newsgroup "local.spitfire.news.server" en lecture pour suivre l'avancé 
du projet.


Merci à Julien ELIE pour le feed 😄

Franck