Sophos Email: configurar TLS y Secure Message de forma segura

Una Secure Message policy define cómo protege Sophos Email los mensajes y qué ocurre si no se puede usar el método elegido. Para la mayoría de conexiones TLS, Preferred TLS 1.3 es el punto de partida más robusto: Sophos intenta TLS 1.3 y, si es necesario, pasa a TLS 1.2. Solo debe exigirse Required TLS 1.3 o Required TLS 1.2 a socios cuyo sistema emisor o receptor cumpla de forma demostrable ese requisito exacto.

Vía rápida: primero active TLS 1.3 y los cifrados necesarios en su servidor o servicio de correo y pruebe el flujo hacia Sophos. En My Products > Email Security > Policies, cree una policy Secure Message, defina el ámbito interno y, si procede, el externo, elija dirección y método en Settings y aplique Policy is enforced a un grupo piloto pequeño. Para mensajes salientes, decida antes si un fallo TLS permite entrega sin cifrar o debe tratarse con Fallback to push encrypt the entire message. Después compruebe en Message History la versión TLS y el estado de entrega por socio y dirección.

Advertencia: TLS debe estar activo en su propio servidor o servicio de correo antes de configurar cualquier método Secure Message. En particular, su gateway debe admitir TLS 1.3 antes de elegir Required TLS 1.3. De lo contrario puede romperse la conexión con Sophos y detenerse el correo entrante y saliente.

Registrar requisitos y reversión antes del cambio

Esta guía se aplica a Sophos Email en Sophos Fusion (antes Sophos Central), no a Mail Protection ejecutado en una Sophos Firewall. En EMS mode no se pueden configurar Secure Message Policies.

Antes del cambio, registre:

nombre, ámbito, orden, dirección y estado de aplicación actuales de la policy, y cualquier hora de desactivación;
usuarios, grupos o dominios internos y direcciones o dominios externos afectados;
versiones TLS y cifrados de su servidor y de los sistemas piloto;
si el sistema remoto presenta un certificado para su dominio destinatario;
fallback autorizado para cada socio de comunicación;
remitentes, destinatarios, Message-ID, ventana de cambio y responsables de ambas plataformas.

Sophos recomienda TLS 1.3. La cadena de cifrados documentada es exactamente TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 y TLS 1.1 no se admiten para entrega entrante ni saliente desde el 1 de enero de 2024. Por tanto, su servidor no debe estar limitado a esas versiones antiguas.

Para revertir, conserve capturas o datos exportados de la policy anterior. Una policy piloto nueva o clonada puede volver a Policy Bypassed y puede restaurarse el orden previo. No elimine una policy operativa antes de completar todas las pruebas.

Elegir conscientemente el método y el comportamiento ante fallos

TLS: cifrado de transporte en el cliente habitual

Secure using TLS protege la conexión SMTP durante el transporte; remitentes y destinatarios siguen usando su cliente habitual. No significa que el mensaje permanezca en un contenedor cifrado después de entregarse al buzón.

Los niveles TLS tienen consecuencias distintas:

Preferred TLS 1.3 intenta TLS 1.3 y usa TLS 1.2 si el sistema remoto no admite TLS 1.3. Sophos recomienda esta opción flexible porque es menos probable que interrumpa el intercambio.
Required TLS 1.3 solo acepta TLS 1.3. Si el remoto no lo admite, el mensaje no se intercambia mediante otra versión TLS.
Required TLS 1.2 solo acepta TLS 1.2. TLS 1.3 tampoco sustituye a la versión seleccionada en este modo.

Sin esa exigencia, Sophos intenta usar TLS de forma predeterminada cuando la conexión es posible. Este comportamiento oportunista favorece la compatibilidad, pero no garantiza cifrado con todos los socios. Si una versión o verificación de certificado es contractual, asigne al socio un ámbito Required muy limitado y realice una prueba de fallo documentada.

