Path: ...!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!.POSTED.176.143-2-105.abo.bbox.fr!not-for-mail
From: =?UTF-8?Q?Julien_=c3=89LIE?= <iulius@nom-de-mon-site.com.invalid>
Newsgroups: fr.comp.usenet.serveurs
Subject: =?UTF-8?Q?Re=3a_comment_ignorer_les_cancels_non_authentifi=c3=a9s?=
Date: Fri, 25 Feb 2022 20:24:29 +0100
Organization: Groupes francophones par TrigoFACILE
Message-ID: <svbadd$2h8ln$1@news.trigofacile.com>
References: <sv5i3p$6d2$1@ns507557.dodin.fr.nf>
 <sv64jp$2d1l0$1@news.trigofacile.com> <sv6eb7$f2t$1@ns507557.dodin.fr.nf>
 <sv7k55$p4m$1@rasp.pasdenom.info> <sv8h7a$2elhi$1@news.trigofacile.com>
 <sv8j07$a11$1@rasp.pasdenom.info> <sv8nmq$2eol9$1@news.trigofacile.com>
 <sv9pma$br0$1@rasp.pasdenom.info> <svauo8$2h228$1@news.trigofacile.com>
 <svb4t1$o1g$1@rasp.pasdenom.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 25 Feb 2022 19:24:29 -0000 (UTC)
Injection-Info: news.trigofacile.com; posting-account="julien"; posting-host="176.143-2-105.abo.bbox.fr:176.143.2.105";
	logging-data="2663095"; mail-complaints-to="abuse@trigofacile.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.1
Cancel-Lock: sha1:h0dvOrEIasWEhlEm1mZI76uT0Lc= sha256:ANdwEEuvebd2IWGCcovaFe+maA9w3eYQU1662g9mrbs=
	sha1:+alHsALvjLQZE6Na67FhuJYIlR4= sha256:dPh2uBjVw8r16Gkl6TiLexrQm+x99ty2ISKYw15hzjw=
In-Reply-To: <svb4t1$o1g$1@rasp.pasdenom.info>
Bytes: 4878
Lines: 69

Bonsoir Stéphane,

>> Je ne comprends pas bien le besoin de générer le Cancel-Lock depuis le
>> posting-host.
>> Quel est le problème exactement avec la conf du serveur de Jean-Daniel ?
> 
> À moins de dire une grosse bêtise, il me semble que tous les clients NNTP
> sur dodin ont le même user (ils ne sont pas authentifiés) et avec le code
> fourni par Gérald, le cancel-lock est généré pour un user. Donc si c'est
> le cas n'importe quel utilisateur non authentifié pourra annuler un post
> dodin.

Ah oui, tout à fait. Le code Perl en question calcule la clé ainsi :
   hmac_sha256_base64($message_id, $user . $CANCEL_LOCK)
sans regarder si $user est vide ou non.
Je suis d'accord avec toi que n'importe quel utilisateur non authentifié 
pourra annuler un message de n'importe quel autre utilisateur non 
authentifié. Il vaut mieux ne pas utiliser ce code si les utilisateurs 
ne sont pas tous authentifiés.

En ce qui concerne l'implémentation dans INN 2.7.0, il n'y a pas de 
Cancel-Lock généré pour les utilisateurs non authentifiés, mais 
uniquement le Cancel-Lock de l'administrateur.
Seul l'administrateur pourra annuler des messages d'utilisateurs non 
authentifiés. Si un utilisateur souhaite annuler un article, il devra le 
demander à l'administrateur.

P.-S. : prendre en compte le posting-host ne marchera pas toujours, à 
moins de supposer que tous les utilisateurs ont une IP fixe, et que 
personne ne peut usurper l'IP d'un autre.
Ce n'est pas vraiment une solution sécurisée.


Si tu regardes les en-têtes de mes messages, tu pourras voir 2 lignes de 
hashes de Cancel-Lock. La première correspond à l'administrateur 
(toujours renseignée) et la deuxième à l'utilisateur (s'il est authentifié).

Cancel-Lock: sha1:Tzc/o42nD7uyTe03v4pQzyPbm/c= 
sha256:yeETlznbDezy3LIuA1+1yXXN/hsyWVVigU69vvZUorU=
	sha1:W1e6DoXY5PWbEZ6Xv/nnpiOGj/8= 
sha256:VO2QdiBZ6sCzb1T7C6RnGp/pi5lAcl4PrJBiWgnDT3s=


Si j'annule un article, ou en remplace un (Supersedes), INN 2.7.0 va 
automatiquement générer un Cancel-Key correspondant à l'utilisateur 
(authentifié). S'il n'est pas authentifié, il n'y a aucun Cancel-Key ajouté.
Et l'administrateur peut annuler les messages qu'il souhaite avec 
l'outil "gencancel" qui créera pour lui l'article d'annulation avec le 
bon Cancel-Key.

C'est ainsi qu'est censé fonctionner Cancel-Lock. L'utilisation du nom 
de l'utilisateur est une recommandation de la RFC. Le reste est 
insuffisamment sécurisé et je ne compte pas l'implémenter nativement 
dans INN. (Ce qui n'empêche pas Jean-Daniel, s'il préfère ne pas 
authentifier ses utilisateur, changer le script Perl pour mettre 
$attributes{'hostname'} au lieu de $user -- ceci devrait rendre plus 
difficile l'usurpation d'identité.)


filter_post() has access to a global hash %attributes which contains 
information about the connection as follows: $attributes{'hostname'} 
will contain the hostname (or the IP address if it does not resolve) of 
the client machine, $attributes{'ipaddress'} will contain its IP address 
(as a string), ...

-- 
Julien ÉLIE

« Don't marry for money; you can borrow it cheaper. » (proverbe
   écossais)