Processus de vérification TLS pour la sécurité de la messagerie Cisco

Introduction

Ce document décrit  Processus de vérification de l'identité du serveur TLS (Transport Layer Security) pour l'appliance de sécurité de la messagerie Cisco (ESA)

Processus de vérification TLS pour la sécurité de la messagerie Cisco

Le processus de vérification TLS est essentiellement un processus de validation en deux étapes :

I - VALIDATION DE CERTIFICAT

Cela implique la vérification des éléments suivants :

• période de validité du certificat - durée de vie du certificat
• émetteur de la chaîne de certificats
• liste de révocation, etc.

II - VALIDATION DE L'IDENTITÉ DU SERVEUR

Il s'agit d'un processus de validation de l'identité présentée par le serveur (contenue dans le certificat de clé publique X.509) par rapport à l'identité de référence du serveur.

Fond

Continuons avec la terminologie des noms d'identité décrite dans la RFC 6125.  

Remarque : l'identité présentée est un identifiant présenté par un certificat de clé publique X.509 du serveur qui peut inclure plusieurs identifiants présentés de différents types. Dans le cas d'un service SMTP, il est contenu sous la forme d'une extension subjectAltName de type dNSName ou sous la forme du CN (Common Name) dérivé du champ d'objet.

Remarque : l'identité de référence est un identificateur construit à partir d'un nom de domaine DNS complet qu'un client attend qu'un service d'application présente dans le certificat.

Le processus de vérification est principalement important pour un client TLS, car en général, un client lance une session TLS et un client doit authentifier la communication. Pour ce faire, le client doit vérifier si l'identité présentée correspond à l'identité de référence. L'important est de comprendre que la sécurité du processus de vérification TLS pour la livraison du courrier est presque entièrement basée sur le client TLS.

Étape 1

La première étape de la validation de l’identité du serveur consiste à déterminer l’identité de référence par le client TLS. La liste des identificateurs de référence que le client TLS juge acceptables dépend de l’application. De plus, une liste d'identificateurs de référence acceptables doit être établie indépendamment des identificateurs présentés par le service. [rfs6125#6.2.1]

L'identité de référence doit être un nom de domaine DNS complet et peut être analysée à partir de n'importe quelle entrée (ce qui est acceptable pour un client et considéré comme sécurisé).  L'identité de référence doit être un nom d'hôte DNS auquel le client tente de se connecter. 

Le nom de domaine du courrier électronique destinataire est une identité de référence qui est directement exprimée par l'utilisateur, par l'intention d'envoyer un message à un utilisateur particulier dans un domaine particulier, et qui répond également à une exigence d'être un nom de domaine complet auquel un utilisateur tente de se connecter. Elle est cohérente uniquement dans le cas d'un serveur SMTP auto-hébergé dont le propriétaire et le gestionnaire sont identiques et où le serveur n'héberge pas trop de domaines. Comme chaque domaine doit être répertorié dans le certificat (comme l'une des valeurs subjectAltName : dNSName). Du point de vue de la mise en oeuvre, la plupart des autorités de certification limitent le nombre de noms de domaine à 25 entrées (jusqu'à 100). Cela n'est pas accepté dans le cas de l'environnement hébergé, pensons aux fournisseurs de services de messagerie électronique (ESP) où les serveurs SMTP de destination hébergent des milliers et des milliers de domaines. Cela ne s'adapte pas.

L'identité de référence explicitement configurée semble être la réponse, mais cela impose certaines contraintes, car il est nécessaire d'associer manuellement une identité de référence au domaine source pour chaque domaine de destination ou d'« obtenir les données d'un service tiers de mappage de domaine dans lequel un utilisateur humain a explicitement placé une confiance et avec lequel le client communique via une connexion ou une association qui fournit à la fois une authentification mutuelle et un contrôle d'intégrité ». [RFC6125#6.2.1]

Conceptuellement, cela peut être considéré comme une « requête MX sécurisée » unique au moment de la configuration, avec le résultat en permanence mis en cache sur le MTA pour se protéger contre toute compromission DNS pendant l'état d'exécution. [2]

Cela permet une authentification plus forte uniquement avec les domaines « partenaires », mais pour les domaines génériques qui n'ont pas été mappés, cela ne passe pas l'examen et cela n'est pas non plus à l'abri des modifications de configuration du côté du domaine de destination (comme les modifications de nom d'hôte ou d'adresse IP).

Étape 2

L'étape suivante du processus consiste à déterminer une identité présentée. L'identité présentée est fournie par un certificat de clé publique X.509 du serveur, comme extension subjectAltName de type dNSName ou comme Common Name (CN) trouvé dans le champ d'objet. Où il est parfaitement acceptable que le champ objet soit vide, tant que le certificat contient une extension subjectAltName qui inclut au moins une entrée subjectAltName.

