Résumé

  • La RFC 8314 recommande TLS implicite pour l’accès et la soumission de courrier : sur les ports 465, 993 ou 995, la négociation TLS commence dès l’établissement de la connexion TCP.
  • Ce choix protège le début du transport. Il ne suffit pas à valider le service attendu, authentifier un utilisateur, lui accorder des droits, accepter son message ou constater sa livraison.

Dans un journal d’assistance, deux lignes se suivaient : « TLS réussi », puis « expéditeur refusé ». L’équipe avait d’abord lu la seconde comme la preuve d’un incident incohérent. En réalité, le serveur avait rempli deux fonctions différentes. Il avait établi un canal protégé, puis appliqué une règle disant que ce compte ne pouvait pas utiliser cette adresse d’enveloppe.

Les interfaces encouragent la confusion. Elles résument par un cadenas une succession d’objets : le nom de service visé, la résolution réseau, le point d’extrémité contacté, la négociation cryptographique, le certificat présenté, l’identité de service validée, le mécanisme d’authentification, l’identité demandée et enfin les droits accordés. Le succès d’une étape rend la suivante possible ; il ne la garantit pas.

Keith Moore et Chris Newman ont publié la RFC 8314 en 2018. Leur recommandation est nette : le trafic entre un agent utilisateur de messagerie et les services d’accès ou de soumission ne devrait plus dépendre d’un transport en clair. Le document préfère TLS implicite à une connexion ouverte sur un port clair, ensuite élevée vers TLS par STARTTLS ou une commande comparable.

Le mot « implicite » décrit le moment où TLS intervient. Pour le service submissions sur le port 465, la négociation TLS suit immédiatement la connexion TCP. C’est également le modèle des ports 993 pour IMAP et 995 pour POP. Le protocole applicatif circule ensuite dans ce canal. Avec STARTTLS, le client commence au contraire par une session applicative en clair, lit les capacités du serveur, demande l’élévation, puis lance la négociation.

Supprimer cette phase préalable réduit une surface de rétrogradation. Cela ne transforme pas le numéro 465 en preuve cryptographique. Un port est un choix de destination. Il ne dit pas à lui seul quel programme écoute, quelle adresse a été résolue, quel certificat est apparu ou si le client a contrôlé le nom qu’il attendait. Un rapport sérieux doit montrer la connexion et la négociation, pas seulement la configuration.

La RFC 8314 tient compte de l’existant. Elle constate le déploiement important de STARTTLS sur le port 587 et recommande de prendre en charge, pendant la transition, 587 avec élévation et 465 avec TLS implicite. Il serait donc faux d’en déduire que toute utilisation de STARTTLS est défectueuse. Le risque dépend notamment de la règle de repli du client.

La RFC 2595 avait défini STARTTLS pour IMAP, POP3 et ACAP. Elle décrit la possibilité qu’un intermédiaire retire la capacité annoncée ou provoque l’échec de la commande. Une attaque ne devient une rétrogradation silencieuse que si le client accepte de poursuivre sans la protection exigée. La preuve utile associe donc la transcription du serveur à la politique locale : TLS était-il obligatoire, et que s’est-il passé lors d’un refus ?

Après la négociation vient la question du nom. La RFC 8314 impose aux clients concernés de mettre en œuvre la validation du certificat. La RFC 9525, plus récente et due à d’autres auteurs, fournit un cadre général pour l’identité des services TLS. Le client construit des identifiants de référence à partir d’une configuration ou d’une entrée fiable, valide le chemin de certification, puis cherche une correspondance avec les identifiants présentés dans le certificat. Un nom intermédiaire obtenu par résolution n’acquiert pas automatiquement le statut d’identité attendue.

Une correspondance valide authentifie le service applicatif dans ce périmètre. Elle n’authentifie pas la personne devant le client. Elle ne prouve pas que le service est exempt de défauts ou autorisé pour toutes les autres ressources. Elle n’accorde aucun droit sur une boîte. Le sujet côté serveur et le sujet côté utilisateur restent deux identités distinctes.

Un certificat client ne fait pas disparaître la limite. La RFC 8314 permet son emploi, tout en laissant le serveur exiger une authentification applicative supplémentaire. Même en présence de TLS mutuel, l’opérateur doit connaître la règle qui associe le certificat à un compte et les permissions attribuées à ce compte. La transcription cryptographique n’est pas, à elle seule, la politique d’autorisation.

SASL nomme cette séparation. La RFC 4422 distingue l’identité d’authentification, liée aux justificatifs présentés, de l’identité d’autorisation sous laquelle le client demande à agir. Le serveur vérifie les justificatifs puis décide si la première peut endosser la seconde. L’échange échoue si l’authentification ou cette décision échoue. L’absence d’une identité d’autorisation distincte signifie généralement « agir comme soi-même » ; elle ne supprime pas le contrôle du serveur.

La soumission ajoute encore des droits propres. La RFC 6409 sépare la soumission du relais et réserve le port 587 à ce service. L’agent de soumission peut n’accepter que des utilisateurs autorisés et refuser un MAIL FROM incompatible avec les droits issus de l’authentification. Avoir rejoint un agent de soumission par TLS identifie un chemin de service ; cela ne préautorise ni l’expéditeur d’enveloppe, ni les destinataires, ni la taille, ni le contenu.

Enfin, l’acceptation par l’agent de soumission n’est pas la livraison. Elle transfère la responsabilité à un stade donné. Le relais ultérieur, la réponse du domaine destinataire, les filtres, le classement dans une boîte et la lecture humaine forment d’autres événements. « Canal protégé », « utilisateur authentifié », « opération autorisée » et « message livré » doivent rester quatre reçus.

Une chaîne vérifiable conserve donc le nom de service configuré et les données de découverte, l’adresse et le port contactés, le mode de démarrage de TLS, la transcription, la version négociée et le certificat. Elle ajoute le chemin de confiance, les identifiants de référence et la correspondance obtenue, puis le mécanisme SASL, les identités d’authentification et d’autorisation, la règle appliquée, la commande et la réponse exacte. La livraison vient après.

L’apport de Newman et Moore n’est pas d’avoir donné tous les pouvoirs à un port. Il est d’avoir placé la protection avant les commandes tout en laissant visibles les décisions qui suivent. TLS implicite peut être le premier acte du protocole ; l’autorisation demeure une décision du service.

Sources