Proceso de verificación de TLS para Cisco Email Security

Introducción

En este documento, se describe el proceso de verificación de la identidad del servidor de seguridad de la capa de transporte (TLS) para el dispositivo de seguridad Cisco Email Security Appliance (ESA)

Proceso de verificación de TLS para Cisco Email Security

El proceso de verificación de TLS es básicamente un proceso de validación de dos etapas:

I - VALIDACIÓN DE CERTIFICADOS

Esto implica la verificación de:

• período de validez del certificado - duración del certificado
• emisor de cadena de certificados
• lista de revocación, etc.

II - VALIDACIÓN DE IDENTIDAD DEL SERVIDOR

Este es un proceso de validación de la identidad presentada por el servidor (contenida en el certificado de clave pública X.509) frente a la identidad de referencia del servidor.

Background

Sigamos con la terminología del nombre de identidad descrita en RFC 6125.  

Nota: la identidad presentada es un identificador presentado por un certificado de clave pública X.509 del servidor que puede incluir más de un identificador presentado de diferentes tipos. En el caso del servicio SMTP, se incluye como una extensión subjectAltName de tipo dNSName o como CN (Common Name) derivado del campo subject.

Nota: la identidad de referencia es un identificador construido a partir de un nombre de dominio DNS completo que un cliente espera que un servicio de aplicación presente en el certificado.

El proceso de verificación es principalmente importante para un cliente TLS, ya que en general un cliente inicia una sesión TLS y un cliente necesita autenticar la comunicación. Para lograr esto, un cliente necesita verificar si la identidad presentada coincide con la identidad de referencia. La parte importante es comprender que la seguridad del proceso de verificación de TLS para la entrega de correo se basa casi completamente en el cliente TLS.

Primer paso