En conexiones salientes con Required TLS 1.3 o Required TLS 1.2 también puede activar Verify certificate. Sophos comprueba entonces que el certificado se emitió para el dominio destinatario. Si falla, no entrega el mensaje. Incluya en External el dominio destinatario real y compruebe qué host y certificado presenta su ruta MX; otro dominio de nombre parecido no sirve.

No confundir Push Encryption o Portal Encryption con TLS

Push Encryption solo está disponible para salida. Sophos convierte el contenido en un documento protegido por contraseña; adjuntos Microsoft Office, ZIP y PDF usan cifrado nativo y otros formatos pueden convertirse a PDF. La primera vez, el destinatario configura una contraseña de Sophos Secure Message desde la notificación, cuyo enlace caduca en 30 días. La contraseña solo vale para mensajes de la misma región que el original. Para la apertura por el destinatario, el uso de la contraseña y las respuestas seguras, consulte Gestionar el cifrado mediante portal y Push de Sophos Email.

Portal Encryption también es solo saliente y requiere una licencia Sophos Email con Portal Encryption Add-on. El destinatario lee y responde en Sophos Secure Message y crea una cuenta con el primer mensaje. Branding, administración de destinatarios, caducidad y recall constituyen otro flujo operativo; este artículo solo selecciona el método en la policy.

Secure using S/MIME requiere CA, certificados de usuarios y destinatarios, y claves privadas previamente configurados. S/MIME puede firmar sin cifrar necesariamente. Aprovisionamiento, confianza, extracción y reset de certificados pertenecen a un procedimiento S/MIME independiente y no se sustituyen con Verify certificate de TLS.

Para TLS saliente hacia un socio sin TLS, Sophos ofrece Allow unencrypted delivery o Fallback to push encrypt the entire message; recomienda Push. Si se configura el fallback Push y falla la negociación TLS, Sophos envía el mensaje mediante Push Encryption en lugar de ponerlo en cola para nuevos intentos TLS. Permita entrega sin cifrar solo si la clasificación de datos lo autoriza expresamente. Push solo es adecuado si los destinatarios pueden abrir documentos protegidos y aceptan el alta inicial. Si no hay fallback autorizado ni negociación TLS, no espere una entrega silenciosa en texto claro.

Crear y limitar la Secure Message policy

Abra My Products > Email Security > Policies y haga clic en Add Policy.
Seleccione Secure Message y Continue. Use un nombre claro, por ejemplo SM-Outbound-Partner-TLS13.
En Internal, añada usuarios, grupos o dominios. Basta una coincidencia en cualquiera de las listas. Pase el cursor sobre un usuario para verificar su dirección.
Para una regla de socio, abra External y añada la dirección o dominio exactos, manualmente o desde un archivo. Compruebe si se incluye o excluye la lista; el valor predeterminado es Include all. La policy se aplica cuando una entrada interna se comunica con una externa.
Abra Settings, elija Inbound u Outbound y active Secure inbound messages o Secure outbound messages.
En Select the method to secure messages, elija el método aprobado. Para TLS, configure Preferred TLS 1.3, Required TLS 1.3 o Required TLS 1.2.
Si se requiere para un socio Required TLS saliente, active Verify certificate. Defina explícitamente el comportamiento de fallback o ante fallos; no lo deduzca del nombre.
Para Push o Portal Encryption, elija el idioma de notificaciones y mensajes de registro enviados al destinatario.
En Choose how to secure, decida si protege todos los mensajes o si el usuario activa la protección con una etiqueta de asunto. La etiqueta fija secure: siempre activa el cifrado, incluso si hay triggers propios. secureTest: o secureFull: deben aparecer completos y exactamente al inicio del asunto; una parte no basta.
Cambie la policy piloto a Policy is enforced, guarde y compruebe su prioridad. Opcionalmente puede fijar fecha y hora de desactivación automática.

Use Clone para ámbitos similares. Un clon empieza en Policy Bypassed, un clon de Base Policy no tiene usuarios, grupos ni dominios, y por defecto tiene prioridad sobre el original. Compruebe ámbito, ajustes y orden antes de Policy is enforced.

