Re: usage de cancel-clock

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