Bien que l'utilisation de Common Name soit toujours en pratique, elle est considérée comme déconseillée et la recommandation actuelle est d'utiliser des entrées subjectAltName. La prise en charge de l'identité de Common Name reste pour assurer la rétrocompatibilité. Dans ce cas, un dNSName de subjectAltName doit être utilisé en premier et uniquement lorsqu'il est vide, le nom commun est vérifié.

Remarque : le nom commun n'est pas fortement typé car un nom commun peut contenir une chaîne conviviale pour le service, plutôt qu'une chaîne dont la forme correspond à celle d'un nom de domaine DNS complet

À la fin, lorsque les deux types d’identités ont été déterminés, le client TLS doit comparer chacun de ses identifiants de référence aux identifiants présentés afin de trouver une correspondance.

Vérification TLS ESA

ESA permet d'activer TLS et la vérification de certificat lors de la livraison à des domaines spécifiques (à l'aide de la page Contrôles de destination ou de la commande destconfig CLI). Lorsque la vérification du certificat TLS est requise, vous pouvez choisir l'une des deux options de vérification depuis AsyncOS version 8.0.2. Le résultat attendu de la vérification peut varier en fonction de l'option configurée. À partir de 6 paramètres différents pour TLS, disponibles sous le contrôle de la destination, il y a deux paramètres importants qui sont responsables de la vérification du certificat :

1. TLS requis - Vérifier
2. TLS requis - Vérifiez les domaines hébergés.

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 processus de vérification TLS pour l'option (4) Preferred - Verify est identique à (5) Required - Verify, mais l'action entreprise en fonction des résultats diffère comme présenté dans le tableau ci-dessous. Les résultats pour l'option (6) Required - Verify Hosted Domains est identique à (5) Required - Verify mais un flux de vérification TLS est tout à fait différent. 

Paramètres TLS	Signification
4. Préféré (vérification)	TLS est négocié de l'appliance de sécurité de la messagerie vers le ou les MTA du domaine. L'appliance tente de vérifier le certificat des domaines. Trois résultats sont possibles : TLS est négocié et le certificat est vérifié. Le courrier est envoyé via une session chiffrée. TLS est négocié, mais le certificat n'est pas vérifié. Le courrier est envoyé via une session chiffrée. Aucune connexion TLS n'est établie et, par conséquent, le certificat n'est pas vérifié. Le message électronique est envoyé en texte brut.
5. Obligatoire (vérification)	TLS est négocié de l'appliance de sécurité de la messagerie vers le ou les MTA du domaine. La vérification du certificat de domaines est requise. Trois résultats sont possibles : Une connexion TLS est négociée et le certificat est vérifié. Le message électronique est envoyé via une session chiffrée. Une connexion TLS est négociée, mais le certificat n'est pas vérifié par une autorité de certification approuvée. Le courrier n'est pas remis. Une connexion TLS n'est pas négociée. Le courrier n'est pas remis.

La différence entre les options TLS Required - Verify et TLS Required - Verify Hosted Domain réside dans le processus de vérification d'identité. La manière dont l'identité présentée est traitée et le type d'identifiants de référence autorisés à être utilisés font une différence par rapport au résultat final. L'objectif de la description ci-dessous ainsi que du document entier est de rapprocher ce processus de l'utilisateur final. Comme la compréhension incorrecte ou imprécise de ce sujet peut avoir un impact sur la sécurité du réseau de l'utilisateur.

Vérification TLS requise

L'identité présentée est d'abord dérivée de subjectAltName - dNSName extension et s'il n'y a pas de correspondance ou si subjectAltName extension n'existe pas, CN-ID - Common Name from subject field est vérifié.

La liste d'identité de référence (REF-ID) est construite à partir d'un domaine destinataire ou d'un domaine destinataire et d'un nom d'hôte dérivé d'une requête DNS PTR exécutée sur l'adresse IP à laquelle le client est connecté.  Note : Dans ce cas particulier, différentes identités de référence sont comparées à différentes vérifications d'identité présentées.

~= représente la correspondance exacte ou générique

L'identité présentée (dNSName ou CN-ID) est comparée aux identités de référence acceptées jusqu'à ce qu'elle corresponde et dans l'ordre dans lequel elles sont répertoriées ci-dessous. 

