Résumé

  • STARTTLS a inséré une négociation TLS dans une connexion SMTP existante, mais sans conserver l’autorité de la première conversation : après la poignée de main, les deux parties effacent l’état appris en clair et le client envoie un nouvel EHLO.
  • Cette remise à zéro sépare deux contextes de confiance. Elle ne rend ni le chiffrement obligatoire ni le courrier authentifié de bout en bout ; DANE et MTA-STS ont ensuite placé la règle anti-repli hors du dialogue modifiable.

Deux débuts dans une seule connexion

Le serveur SMTP accueille le client par 220. Le client répond par EHLO, et le serveur énumère les extensions disponibles. En 1999, STARTTLS s’est glissé dans cette grammaire sans créer un second système de routage du courrier : un mot sans paramètre dans la réponse EHLO indiquait la possibilité de négocier TLS.

Le client envoyait STARTTLS, le serveur répondait 220, puis les octets suivants appartenaient à la poignée de main TLS. Cette continuité facilitait le déploiement : les anciens clients continuaient leur échange, les nouveaux découvraient le chiffrement sur le port déjà désigné par MX.

Or la découverte précédait la protection. Un adversaire placé sur le chemin pouvait modifier le premier EHLO, altérer une capacité ou supprimer l’annonce STARTTLS. La première moitié de la connexion permettait d’atteindre la frontière cryptographique ; elle ne pouvait servir de preuve à l’intérieur de cette frontière.

Le chiffrement exigeait d’oublier

Après une poignée de main réussie, le protocole SMTP revient donc à son état initial. Le serveur abandonne le nom appris dans le premier EHLO ; le client abandonne la première liste d’extensions. Le client salue de nouveau le serveur.

Ce deuxième EHLO n’est pas une politesse redondante. Il est prononcé dans un autre contexte. Le serveur peut, par exemple, n’annoncer certains mécanismes d’authentification qu’après avoir reçu un certificat client approprié. Le client peut refuser des fonctions dont l’autorité dépendait uniquement d’octets lus avant TLS.

La coupure est aussi syntaxique. Une fois le 220 reçu, aucune autre commande SMTP ne doit précéder la négociation TLS. Dans un groupe pipeliné, STARTTLS vient en dernier. Sans cette règle, une commande en clair pourrait être interprétée comme le début de TLS, ou une décision fondée sur l’ancien état entrer dans le nouveau.

Un canal protégé n’est pas encore un verdict

TLS peut apporter confidentialité, intégrité et authentification, mais le succès technique de la poignée de main ne fixe pas à lui seul le niveau acceptable. Le nom attendu dans le certificat, les autorités de confiance, les algorithmes et les identités clientes restent des décisions locales. Chaque partie peut interrompre la session si le résultat ne suffit pas.

Cette autonomie évite de transformer l’icône d’un cadenas en certificat universel. Chiffrer contre l’écoute passive ne prouve pas toujours que le serveur contacté est le MX voulu. Authentifier un relais n’authentifie pas l’auteur humain. Protéger un saut ne protège ni le saut précédent ni le suivant.

La réponse 454 rend ce choix visible : lorsque TLS est temporairement indisponible, l’émetteur peut livrer en clair, remettre le message en file d’attente ou signaler un échec. Le mécanisme ne décide pas à sa place de la valeur du secret transporté.

L’interopérabilité borna le premier mandat

Le courrier public devait continuer à accepter les expéditeurs non modernisés. RFC 3207 interdit donc à un serveur SMTP publiquement référencé sur le port 25 d’exiger STARTTLS uniquement pour une livraison locale. Un serveur privé ou une politique de relais peut être plus stricte, notamment lorsqu’une authentification TLS autorise le relais.

Ce compromis a permis une migration progressive. Il a aussi laissé l’annonce STARTTLS sans mémoire obligatoire. Si un attaquant supprimait la ligne, un client opportuniste pouvait croire que le serveur ne proposait jamais TLS et livrer en clair.

Le défaut n’était pas dans le chiffrement négocié. Il résidait dans une obligation de chiffrement annoncée à l’intérieur du dialogue que l’attaquant pouvait précisément modifier.

DANE et MTA-STS ont déplacé la politique

DANE pour SMTP publie, sous protection DNSSEC, des enregistrements TLSA associés aux serveurs de destination. Une preuve TLSA sûre signifie à la fois qu’un canal TLS est attendu et comment authentifier le pair. L’absence apparente de STARTTLS n’autorise alors plus la livraison : le message attend.

MTA-STS suit un autre chemin de confiance. Le domaine destinataire signale une politique, la sert par HTTPS et permet à l’émetteur de mettre en cache les hôtes MX admis, l’exigence PKIX et une durée. Tant que cette politique s’applique, une annonce supprimée ou un certificat invalide entraîne une mise en file, non un repli silencieux. La première découverte conserve une exposition particulière que DANE réduit grâce à DNSSEC.

STARTTLS demeure le passage dans le canal. Ces politiques répondent à une question différente : qui a autorité pour accepter l’absence de ce passage ?

La vraie invention fut la seconde salutation

STARTTLS est souvent résumé comme le moment où le texte devient chiffré. Son apport plus durable est l’expiration explicite de l’ancien état. Les affirmations reçues avant la protection ne sont pas sanctifiées après coup. Les capacités sont redécouvertes, l’identité est évaluée par une politique nommée et le repli devient une décision observable.

Toute sécurité ajoutée à un protocole ancien rencontre le même problème. Une couche cryptographique nouvelle ne lave pas les choix déjà faits sur des données modifiables. Il faut dire ce qui survit à la frontière, ce qui disparaît et qui peut autoriser un niveau plus faible.

Sources et limites

La conception initiale et l’avertissement sur le retrait de l’annonce figurent dans RFC 2487. Les règles révisées, la remise à zéro et la limite d’interopérabilité viennent de RFC 3207. RFC 7672 définit DANE pour SMTP, et RFC 8461 MTA-STS. Ces textes ne mesurent ni le déploiement actuel ni la fréquence mondiale des attaques.