Résumé

  • Après STARTTLS, la connexion persistait mais NNTP revenait presque à l’état suivant le message d’accueil.
  • Le serveur abandonnait le groupe et l’article courants; le client ne pouvait plus se fier aux capacités annoncées en clair.
  • TLS protégeait un lien, sans authentifier automatiquement l’utilisateur NNTP ni toute la chaîne de relais.

Continuité physique, rupture de confiance

RFC 977 décrivait NNTP comme une conversation à état: accueil du serveur, commandes du client, réponses numériques. Avec RFC 4642, une réponse 382 change la nature de l’octet suivant: il appartient à la négociation TLS. La commande ne peut donc pas être mise en pipeline. Si la négociation échoue, fermer la connexion évite de poursuivre dans un état indéterminé.

Lorsqu’elle réussit, aucun nouveau socket n’est nécessaire. Mais le protocole revient à l’instant qui suit l’accueil initial, sans renvoyer cet accueil. Le serveur doit oublier les connaissances acquises du client avant TLS, notamment le groupe et le numéro d’article courants. Le client doit cesser de se fier à ce qu’il a appris du serveur, notamment sa liste de capacités.

La raison est temporelle. Le chiffrement protège l’avenir, pas les déclarations passées. Un attaquant pouvait modifier les échanges en clair. Hériter de ces choix dans la phase protégée aurait donné à un état non authentifié l’autorité du canal sécurisé.

Une capacité est une observation datée

RFC 3977 précise que CAPABILITIES décrit le serveur à l’endroit exact de la session où la commande est envoyée. La réponse peut changer avec l’état. Après TLS, le client interroge donc de nouveau le serveur. STARTTLS disparaît; des mécanismes d’authentification liés à un certificat peuvent apparaître.

Le cache d’une session précédente ne suffit pas pour une décision de sécurité. Un adversaire peut supprimer l’annonce STARTTLS dans la réponse en clair. Le client peut toutefois mémoriser que le serveur offrait auparavant TLS et signaler sa disparition. Il faut oublier l’ancienne liste dans la session, tout en conservant hors session une attente utile contre le déclassement.

L’exception MODE READER montre la précision de la règle: son effet antérieur n’est pas annulé. La réinitialisation ne détruit pas l’histoire au hasard; elle retire aux connaissances sensibles obtenues hors TLS le droit de gouverner la suite.

Le certificat ne confère pas seul un compte

Même si le client présente un certificat pendant TLS, le serveur reste non authentifié au sens applicatif de NNTP. RFC 4643 place ensuite une nouvelle demande de capacités puis une commande AUTHINFO SASL. Le mécanisme EXTERNAL peut exploiter l’identité issue du certificat, mais l’acceptation NNTP demeure un événement distinct.

Cette séparation empêche le transport d’inventer des droits. Le certificat peut lier une identité à une clé; le serveur décide encore des opérations autorisées. Un serveur STARTTLS n’est d’ailleurs pas obligé d’offrir AUTHINFO ou EXTERNAL.

Enfin, TLS n’est pas une preuve de bout en bout. Un article Netnews peut traverser plusieurs serveurs. Chiffrer une paire protège ce seul trajet; authentifier un relais ne prouve ni l’auteur de l’article ni la manière dont ce relais l’a reçu. L’IANA enregistre STARTTLS comme capacité standard de sécurité du transport, non comme certification d’un parcours réel.

NNTP a ainsi conservé la connexion tout en refusant de conserver une certitude mal acquise. La sécurité commençait moins par un cadenas que par une nouvelle question: quels faits ont été établis du bon côté de la frontière?

Sources