Los tenants migrados pueden mostrar policies cuyo nombre empieza por Migrated. Contienen los antiguos ajustes TLS y de cifrado de Global Settings y los usuarios y dominios protegidos al migrar. Pueden editarse, renombrarse, fusionarse o eliminarse, pero solo después de comparar ámbito, método, fallback y prioridad con el estado deseado actual.

Interacción con Data Control

Una acción de cifrado saliente de una policy Data Control anula el método elegido en la Secure Message policy. Si un mensaje usa Push o Portal en lugar de TLS, compruebe ambas policies y las reglas de Data Control aplicables. Compruebe el ámbito y el orden por separado, ya que cada familia cumple otra función.

Validar con destinatarios representativos

Para aceptar el cambio, envíe mensajes controlados y no confidenciales a un destinatario dentro del ámbito y a otro de control fuera. El plan TLS de un socio incluye:

un sistema que admite la versión elegida y, con Verify certificate, presenta un certificado coincidente;
un sistema con TLS 1.2 pero sin TLS 1.3 para probar Preferred TLS 1.3;
una prueba negativa autorizada en la que no se cumple el requisito TLS o de certificado;
con fallback Push, un destinatario que completa notificación, creación de contraseña y apertura;
con etiquetas, un mensaje con trigger exacto, otro incompleto y otro sin trigger.

En Message History, abra Filter a la izquierda, seleccione la categoría Secure message y filtre por versión TLS. Abra el asunto. En Message Details, al pasar por los tres puntos en Status verá si la conexión se protegió con TLS y qué versión se autenticó. Si Sophos no pudo verificar la firma de la CA emisora, SMTP Text indica que la entrega TLS no era de confianza.

Una aceptación correcta registra nombre y prioridad de policy, ámbitos interno y externo, Message-ID, hora, destinatario, método, versión TLS observada, resultado del certificado, fallback y estado final del destinatario. Una entrada en Message History no demuestra por sí sola que el destinatario pudo leer el mensaje.

Investigar fallos TLS, cola y certificados

Si Sophos Email no puede establecer una conexión TLS obligatoria y ningún fallback configurado procesa el mensaje, no envía el correo. Lo mantiene hasta siete días en cola para reentrega y después lo elimina. Cada intento TLS crea una entrada con formato Processing: Check TLS; tras el fallo final, el log registra que el mensaje se eliminó por la TLS policy. No es un método adecuado para probar siete días en producción una configuración Required errónea.

Compruebe en este orden:

¿Está la Secure Message policy esperada en Policy is enforced, con ámbitos correctos y prioridad prevista?
¿Una acción Data Control anula el método o la etiqueta fija secure: activa cifrado?
¿Su servidor y el socio admiten la versión seleccionada? TLS 1.0 y 1.1 no son fallback.
¿Están activos TLS y los cifrados requeridos, en especial TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL?
Con Verify certificate, ¿coincide el certificado con el dominio destinatario real y puede Sophos verificar la CA emisora?
¿Indican Message History, Processing: Check TLS y SMTP Text un error de versión, confianza o negociación?

Si la causa sigue abierta, recopile nombre, ámbito y prioridad de policy, Message-ID, hora, dirección, dominio destinatario, versión esperada y observada, y textos relevantes de History y SMTP para Sophos Email Support. No incluya claves privadas, contraseñas ni contenido confidencial.

Revertir de forma segura

Si el flujo se comporta de forma inesperada, devuelva primero la nueva policy a Policy Bypassed o use la hora de desactivación preparada y restaure la prioridad anterior. Pruebe ambas direcciones y confirme la ruta previa en Message History y en el destinatario. No relaje a la vez versión TLS, verificación de certificado y ámbito, pues ocultaría la causa.

Un fallback temporal a Preferred TLS 1.3, Push Encryption o entrega sin cifrar solo se permite con aprobación explícita del propietario de datos y del cambio. Si se prohíbe texto claro, es mejor retener el mensaje mientras el socio corrige versión TLS, cifrados o cadena del certificado. Amplíe el ámbito o limpie una policy Migrated antigua únicamente tras superar las pruebas piloto y negativas.