Transport TLS y S/MIME resuelven diferentes problemas. TLS protege una conexión entre sistemas adyacentes. S/MIME puede firmar o cifrar el contenido del mensaje para que la protección viaje con el mensaje. Que esto sea realmente de extremo a extremo depende de dónde se guardan las claves y dónde se realiza la firma o el descifrado, no simplemente si un cliente de correo electrónico muestra un ícono de seguridad.
Dibuja el camino antes de elegir un control.
Referencias: RFC 3207 §1, RFC 8551 §1.
Utilice un mensaje del cliente de Alice a su servicio de envío, luego una puerta de enlace de salida, el servicio MX del destinatario y el buzón y el cliente de Bob. Cada salto de red puede tener su propia conexión y política TLS . Una conexión SMTP TLS entre dominios exitosa no dice nada por sí sola sobre el envío, las retransmisiones internas, el acceso al buzón o el cifrado del almacenamiento.
En cada servidor que termina TLS , el contenido del mensaje ordinario está disponible para su procesamiento a menos que esté cifrado por separado. Por lo tanto, los filtros, puertas de enlace y puntos finales comprometidos siguen siendo parte del límite de confidencialidad. MTA-STS y SMTP DANE mejorar la autenticación y el cumplimiento del transporte para sus rutas aplicables; ninguno de los dos transforma TLS salto a salto en cifrado de mensajes. RFC 8461 sección 2.
Distinguir la firma del cifrado
Referencias: RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
El contenido firmado S/MIME proporciona evidencia de integridad y autenticación del firmante de acuerdo con la confianza y validación del certificado. La firma por sí sola no oculta el mensaje. El contenido envuelto S/MIME cifra el material protegido para los destinatarios cuyas claves pueden descifrarlo; el cifrado por sí solo no equivale a la firma de un autor verificado. El contenido envuelto autenticado también puede proporcionar confidencialidad e integridad de los datos sin demostrar su origen, como explica RFC 8551 §3.4. No equipare esa protección con la firma de un autor verificado. Un flujo de trabajo puede combinar firma y cifrado. RFC 8551 secciones 2 y 3.
Las claves y las identidades de los certificados necesitan gestión del ciclo de vida. Confirme quién puede acceder a las claves privadas, cómo los destinatarios obtienen los certificados, cómo las claves vencidas o perdidas afectan el acceso al correo archivado y qué proceso de recuperación está autorizado. Esas son preguntas de diseño operativo, no razones para distribuir claves privadas ampliamente o asumir que una verificación de autenticación de dominio reemplaza la validación de certificados.
Compara amenazas en el mismo mensaje
Referencias: RFC 8551 §3.1, RFC 8551 §6.
Para la observación pasiva de un salto SMTP correctamente cifrado, TLS protege los bytes transmitidos en ese salto. Para un administrador de puerta de enlace que lee el correo después de la terminación TLS , el cifrado de saltos no proporciona ninguna barrera de confidencialidad del contenido. El cifrado S/MIME del lado del cliente puede proteger el cuerpo cifrado de esa puerta de enlace si no posee una clave de descifrado. La palabra puede ser importante porque algunas implementaciones descifran intencionalmente en las puertas de enlace.
Para modificaciones después del transporte, una firma S/MIME válida puede exponer cambios en el contenido firmado; el hecho de que una conexión TLS anterior haya tenido éxito no puede hacerlo. Para un cliente destinatario comprometido que tiene la clave de descifrado, ni el cifrado TLS ni S/MIME impiden que el cliente acceda al texto sin formato. Para los metadatos de enrutamiento visibles y los encabezados externos, no prometa una ocultación total: la cobertura depende del empaquetado y la implementación del mensaje.
La evidencia de la revisión privada contiene una matriz explícita de rutas y amenazas que describe estos límites. Es un modelo de diseño, no una prueba de interoperabilidad criptográfica. el local TLSA Los elementos adjuntos del certificado en otras partes del paquete no establecen un comportamiento de firma o descifrado S/MIME .
Elija controles y pruebas de aceptación juntos
Referencias: RFC 8551 §4, RFC 8551 §6.
Especifique qué saltos necesitan TLS aplicado, qué contenido necesita firma o cifrado y dónde se permite el descifrado. Pruebe clientes representativos, archivos adjuntos, reenvío y acceso a archivos en un entorno controlado. Conserve tanto los casos de verificación positiva como los negativos de contenido alterado antes de afirmar que el flujo de trabajo preserva las firmas o la confidencialidad en una ruta particular.
Mantener phishing y los reclamos de procesos comerciales separados. Un remitente autenticado o un mensaje firmado aún pueden contener una solicitud de pago errónea o fraudulenta, especialmente después de que la cuenta se vea comprometida. Sigue siendo necesaria una verificación independiente de las acciones consiguientes. No se firmó, cifró, entregó ni descifró ningún mensaje S/MIME para esta guía; su evidencia es la matriz inspeccionable de control-amenaza, y la interoperabilidad del cliente sigue siendo una tarea de aceptación explícitamente pendiente.