Transport TLS et S/MIME résolvent différents problèmes. TLS protège une connexion entre des systèmes adjacents. S/MIME peut signer ou chiffrer le contenu du message afin que la protection accompagne le message. Que cela soit réellement de bout en bout dépend de l'endroit où les clés sont conservées et de l'endroit où la signature ou le déchiffrement a lieu, et pas seulement du fait qu'un client de messagerie affiche une icône de sécurité.
Tracez le chemin avant de choisir un contrôle
Références : RFC 3207 §1, RFC 8551 §1.
Utilisez un message du client d'Alice vers son service de soumission, puis une passerelle sortante, le service MX du destinataire et la boîte aux lettres et le client de Bob. Chaque tronçon de réseau peut avoir sa propre connexion et politique TLS . Une connexion SMTP TLS inter-domaines réussie ne dit rien en soi sur la soumission, les relais internes, l'accès à la boîte aux lettres ou le cryptage du stockage.
Sur chaque serveur qui termine TLS , le contenu du message ordinaire est disponible pour le traitement à moins qu'il ne soit chiffré séparément. Les filtres, les passerelles et les points finaux compromis restent donc partie intégrante de la frontière de confidentialité. MTA-STS et SMTP DANE améliorer l'authentification et l'application des règles de transport pour leurs itinéraires applicables ; ni l’un ni l’autre ne transforme TLS saut par saut en cryptage de message. RFC 8461 section 2.
Distinguer la signature du chiffrement
Références : RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
Le contenu signé S/MIME fournit des preuves d'intégrité et d'authentification du signataire conformément à la confiance et à la validation du certificat. Signer seul ne cache pas le message. Le contenu enveloppé S/MIME chiffre le matériel protégé pour les destinataires dont les clés peuvent le déchiffrer ; Le cryptage seul n’équivaut pas à une signature d’auteur vérifiée. Le contenu enveloppé authentifié peut en outre assurer la confidentialité et l'intégrité des données sans prouver l'origine, comme l'explique RFC 8551 §3.4. N’assimilez pas cette protection à une signature d’auteur vérifiée. Un workflow peut combiner signature et chiffrement. RFC 8551 sections 2 et 3.
Les clés et les identités de certificat nécessitent une gestion du cycle de vie. Confirmez qui peut accéder aux clés privées, comment les destinataires obtiennent les certificats, comment les clés expirées ou perdues affectent l'accès au courrier archivé et quel processus de récupération est autorisé. Ce sont des questions de conception opérationnelle, et non des raisons de distribuer largement les clés privées ou de supposer qu'une vérification d'authentification de domaine remplace la validation de certificat.
Comparez les menaces sur le même message
Références : RFC 8551 §3.1, RFC 8551 §6.
Pour l'observation passive d'un saut SMTP correctement chiffré, TLS protège les octets transmis sur ce saut. Pour un administrateur de passerelle lisant le courrier après la terminaison TLS , le chiffrement par sauts ne fournit aucune barrière de confidentialité du contenu. Le chiffrement S/MIME côté client peut protéger le corps chiffré de cette passerelle s'il ne contient pas de clé de déchiffrement. Le mot peut être important car certains déploiements déchiffrent intentionnellement au niveau des passerelles.
En cas de modification après transport, une signature S/MIME valide peut exposer les modifications apportées au contenu signé ; le fait qu'une connexion TLS antérieure ait réussi ne le peut pas. Pour un client destinataire compromis disposant de la clé de déchiffrement, ni le chiffrement TLS ni S/MIME n’empêche le client d’accéder au texte en clair. Pour les métadonnées de routage visibles et les en-têtes externes, ne promettez pas une dissimulation complète : la couverture dépend de l’empaquetage et de la mise en œuvre du message.
Les preuves de l’examen privé contiennent une matrice explicite de cheminement et de menace décrivant ces limites. Il s’agit d’un modèle de conception et non d’un test d’interopérabilité cryptographique. Le local TLSA les éléments de certificat ailleurs dans le package n'établissent pas de comportement de signature ou de déchiffrement S/MIME .
Choisissez ensemble les contrôles et les preuves d’acceptation
Références : RFC 8551 §4, RFC 8551 §6.
Spécifiez quels sauts nécessitent l'application TLS , quel contenu nécessite une signature ou un chiffrement et où le déchiffrement est autorisé. Testez les clients représentatifs, les pièces jointes, le transfert et l’accès aux archives dans un environnement contrôlé. Conservez à la fois les cas de vérification positive et les cas de contenu modifié négatif avant de prétendre que le flux de travail préserve les signatures ou la confidentialité sur un itinéraire particulier.
Garder hameçonnage et les revendications de processus métier sont séparées. Un expéditeur authentifié ou un message signé peut toujours contenir une demande de paiement erronée ou frauduleuse, notamment après une compromission du compte. Une vérification indépendante des actions consécutives reste nécessaire. Aucun message S/MIME n'a été signé, chiffré, livré ou déchiffré pour ce guide ; sa preuve est la matrice inspectable contrôle-menace, et l’interopérabilité des clients reste une tâche d’acceptation explicitement en attente.