• Si l'extension dNSName de subjectAltName existe :
  • la correspondance exacte ou générique est effectuée sur le domaine du destinataire uniquement
    
    L'identité de référence en cas de correspondance subjectAltName est dérivée uniquement du domaine destinataire. Si le domaine du destinataire ne correspond à aucune des entrées dNSName, aucune autre identité de référence n'est vérifiée (comme le nom d'hôte dérivé de la résolution DNS MX ou PTR)

• S'il existe un CN du DN en cours (ID CN) :
  • la correspondance exacte ou générique est effectuée par rapport au domaine du destinataire
  • La correspondance exacte ou générique est effectuée par rapport au nom d'hôte dérivé de la requête PTR effectuée sur une adresse IP du serveur de destination
    
    Où l'enregistrement PTR a préservé une cohérence dans le DNS entre le redirecteur et le résolveur. Ce qu'il faut mentionner ici, c'est que le champ CN est comparé à un nom d'hôte de PTR seulement quand un enregistrement PTR existe et qu'un enregistrement A résolu (un redirecteur) pour ce nom d'hôte (identité de référence) retourne une adresse IP qui correspond à une adresse IP de serveur de destination sur laquelle une requête PTR a été effectuée.
    
    A(PTR(IP)) == IP
    
    L'identité de référence dans le cas de CN-ID est dérivée du domaine destinataire et lorsqu'il n'y a pas de correspondance, une requête DNS est effectuée sur un enregistrement PTR de l'adresse IP de destination pour obtenir un nom d'hôte. Si un PTR existe, une requête supplémentaire est effectuée sur un enregistrement A sur un nom d'hôte dérivé d'un PTR pour confirmer qu'une cohérence DNS est préservée ! Aucune autre référence n'est vérifiée (comme le nom d'hôte dérivé de la requête MX)

En résumé, avec l'option 'TLS Required - Verify', il n'y a pas de nom d'hôte MX comparé à dNSName ou CN, un RR PTR DNS est vérifié uniquement pour CN et n'est mis en correspondance que si la cohérence DNS est préservée A(PTR(IP)) = IP, les tests exacts et génériques pour dNSName et CN sont effectués.

TLS Required Verify - Domaine hébergé

L'identité présentée est d'abord dérivée de l'extension subjectAltName de type dNSName. S'il n'y a aucune correspondance entre le dNSName et l'une des identités de référence acceptées (REF-ID), la vérification échoue, peu importe si CN existe dans le champ d'objet et pourrait passer une autre vérification d'identité. Le CN dérivé du champ objet est validé uniquement lorsque le certificat ne contient aucune extension subjectAltName de type dNSName.

Rappelez-vous que l'identité présentée (dNSName ou CN-ID) est comparée aux identités de référence acceptées jusqu'à ce qu'elle corresponde et dans l'ordre où elles sont répertoriées ci-dessous. 

• Si l'extension dNSName de subjectAltName existe :
  
  En l'absence de correspondance entre dNSName et l'une des identités de référence acceptées répertoriées ci-dessous, la validation de l'identité échoue
   
  • La correspondance exacte ou générique est effectuée par rapport au domaine du destinataire : l'un des dNSName doit correspondre à un domaine du destinataire
  • une correspondance exacte ou générique est effectuée avec un nom d'hôte explicitement configuré avec SMTPROUTES (*)
  • La correspondance exacte ou générique est effectuée avec le nom d'hôte MX dérivé d'une requête DNS (non sécurisée) avec le nom de domaine du destinataire
    
    Si le domaine destinataire n'a pas explicitement configuré la route SMTP avec des entrées FQDN et que le domaine destinataire n'a pas été mis en correspondance, un retour FQDN par un enregistrement MX à partir d'une requête DNS (non sécurisée) sur un domaine destinataire est utilisé. En l'absence de correspondance, aucun autre test n'est effectué et aucun enregistrement PTR n'est vérifié 
• S'il existe un CN du DN en cours (ID CN) :

  
  CN est validé uniquement lorsque dNSName n'existe pas dans le certificat. L'ID CN est comparé à la liste ci-dessous des identités de référence acceptées.
  
  

  • la correspondance exacte ou générique est effectuée par rapport au domaine du destinataire
  • une correspondance exacte ou générique est effectuée avec un nom d'hôte explicitement configuré dans SMTPROUTES (*)
  • La correspondance exacte ou générique est effectuée avec le nom d'hôte MX dérivé d'une requête DNS (non sécurisée) avec le nom de domaine du destinataire

SMTPROUTES explicitement configuré

Lorsque la route SMTP est configurée et que l'identité présentée ne correspond pas au domaine du destinataire de l'e-mail, tous les noms de route FQDN sont comparés et s'ils ne correspondent pas, il n'y a pas d'autres vérifications. Avec des routes SMTP explicitement configurées, aucun nom d'hôte MX n'est considéré comme étant comparé à une identité présentée. L'exception ici fait une route SMTP qui a été définie comme une adresse IP.

