Processo de verificação TLS para Cisco Email Security

Introdução

Este documento descreve o processo de verificação de identidade do servidor Transport Layer Security (TLS) para o Cisco Email Security Appliance (ESA)

Processo de verificação TLS para Cisco Email Security

O processo de verificação TLS é essencialmente um processo de validação de duas etapas:

I - VALIDAÇÃO DO CERTIFICADO

Isso envolve a verificação de:

• período de validade do certificado - tempo de vida do certificado
• emissor de cadeia de certificado
• lista de revogação, etc. ..

II - VALIDAÇÃO DA IDENTIDADE DO SERVIDOR

Este é um processo de validação da identidade apresentada pelo servidor (contida no certificado de chave pública X.509) contra a identidade de referência do servidor.

Background

Vamos manter a terminologia de nome de identidade descrita no RFC 6125.  

Observação: a identidade apresentada é um identificador apresentado por um certificado de chave pública X.509 de servidor que pode incluir mais de um identificador apresentado de diferentes tipos. No caso do serviço SMTP, ele está contido como uma extensão subjectAltName do tipo dNSName ou como o CN (Nome Comum) derivado do campo assunto.

Observação: a identidade de referência é um identificador construído a partir de um nome de domínio DNS totalmente qualificado que um cliente espera que um serviço de aplicativo apresente no certificado.

O processo de verificação é importante principalmente para um cliente TLS, pois, em geral, um cliente inicia uma sessão TLS e precisa autenticar a comunicação. Para conseguir isso, um cliente precisa verificar se a identidade apresentada corresponde à identidade de referência. A parte importante é entender que a segurança do processo de verificação TLS para entrega de e-mail é quase inteiramente baseada no cliente TLS.

Etapa um

