Sujet : Re: comment ignorer les cancels non authentifiés
De : iulius (at) *nospam* nom-de-mon-site.com.invalid (Julien ÉLIE)
Groupes : fr.comp.usenet.serveursDate : 25. Feb 2022, 20:24:29
Autres entêtes
Organisation : Groupes francophones par TrigoFACILE
Message-ID : <svbadd$2h8ln$1@news.trigofacile.com>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
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)