Les règles suivantes s'appliquent en cas de routes SMTP explicitement configurées :

• Lorsqu'une route SMTP existe pour un domaine destinataire et qu'il s'agit d'un nom de domaine DNS complet, elle est considérée comme une identité de référence. Ce nom d'hôte (un nom de route) est comparé à l'identité présentée reçue d'un certificat dérivé d'un serveur de destination vers lequel il pointe.

• Plusieurs routes pour un domaine destinataire sont autorisées. Si le domaine destinataire possède plusieurs routes SMTP, les routes sont traitées jusqu'à ce que les identificateurs présentés à partir du certificat du serveur de destination correspondent au nom de la route à laquelle la connexion a été établie. Si les hôtes de la liste ont des priorités différentes, ceux dont la priorité est la plus élevée (0 est la plus élevée et la valeur par défaut) sont traités en premier. Si toutes les routes ont la même priorité, la liste des routes est traitée dans l’ordre dans lequel elles ont été définies par l’utilisateur.

• Si l’hôte ne répond pas (n’est pas disponible) ou s’il répond mais que la vérification TLS a échoué, l’hôte suivant de la liste est traité. Lorsque le premier hôte est disponible et que la vérification réussit, les autres ne sont pas utilisés.

• Si plusieurs routes sont résolues vers les mêmes adresses IP, une seule connexion à cette adresse IP est établie et l'identité présentée, dérivée du certificat envoyé par le serveur de destination, doit correspondre à l'un de ces noms de routes.

• Si une route SMTP existe pour les domaines destinataires mais a été configurée en tant qu'adresse IP, elle est toujours utilisée pour établir une connexion, mais l'identité présentée par le certificat est comparée au domaine destinataire, puis au nom d'hôte dérivé de l'enregistrement de ressource DNS/MX.

Lorsque nous parlons de l'option Vérification TLS requise pour les domaines hébergés, la façon dont ESA s'est connecté à un serveur de destination est importante pour le processus de vérification TLS en raison des routes SMTP explicitement configurées qui fournissent une identité de référence supplémentaire à prendre en compte dans le processus.

~= représente la correspondance exacte ou générique

Exemple

Prenons un exemple de la vie réelle, mais pour le domaine du destinataire : example.com. Ci-dessous, j'ai essayé de décrire toutes les étapes nécessaires à la vérification manuelle de l'identité du serveur. 

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

Remarque : les noms d'hôte MX et les noms revDNS ne correspondent pas dans ce cas

$ 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   

•   identité présentée : dNSName existing (continuer la comparaison avec l'identité de référence autorisée)
  
  
  • l'identité de référence = le domaine destinataire (example.com) est vérifié et ne correspond pas au nom dNSN DNS : *.emailhosted.not, DNS : emailhosted.not
•   identité présentée : CN existe (continuez avec l'identité présentée suivante, car il n'y avait aucune correspondance avec la précédente)
  
  
  • reference identity = le domaine destinataire (example.com) est vérifié et ne correspond pas au CN *.emailhosted.not
    
    
  • reference identity = PTR(IP) : une requête PTR est effectuée sur l'IP du serveur auquel le client TLS (ESA) a établi la connexion et reçu un certificat, et cette requête renvoie : mx0a.emailhosted.not.
    
    
    • La cohérence DNS est vérifiée pour considérer ce nom d'hôte comme une identité de référence valide :
      
      
      La cohérence 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
      

    • La valeur de mx0a.emailhosted.not. est comparée à CN *.emailhosted.not et elle y correspond.

Le nom de domaine PTR valide l'identité et comme le certificat est un certificat signé par une autorité de certification, il valide l'ensemble du certificat et la session TLS est établie.

• identité présentée : dNSName existe (le CN ne sera donc pas traité dans ce cas)
  • identité de référence = le domaine destinataire (example.com) est vérifié et
    ne correspond pas à dNSName DNS:*.emailhosted.not, DNS:emailhosted.not
  • identité de référence = FQDN(smtp route) - il n'y a pas de smtproutes pour ce domaine destinataire 
    
    Comme il n'y a pas SMTPROUTES utilisé en plus :
    
    
  • identité de référence = MX(domaine destinataire) - une requête DNS MX est effectuée sur le domaine destinataire
    et renvoie : mx01.subd.emailhosted.not - ceci ne correspond pas au DNS dNSName : *.emailhosted.not, DNS : emailhosted.not
• identité présentée : CN existe mais est ignoré car dNSName existe également.