A primeira etapa na validação da identidade do servidor é determinar a identidade de referência pelo cliente TLS. Depende do aplicativo qual lista de identificadores de referência o cliente TLS considera aceitável. Além disso, deve ser elaborada uma lista de identificadores de referência aceitáveis, independentemente dos identificadores apresentados pelo serviço. [rfs6125#6.2.1]

A identidade de referência deve ser um nome de domínio DNS totalmente qualificado e pode ser analisada a partir de qualquer entrada (o que é aceitável para um cliente e considerado seguro).  A identidade de referência precisa ser um nome de host DNS ao qual o cliente está tentando se conectar. 

O nome de domínio do e-mail do destinatário é uma identidade de referência que é expressa diretamente pelo usuário, pela intenção de enviar uma mensagem a um usuário específico em um domínio específico e isso também atendeu a um requisito de ser um FQDN ao qual um usuário está tentando se conectar. Ele é consistente apenas no caso de um servidor SMTP auto-hospedado em que o servidor SMTP é de propriedade e gerenciado pelo mesmo proprietário e o servidor não está hospedando muitos domínios. Como cada domínio precisa ser listado no certificado (como um dos valores subjectAltName: dNSName). De uma perspectiva de implementação, a maioria das Autoridades de Certificação (CA) limita o número de nomes de domínio a até 25 entradas (até 100). Isso não é aceito no caso do ambiente hospedado, vamos pensar em provedores de serviços de e-mail (ESP) onde os servidores SMTP de destino hospedam milhares e mais de domínios. Isso simplesmente não é escalável.

A identidade de referência explicitamente configurada parece ser a resposta, mas isso impõe algumas restrições, pois é necessário associar manualmente uma identidade de referência ao domínio de origem para cada domínio de destino ou "obter os dados de um serviço de mapeamento de domínio de terceiros no qual um usuário humano tenha explicitamente colocado confiança e com o qual o cliente se comunica através de uma conexão ou associação que fornece tanto autenticação mútua e verificação de integridade". [RFC6125#6.2.1]

Conceitualmente, isso pode ser pensado em uma única "consulta MX segura" no momento da configuração, com o resultado armazenado em cache permanentemente no MTA para proteger contra qualquer comprometimento de DNS enquanto em estado de execução. [2]

Isso fornece uma autenticação mais forte apenas com domínios "parceiros", mas para o domínio genérico que não foi mapeado isso não passa no exame e isso também não é imune a alterações de configuração no lado do domínio de destino (como alterações de nome de host ou endereço IP).

Etapa dois:

A próxima etapa no processo é determinar uma identidade apresentada. A identidade apresentada é fornecida por um certificado de chave pública X.509 do servidor, como a extensão subjectAltName do tipo dNSName ou como Nome Comum (CN) encontrado no campo assunto. Onde for perfeitamente aceitável que o campo assunto fique vazio, desde que o certificado contenha uma extensão subjectAltName que inclua pelo menos uma entrada subjectAltName.

Embora o uso de Nome comum ainda esteja na prática, ele é considerado obsoleto e a recomendação atual é usar entradas subjectAltName. O suporte para a identidade do Nome Comum permanece para compatibilidade com versões anteriores. Nesse caso, um dNSName de subjectAltName deve ser usado primeiro e somente quando estiver vazio, o Nome comum será verificado.

Observação: o nome comum não é digitado com segurança porque um nome comum pode conter uma cadeia de caracteres amigável para o serviço, em vez de uma cadeia de caracteres cujo formato corresponda ao de um nome de domínio DNS totalmente qualificado

No final, quando ambos os tipos de identidades tiverem sido determinados, o cliente TLS precisa comparar cada um de seus identificadores de referência com os identificadores apresentados com a finalidade de encontrar uma correspondência.

Verificação TLS ESA

O ESA permite habilitar TLS e verificação de certificado na entrega para domínios específicos (usando a página de controles de destino ou o comando CLI destconfig). Quando a verificação do certificado TLS é necessária, você pode escolher uma das duas opções de verificação desde a versão 8.0.2 do AsyncOS. O resultado de verificação esperado pode variar dependendo da opção configurada. De 6 configurações diferentes para TLS, disponíveis sob controle de destino, há duas importantes responsáveis pela verificação do certificado:

1. TLS necessário - Verificar
2. TLS necessário - Verificar domínios hospedados.

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]> 

Um processo de verificação TLS para a opção (4) Preferred - Verify é idêntico a (5) Required - Verify, mas a ação tomada com base nos resultados difere conforme apresentado na tabela abaixo. Os resultados da opção (6) Obrigatório - Verificar domínios hospedados são idênticos a (5) Obrigatório - Verificar, mas um fluxo de verificação TLS é bem diferente. 

Configurações de TLS	Significado
4. Preferencial (Verificar)	O TLS é negociado do dispositivo Email Security para o(s) MTA(s) do domínio. O equipamento tenta verificar o certificado dos domínios. Três resultados são possíveis: O TLS é negociado e o certificado é verificado. O e-mail é entregue por meio de uma sessão criptografada. O TLS é negociado, mas o certificado não é verificado. O e-mail é entregue por meio de uma sessão criptografada. Nenhuma conexão TLS é feita e, subsequentemente, o certificado não é verificado. A mensagem de e-mail é entregue em texto simples.
5. Obrigatório (Verificar)	O TLS é negociado do dispositivo Email Security para o(s) MTA(s) do domínio. A verificação do certificado de domínios é necessária. Três resultados são possíveis: Uma conexão TLS é negociada e o certificado é verificado. A mensagem de e-mail é entregue por meio de uma sessão criptografada. Uma conexão TLS é negociada, mas o certificado não é verificado por uma CA confiável. O e-mail não foi entregue. Uma conexão TLS não é negociada. O e-mail não foi entregue.

A diferença entre as opções TLS Obrigatório - Verificar e TLS Obrigatório - Verificar Domínio Hospedado está no processo de verificação de identidade. A forma como a identidade apresentada é processada e que tipo de identificadores de referência podem ser usados faz uma diferença sobre um resultado final. A finalidade da descrição abaixo, assim como do documento inteiro, é aproximar esse processo ao usuário final. Como a compreensão incorreta ou incerta desse assunto pode ter um impacto na segurança da rede do usuário.

Verificação de TLS Necessária

A identidade apresentada é derivada primeiro da extensão subjectAltName - dNSName e se não houver correspondência ou se a extensão subjectAltName não existir em comparação com CN-ID - Nome comum do campo de assunto está marcado.

A lista de identidade de referência (REF-ID) é construída a partir de um domínio de destinatário ou domínio de destinatário e nome de host derivados de uma consulta PTR DNS executada em relação ao endereço IP ao qual o cliente está conectado.  Nota: Nesse caso específico, são comparadas identidades de referência diferentes com diferentes controlos de identidade apresentados.

~= representa correspondência exata ou curinga

A identidade apresentada (dNSName ou CN-ID) é comparada com as identidades de referência aceitas até que seja correspondida e na ordem em que são listadas abaixo. 

• Se a extensão dNSName de subjectAltName existir:
  • a correspondência exata ou curinga é feita apenas no domínio do destinatário
    
    A identidade de referência no caso de correspondência subjectAltName é derivada somente do domínio do destinatário. Se o domínio do destinatário não corresponder a nenhuma das entradas dNSName, nenhuma outra identidade de referência será verificada (como o nome do host derivado da resolução DNS MX ou PTR)

• Se existir CN do DN do assunto (CN-ID):
  • a correspondência exata ou curinga é feita em relação ao domínio do destinatário
  • a correspondência exata ou curinga é feita em relação ao nome de host derivado da consulta PTR executada em relação a um IP do servidor de destino
    
    Onde o registro PTR preservou uma consistência no DNS entre o encaminhador e o resolvedor. O que precisa ser mencionado aqui, esse campo CN é comparado a um nome de host do PTR somente quando existe um registro PTR e um registro A resolvido (um encaminhador) para esse nome de host (identidade de referência) retorna um endereço IP que corresponde a um IP de servidor de destino no qual uma consulta PTR foi executada.
    
    A(PTR(IP)) == IP
    
    A identidade de referência no caso de CN-ID é derivada do domínio do destinatário e quando não há correspondência, uma consulta DNS é executada em um registro PTR do IP de destino para obter um nome de host. Se houver um PTR, uma consulta adicional será executada em um registro A em um nome de host derivado de um PTR para confirmar se a consistência do DNS está preservada! Nenhuma outra referência é verificada (como o nome do host derivado da consulta MX)

Em resumo, com a opção 'TLS necessário - Verificar', não há nenhum nome de host MX comparado com dNSName ou CN, um RR PTR de DNS é verificado apenas para CN e é correspondido somente se a consistência do DNS for preservada A(PTR(IP)) = IP, são realizados testes exatos e com curingas para dNSName e CN.

Verificação de TLS Necessária - Domínio hospedado

A identidade apresentada é derivada primeiro da extensão subjectAltName do tipo dNSName. Se não houver correspondência entre o dNSName e uma das identidades de referência aceitas (REF-ID), a verificação falhará, independentemente de CN existir no campo assunto e poderá passar por uma verificação de identidade adicional. O CN derivado do campo de assunto é validado somente quando o certificado não contém nenhuma extensão subjectAltName do tipo dNSName.

Lembre-se de que a identidade apresentada (dNSName ou CN-ID) é comparada com as identidades de referência aceitas até que seja correspondida e na ordem em que são listadas abaixo. 

• Se a extensão dNSName de subjectAltName existir:
  
  Se não houver correspondência entre o dNSName e uma das identidades de referência aceitas listadas abaixo, a validação da identidade falhará
   
  • a correspondência exata ou curinga é feita em relação ao domínio do destinatário: Um dos dNSName deve corresponder a um domínio do destinatário
  • a correspondência exata ou curinga é feita em relação ao nome de host explicitamente configurado com SMTPROUTES (*)
  • a correspondência exata ou curinga é feita em relação ao nome de host MX derivado de uma consulta DNS (não segura) em relação ao nome de domínio do destinatário
    
    Se o domínio do destinatário não tiver configurado explicitamente a rota SMTP com entradas FQDN e o domínio do destinatário não tiver sido correspondido a um FQDN retornado por um registro MX de uma consulta DNS (não segura) em relação a um domínio do destinatário for usado. Se não houver correspondência, nenhum registro PTR será verificado 
• Se existir CN do DN do assunto (CN-ID):

  
  O CN é validado somente quando o dNSName não existe no certificado. O CN-ID é comparado com a lista de identidades de referência aceites abaixo.
  
  

  • a correspondência exata ou curinga é feita em relação ao domínio do destinatário
  • a correspondência exata ou curinga é feita em relação ao nome de host explicitamente configurado em SMTPROUTES (*)
  • a correspondência exata ou curinga é feita em relação ao nome de host MX derivado de uma consulta DNS (não segura) em relação ao nome de domínio do destinatário

SMTPROUTES configurados explicitamente

Quando a rota SMTP é configurada e a identidade apresentada não corresponde ao domínio do destinatário de e-mail, todos os nomes de rotas FQDN são comparados e, se não corresponderem, não haverá mais verificações. Com rotas SMTP configuradas explicitamente, nenhum nome de host MX é considerado como comparado a uma identidade apresentada. A exceção aqui faz uma rota SMTP que foi definida como um endereço IP.

As regras a seguir se aplicam em caso de rotas SMTP configuradas explicitamente:

• Quando existe uma rota SMTP para um domínio de destinatário e ela é um nome de domínio DNS totalmente qualificado (FQDN), ela é considerada uma identidade de referência. Esse nome de host (um nome de rota) é comparado com a identidade apresentada recebida de um certificado derivado de um servidor de destino para o qual ele aponta.

• São permitidas várias rotas para um domínio de destinatário. Se o domínio do destinatário tiver mais de uma rota SMTP, as rotas serão processadas até que os identificadores apresentados do certificado do servidor de destino correspondam ao nome da rota para a qual a conexão foi estabelecida. Se os hosts da lista tiverem prioridades diferentes, os hosts com maior prioridade (0 é o maior e o padrão) serão processados primeiro. Se todas tiverem a mesma prioridade, a lista de rotas será processada na ordem em que as rotas foram definidas pelo usuário.

• Quando o host não responde (não está disponível) ou responde, mas a verificação TLS falha, o próximo host da lista é processado. Quando o primeiro host estiver disponível e passar na verificação, os outros não serão usados.

• Se várias rotas forem resolvidas para os mesmos endereços IP, apenas uma conexão para esse IP será estabelecida e a identidade apresentada derivada do certificado enviado pelo servidor de destino deverá corresponder ao nome de uma dessas rotas.

• Se a rota SMTP existir para domínios de destinatário, mas tiver sido configurada como um endereço IP, a rota ainda será usada para fazer uma conexão, mas uma identidade apresentada do certificado será comparada com o domínio de destinatário e, posteriormente, com o nome de host derivado do registro de recurso DNS/MX.

Quando falamos sobre a opção Verificação TLS necessária para Domínios hospedados, a maneira como o ESA se conectou com um servidor de destino é importante para o processo de verificação TLS devido às rotas SMTP configuradas explicitamente que fornecem identidade de referência adicional a ser considerada no processo.

~= representa correspondência exata ou curinga

Exemplo

Vamos pegar um exemplo da vida real, mas para o domínio do destinatário: example.com. Abaixo, tentei descrever todas as etapas necessárias para verificar manualmente a identidade do 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

Observação: os nomes de host MX e os nomes revDNS não correspondem neste 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   

•   identidade apresentada: dNSName existe (continue com a comparação com a identidade de referência permitida)
  
  
  • identidade de referência = domínio do destinatário (example.com) é verificado e não corresponde ao dNSName DNS:*.emailhosted.not, DNS:emailhosted.not
•   identidade apresentada: CN existe (continuar com a próxima identidade apresentada como para a anterior não houve correspondência)
  
  
  • identidade de referência = domínio do destinatário (example.com) está marcado e não corresponde ao CN *.emailhosted.not
    
    
  • identidade de referência = PTR(IP) : uma consulta PTR é executada em relação ao IP do servidor ao qual o cliente TLS (ESA) estabeleceu conexão e recebeu um certificado, e essa consulta retorna: mx0a.emailhosted.not.
    
    
    • A consistência do DNS é verificada para considerar este nome de host como uma identidade de referência válida:
      
      
      Consistência existe: 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
      

    • O valor de mx0a.emailhosted.not. é comparado com CN *.emailhosted.not e lá ele corresponde.

O nome de domínio PTR valida a identidade e, como o certificado é um certificado assinado por uma CA, ele valida todo o certificado e a sessão TLS é estabelecida.

• identidade apresentada: dNSName existe (portanto, o CN não será processado nesse caso)
  • identidade de referência = domínio do destinatário (example.com) é verificado e
    não corresponde ao dNSName DNS:*.emailhosted.not, DNS:emailhosted.not
  • identidade de referência = FQDN(rota smtp) - não há smtproutes para este domínio de destinatário 
    
    Como não há SMTPROUTES usado adicionalmente:
    
    
  • identidade de referência = MX(domínio do destinatário) - uma consulta DNS MX é executada no domínio do destinatário
    e retorna: mx01.subd.emailhosted.not - isso não corresponde ao dNSName DNS:*.emailhosted.not, DNS:emailhosted.not
• identidade apresentada: CN existe mas é ignorado pois dNSName existe também.