STARTTLS est un mécanisme permettant de mettre à niveau une connexion SMTP vers TLS . Il ne précise pas en soi si TLS était requis, si l'homologue était authentifié ou si une négociation échouée pourrait revenir au texte en clair. Ce sont des questions de politique. Une évaluation utile des transports enregistre chacun séparément plutôt que de les réduire à un seul cadenas vert.
Lire la négociation dans l'ordre
Références : RFC 3207 §4.
Un client SMTP établit une connexion, envoie EHLO et lit les extensions du serveur. Une publicité STARTTLS propose la mise à niveau. Lorsque le client le demande et reçoit la réponse de préparation, la négociation TLS commence. Après la prise de contact, l'état SMTP est réinitialisé et le client doit à nouveau émettre EHLO ; les capacités apprises avant TLS ne sont pas simplement reportées. RFC 3207 section 4.
Une transcription contenant le mot STARTTLS ne suffit pas. Identifiez la réponse du serveur, le résultat de la prise de contact et le protocole négocié. Une négociation réussie établit le cryptage sur cette connexion, mais sa force d'authentification dépend de la vérification du certificat et de la politique. Enregistrez pourquoi l'expéditeur a accepté le homologue, et pas seulement quel chiffre a été négocié.
Comprendre les comportements opportunistes
Références : RFC 3207 §6.
TLS opportuniste tente le chiffrement lorsqu'il est disponible sans nécessairement nécessiter TLS authentifié pour chaque destination. La politique de l'expéditeur local peut être plus stricte, évitez donc de supposer que tous les systèmes se comportent de la même manière en cas de panne. L’absence d’une règle d’application universelle est ce qui fait d’une simple capacité STARTTLS une revendication de sécurité limitée.
En particulier, un attaquant actif peut supprimer une publicité STARTTLS sur un chemin autrement non authentifié. Si l'expéditeur n'a aucune exigence indépendante concernant TLS , la publicité manquante peut conduire à une livraison non cryptée. Les algorithmes de chiffrement modernes ne résolvent pas une négociation qui n’atteint jamais TLS . Voir la discussion sur l'attaque dans RFC 3207 section 6.
Ajouter une décision politique authentifiée
Références : RFC 8461 §4, RFC 8461 §5, RFC 7672 §2.2.
Un expéditeur prenant en charge avec une application d'application applicable MTA-STS la politique vérifie les exigences de réception MX et de certificat et ne doit pas livrer en violation de cette politique. Le mode test ne nécessite pas de suspendre la livraison en cas d'échec de la validation MTA-STS ; le signalement des pannes dépend de TLS-RPT étant mis en œuvre par l’expéditeur et le domaine de réception. SMTP DANE utilise sécurisé TLSA découverte et ses règles d'utilisation des certificats pour établir les exigences de transport. N'appelez aucun contrôle actif simplement parce que le domaine de réception a publié quelque chose que l'expéditeur n'a jamais évalué.
Un modèle de décision synthétique utilise une route avec trois entrées : STARTTLS annoncé, poignée de main réussie et homologue accepté selon la politique applicable. Il enregistre une connexion cryptée opportuniste séparément d'une connexion conforme aux règles. Un cas négatif supprime STARTTLS alors que l’application est active et n’attend aucune livraison sur cette route. L'appareil est une illustration de décision, pas une implémentation SMTP ou une capture de paquets.
Signaler avec précision et retester les échecs
Pour une vérification réelle, conservez l'expéditeur, l'adresse IP de destination, l'horodatage, la sélection de l'itinéraire, l'état de la politique et le résultat de la vérification. Une sonde OpenSSL STARTTLS peut inspecter un point de terminaison sélectionné, mais elle ne reproduit pas automatiquement l'envoi. MTA's DNSSEC découverte, cache MTA-STS ou politique de basculement. Suivez un test contrôlé côté expéditeur avec des journaux qui établissent la décision réelle.
Utilisez des formulations telles que connexion chiffrée observée, vérification par un homologue authentifié ou application de l'expéditeur qui a rejeté la route non conforme. Ne prétendez pas que chaque message est protégé parce qu’une connexion a réussi. Le package de révision comprend désormais les transcriptions de bouclage conservées du 7 novembre 2026. Les contrôles réussis enregistrent la préparation pré-TLS EHLO , STARTTLS et post-TLS EHLO . Un test de confiance configuré présente le certificat B tandis que le client fait confiance à A et enregistre l'échec de la vérification du certificat auto-signé ; son contrôle A réussit. Un client TLS obligatoire refuse un serveur sans STARTTLS . Il s'agit de décisions client Python contrôlées par l'historique, et non d'un MTA de production ou d'une implémentation complète MTA-STS / DANE . En particulier, les entrées de confiance et d'association configurées n'établissent pas de chaîne DNSSEC , de découverte de politiques en direct, toutes les contraintes de profil de certificat requises ou de véritables caches d'expéditeur. Non COURRIER DE, la commande RCPT TO ou DATA est envoyée. Les captures ont été inspectées et non réexécutées en tant que tests de réseau pour cet examen. Le nouveau luminaire hors ligne vérifie uniquement son modèle de décision explicitement défini.