El primer paso en la validación de la identidad del servidor es determinar la identidad de referencia por el cliente TLS. Depende de la aplicación qué lista de identificadores de referencia el cliente TLS considere aceptable. Asimismo, debe elaborarse una lista de identificadores de referencia aceptables independientemente de los identificadores presentados por el servicio. [rfs6125#6.2.1]

La identidad de referencia debe ser un nombre de dominio DNS completo y se puede analizar desde cualquier entrada (que es aceptable para un cliente y se considera segura).  La identidad de referencia debe ser un nombre de host DNS al que el cliente está intentando conectarse. 

El nombre de dominio de correo electrónico del destinatario es una identidad de referencia que expresa directamente el usuario, con la intención de enviar un mensaje a un usuario determinado en un dominio determinado y que también cumple el requisito de ser un FQDN al que el usuario está intentando conectarse. Es coherente sólo en el caso de un servidor SMTP autoalojado en el que el mismo propietario es el propietario y el servidor SMTP es el propietario y no aloja demasiados dominios. Como cada dominio debe ser enumerado en el certificado (como uno de subjectAltName: dNSName valores). Desde el punto de vista de la implementación, la mayoría de las autoridades de certificados (CA) limitan el número de nombres de dominio a tan solo 25 entradas (hasta 100). Esto no se acepta en el caso del entorno alojado; pensemos en los proveedores de servicios de correo electrónico (ESP), donde los servidores SMTP de destino alojan miles y más de dominios. Esto simplemente no se escala.

La identidad de referencia explícitamente configurada parece ser la respuesta, pero esto impone algunas limitaciones, ya que es necesario asociar manualmente una identidad de referencia al dominio de origen para cada dominio de destino o "obtener los datos de un servicio de asignación de dominios de terceros en el que un usuario humano ha puesto explícitamente confianza y con el que el cliente se comunica a través de una conexión o asociación que proporciona autenticación mutua y comprobación de integridad". [RFC6125#6.2.1]

Conceptualmente, esto se puede pensar en una "consulta segura MX" única en el momento de la configuración, con el resultado almacenado en caché permanentemente en el MTA para protegerse contra cualquier riesgo de DNS mientras está en estado de ejecución. [2]

Esto proporciona una autenticación más segura solo con dominios "asociados", pero para dominios genéricos que no se han asignado, esto no pasa el examen y tampoco es inmune a los cambios de configuración en el lado del dominio de destino (como los cambios de nombre de host o dirección IP).

“Paso dos”

El siguiente paso en el proceso es determinar una identidad presentada. La identidad presentada es proporcionada por un certificado de clave pública X.509 del servidor, como extensión subjectAltName de tipo dNSName o como Common Name (CN) que se encuentra en el campo subject. Donde es perfectamente aceptable que el campo de asunto esté vacío, siempre y cuando el certificado contenga una extensión subjectAltName que incluya al menos una entrada subjectAltName.

Aunque el uso de Common Name todavía está en la práctica, se considera obsoleto y la recomendación actual es utilizar entradas subjectAltName. La compatibilidad con la identidad de Nombre común se mantiene para la compatibilidad con versiones anteriores. En tal caso, se debe utilizar primero un dNSName de subjectAltName y sólo cuando esté vacío, se activará Common Name (Nombre común).

Nota: el nombre común no tiene establecimiento inflexible de tipos porque un nombre común puede contener una cadena descriptiva para el servicio, en lugar de una cadena cuya forma coincida con la de un nombre de dominio DNS completo

Al final, cuando se han determinado ambos tipos de identidades, el cliente TLS necesita comparar cada uno de sus identificadores de referencia con los identificadores presentados con el fin de encontrar una coincidencia.

Verificación de ESA TLS

El ESA permite habilitar la verificación de certificados y TLS en la entrega a dominios específicos (mediante la página Controles de destino o el comando destconfig CLI). Cuando se requiere la verificación del certificado TLS, puede elegir una de las dos opciones de verificación desde la versión 8.0.2 de AsyncOS. El resultado esperado de la verificación puede variar en función de la opción configurada. A partir de 6 configuraciones diferentes para TLS, disponibles bajo control de destino, hay dos importantes que son responsables de la verificación del certificado:

1. TLS requerido - Verificar
2. TLS requerido: verificar dominios alojados.

CLI: destconfig 

Do you want to use TLS support?

1. No

2. Preferred

3. Required

4. Preferred - Verify

5. Required - Verify

6. Required - Verify Hosted Domains 

[6]> 

Un proceso de verificación de TLS para la opción (4) Preferido - Verificar es idéntico a (5) Requerido - Verificar, pero la acción tomada basada en los resultados difiere según se presenta en la tabla a continuación. Los resultados de la opción (6) Requerido - Verificar dominios alojados es idéntico a (5) Requerido - Verificar pero un flujo de verificación de TLS es muy diferente. 

Configuración de TLS	Significado
4. Preferido (Verificar)	TLS se negocia desde el dispositivo Email Security a los MTA para el dominio. El dispositivo intenta verificar el certificado de dominios. Existen tres resultados posibles: TLS se negocia y se verifica el certificado. El correo se envía a través de una sesión cifrada. TLS se negocia, pero el certificado no se verifica. El correo se envía a través de una sesión cifrada. No se realiza ninguna conexión TLS y, posteriormente, el certificado no se verifica. El mensaje de correo electrónico se envía como texto sin formato.
5. Obligatorio (verificar)	TLS se negocia desde el dispositivo Email Security a los MTA para el dominio. Se requiere la verificación del certificado de dominios. Existen tres resultados posibles: Se negocia una conexión TLS y se verifica el certificado. El mensaje de correo electrónico se envía mediante una sesión cifrada. Se negocia una conexión TLS, pero una CA de confianza no verifica el certificado. El correo no se entrega. Una conexión TLS no se negocia. El correo no se entrega.

La diferencia entre las opciones TLS requerido - Verificar y TLS requerido - Verificar dominio alojado se encuentra en el proceso de verificación de identidad. La forma en que se procesa la identidad presentada y el tipo de identificadores de referencia que se permite utilizar marcan la diferencia en cuanto al resultado final. La finalidad de la descripción que aparece a continuación, así como de todo el documento, es acercar este proceso al usuario final. Como la comprensión incorrecta o poco clara de este tema puede tener un impacto en la seguridad de la red del usuario.

TLS requerido Verificar

La identidad presentada se deriva primero de subjectAltName - extensión dNSName y si no hay coincidencia o la extensión subjectAltName no existe, se marca CN-ID - Common Name from subject.

La lista de identidad de referencia (REF-ID) se construye a partir de un dominio de destinatario o dominio de destinatario y un nombre de host derivado de una consulta DNS PTR ejecutada en la dirección IP a la que está conectado el cliente.  Nota: En este caso concreto, se comparan diferentes identidades de referencia con diferentes comprobaciones de identidad presentadas.

~= representa una coincidencia exacta o comodín

La identidad presentada (dNSName o CN-ID) se compara con las identidades de referencia aceptadas hasta que coincide y en el orden en que se enumeran a continuación. 

• Si existe la extensión dNSName de subjectAltName:
  • la coincidencia exacta o con caracteres comodín se realiza sólo con el dominio del destinatario
    
    La identidad de referencia en caso de coincidencia de subjectAltName se deriva únicamente del dominio del destinatario. Si el dominio del destinatario no coincide con ninguna de las entradas de dNSName, no se comprueba ninguna otra identidad de referencia (como el nombre de host derivado de la resolución de DNS MX o PTR)

• Si CN del DN de asunto existe (CN-ID):
  • se realiza una coincidencia exacta o de comodín con el dominio del destinatario
  • se realiza una coincidencia exacta o de comodín con un nombre de host derivado de una consulta PTR realizada contra una IP del servidor de destino
    
    Donde el registro PTR conserva una coherencia en DNS entre el reenviador y la resolución. Lo que debe mencionarse aquí, ese campo CN se compara con un nombre de host de PTR sólo cuando existe un registro PTR y un registro A resuelto (un reenviador) para este nombre de host (identidad de referencia) devuelve una dirección IP que coincide con una IP de servidor de destino con la que se realizó una consulta PTR.
    
    A(PTR(IP)) == IP
    
    La identidad de referencia en el caso de CN-ID se deriva del dominio del destinatario y cuando no hay coincidencia, se realiza una consulta DNS contra un registro PTR de IP de destino para obtener un nombre de host. Si existe un PTR, se realiza una consulta adicional en un registro A de un nombre de host derivado de un PTR para confirmar que se conserva la coherencia de DNS. No se comprueban más referencias (como el nombre de host derivado de la consulta MX)

Para resumir, con la opción 'TLS requerido - Verificar' no hay un nombre de host MX comparado con dNSName o CN, un DNS PTR RR se verifica solamente para CN y se compara solamente si se conserva la consistencia DNS A(PTR(IP)) = IP, se realizan pruebas exactas y de comodines para dNSName y CN.

TLS requerido Verificar - Dominio alojado

La identidad presentada se deriva primero de la extensión subjectAltName de tipo dNSName. Si no hay ninguna coincidencia entre el nombre dNSN y una de las identidades de referencia aceptadas (REF-ID), la verificación no se realiza con independencia de si existe CN en el campo de asunto y podría pasar otra verificación de identidad. El CN derivado del campo de asunto se valida sólo cuando el certificado no contiene ninguna extensión subjectAltName de tipo dNSName.

Recuerde que la identidad presentada (dNSName o CN-ID) se compara con las identidades de referencia aceptadas hasta que coincide y en el orden en que se enumeran a continuación. 

• Si existe la extensión dNSName de subjectAltName:
  
  Si no hay ninguna coincidencia entre el nombreDNS y una de las identidades de referencia aceptadas enumeradas a continuación, se produce un error en la validación de la identidad
   
  • coincidencia exacta o de comodín con el dominio de destinatario: uno de los dNSName debe coincidir con un dominio de destinatario
  • se realiza una coincidencia exacta o de comodín con un nombre de host configurado explícitamente con SMTPROUTES (*)
  • se realiza una coincidencia exacta o de comodín con el nombre de host MX derivado de una consulta DNS (insegura) con el nombre de dominio del destinatario
    
    Si el dominio de destinatario no tiene configurada explícitamente la ruta SMTP con entradas FQDN y el dominio de destinatario no coincide, se utiliza un FQDN devuelto por un registro MX de una consulta DNS (no segura) en un dominio de destinatario. Si no hay coincidencia, no se realizan más pruebas, no se verifica ningún registro PTR 
• Si CN del DN de asunto existe (CN-ID):

  
  CN se valida sólo cuando dNSName no existe en el certificado. El CN-ID se compara con la siguiente lista de identidades de referencia aceptadas.
  
  

  • se realiza una coincidencia exacta o de comodín con el dominio del destinatario
  • se realiza una coincidencia exacta o de comodín con un nombre de host configurado explícitamente en SMTPROUTES (*)
  • se realiza una coincidencia exacta o de comodín con el nombre de host MX derivado de una consulta DNS (insegura) con el nombre de dominio del destinatario

SMTPROUTES configurados explícitamente

Cuando se configura la ruta SMTP y la identidad presentada no coincide con el dominio del destinatario de correo electrónico, se comparan todos los nombres de rutas FQDN y, si no coinciden, no se realizan más comprobaciones. Con rutas SMTP explícitamente configuradas, no se considera que ningún nombre de host MX se compare con una identidad presentada. La excepción aquí hace una ruta SMTP que fue establecida como una dirección IP.

Las siguientes reglas se aplican en el caso de rutas SMTP explícitamente configuradas:

• Cuando existe una ruta SMTP para un dominio de destinatario y es un nombre de dominio DNS (FQDN) completo, se considera una identidad de referencia. Este nombre de host (un nombre de ruta) se compara con la identidad presentada recibida de un certificado derivado de un servidor de destino al que apunta.

• Se permiten varias rutas para un dominio de destinatario. Si el dominio de destinatario tiene más de una ruta SMTP, las rutas se procesan hasta que los identificadores presentados del certificado del servidor de destino coincidan con el nombre de la ruta con la que se estableció la conexión. Si los hosts de la lista tienen prioridades diferentes, se procesan primero los que tienen las más altas (0 es la más alta y el valor predeterminado). Si todas tienen la misma prioridad, la lista de rutas se procesa en el orden en que el usuario estableció las rutas.

• En caso de que el host no responda (no esté disponible) o responda pero la verificación de TLS haya fallado, se procesará el siguiente host de la lista. Cuando el primer host está disponible y pasa la verificación, los demás no se utilizan.

• Si varias rutas se resuelven en las mismas direcciones IP, solo se establece una conexión con esta IP y la identidad presentada derivada del certificado enviado por el servidor de destino debe coincidir con uno de estos nombres de rutas.

• Si existe una ruta SMTP para dominios de destinatario pero se ha configurado como dirección IP, la ruta se seguirá usando para establecer una conexión, pero se comparará una identidad presentada del certificado con el dominio de destinatario y, además, con el nombre de host derivado del registro de recursos DNS/MX.

Cuando hablamos de la opción TLS Required Verify para dominios alojados, la forma en que ESA se ha conectado con un servidor de destino es importante para el proceso de verificación de TLS debido a las rutas SMTP explícitamente configuradas que proporcionan una identidad de referencia adicional que se debe considerar en el proceso.

~= representa una coincidencia exacta o comodín

Ejemplo:

Tomemos un ejemplo de la vida real, pero para el dominio del destinatario: example.com. A continuación, traté de describir todos los pasos necesarios para verificar manualmente la identidad del servidor. 

example.com -> IN MX mx01.subd.emailhosted.not.
example.com -> IN MX mx02.subd.emailhosted.not.

mx01.subd.emailhosted.not. -> IN A 192.0.2.1
mx02.subd.emailhosted.not. -> IN A 192.0.2.2

192.0.2.1 -> IN PTR mx0a.emailhosted.not.
192.0.2.2 -> IN PTR mx0b.emailhosted.not.

mx0a.emailhosted.not. -> IN A 192.0.2.1
mx0b.emailhosted.not. -> IN A 192.0.2.2

Nota: los nombres de host MX y los nombres revDNS no coinciden en este caso

$ echo QUIT |openssl s_client -connect mx0a.emailhosted.not:25 -starttls smtp 2>/dev/null| openssl x509 -text | grep -iEo 'DNS:.*|CN=.*'

CN=thawte SHA256 SSL CA
CN=*.emailhosted.not
DNS:*.emailhosted.not, DNS:emailhosted.not 

echo QUIT |openssl s_client -connect mx0b.emailhosted.not:25 -starttls smtp 2>/dev/null| openssl x509 -text | grep -iEo 'DNS:.*|CN=.*'

CN=thawte SHA256 SSL CA
CN=*.emailhosted.not
DNS:*.emailhosted.not, DNS:emailhosted.not   

•   identidad presentada: dNSName exist (continuar con la comparación con la identidad de referencia permitida)
  
  
  • la identidad de referencia = dominio de destinatario (ejemplo.com) está marcada y no coincide con el nombre DNS de dNSN:*.emailhost.not, DNS:emailhost.not
•   identidad presentada: CN existe (continuar con la siguiente identidad presentada ya que para la anterior no hubo coincidencia)
  
  
  • la identidad de referencia = dominio de destinatario (example.com) está marcada y no coincide con el CN *.emailhospedado.not
    
    
  • identidad de referencia = PTR(IP): se realiza una consulta PTR contra la IP del servidor al que el cliente TLS (ESA) ha establecido la conexión y ha recibido un certificado, y esta consulta devuelve: mx0a.emailhospedado.not.
    
    
    • Se verifica la consistencia de DNS para considerar este nombre de host como identidad de referencia válida:
      
      
      Existe coherencia: A(PTR(IP)) = IP
      
      

      mx01.subd.emailhosted.not. -> IN A 192.0.2.1
      
      PTR(IP):      192.0.2.1  -> IN PTR  mx0a.emailhosted.not.
      A(PTR(IP)):   mx0a.emailhosted.not. -> IN A 192.0.2.1
      

    • El valor de mx0a.emailhost.not. se compara con CN *.emailhost.not y allí coincide.

El nombre de dominio PTR valida la identidad y, como el certificado es un certificado firmado por la CA, valida todo el certificado y se establece la sesión TLS.

• identidad presentada: dNSName exist (por lo que el CN no se procesará en ese caso)
  • identidad de referencia = dominio de destinatario (example.com) se comprueba y
    no coincide con dNSName DNS:*.emailhost.not, DNS:emailhost.not
  • reference identity = FQDN (ruta smtp): no hay rutas smtp para este dominio de destinatario 
    
    Como no hay SMTPROUTES utilizados adicionalmente:
    
    
  • identidad de referencia = MX(dominio de destinatario) - se realiza una consulta DNS MX contra el dominio de destinatario
    y devuelve: mx01.subd.emailhospedado.not - esto no coincide con el nombre de DNS de dNSN:*.emailhospedado.not, DNS:emailhospedado.not
• identidad presentada: CN existe pero se omite porque dNSName existe también.