Sujet : Re: usage de cancel-clock
De : franck (at) *nospam* email.invalid (Franck)
Groupes : fr.comp.usenet.serveursDate : 10. Sep 2022, 06:47:56
Autres entêtes
Organisation : Aioe.org NNTP Server
Message-ID : <tfh8ec$r4p$1@gioia.aioe.org>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Le 09/09/2022 à 12:10, M.V. a écrit :
MID, STP ?
Message-ID
Tous les serveurs doivent faire de même pour la génération et la vérif
Quand tu dis « doivent » tu veux dire « ils ont l'obligation » ou bien
« je suppose que » ?
La RFC "préconise" ces éléments, après rien n'empêche d'utiliser un autre moyen qui permette d'identifier le message et son auteur.
Donc MID et UID en sont le reflet.
Mais si tu veux en plus ajouter l'entête "Date:" dans le calcul du CK, rien ne l'empêche!
Au lieu de K = HMAC(sec, uid+mid), cela peut être : K = HMAC(sec, uid+mid+date).
De toutes façons le CL restera le Hash du CK généré, donc n'importe quel serveur pourra hasher le CK pour vérifier le CL.
En revanche, pour les serveurs qui autorisent les posts anonymes, l'utilisation de l'adresse IP n'est pas sûre mais peut être un début de solution (pour identifier l'auteur de l'article). En effet, il faut prendre en compte le fait qu'elle peut être mutualisée (VPN par exemple) ou ne pas être statique.
C'est d'ailleurs pour cette raison que les serveurs qui utilisent cette solution ne proposent les "Cancels/superseedes" que durant 24 heures après la publication de l'article.
L'IP n'est pas un élément permettant d'identifier un utilisateur de manière formelle entre deux dates (puisque entre la publication et l'annulation, cet élément peut changer).
Que ce soit avec une identification formelle (type UID) ou avec autre chose (IP par exemple), cet élément sera VÉRIFIÉ par le serveur et devra être identique entre l'article cancel et celui qui en est la cible.
Plus généralement, il est recommandé de ne pas utiliser un UID qui peut être modifié dans le temps (Par exemple l'entête "From:"). Le login envoyé avec la commande AUTHINFO reste le meilleur moyen d'identifier formellement l'utilisateur puisqu'il ne change jamais.
Je ne vois en réalité pas pourquoi tous les serveurs devraient faire la
même chose pour *générer* CK mais pour le re-calcul du CL à partir du CK
joint à un message, là oui.
Tous les serveurs ne sont pas "obligés" de le faire, la RFC indique simplement un moyen d'authentifier de manière unique un article et son auteur et ces deux informations sont les plus pertinentes.
Après, cela reste de la tambouille interne et effectivement le seul impératif reste la formule de génération du CL.
Franck