TLS-verificatieproces voor Cisco e-mail security

Inleiding

Dit document beschrijft het TLS-serveridentiteitscontroleproces (Transport Layer Security) voor de Cisco e-mail security applicatie (ESA)

TLS-verificatieproces voor Cisco e-mail security

Het TLS-verificatieproces is in wezen een tweefasenvalideringsproces:

I - CERTIFICAATVALIDERING

Hierbij gaat het om de verificatie van:

• geldigheidsperiode van het certificaat - levensduur van het certificaat
• certificaatketenemittent
• intrekkingslijst enz. ...

II - BEVESTIGING VAN SERVERIDENTITEIT

Dit is een validatieproces van de server gepresenteerde identiteit (in X.509 public key certificate) tegen de server referentie identiteit.

Achtergrond

Laten we de terminologie van de identiteitsnaam zoals beschreven in RFC 6125 gebruiken.  

Opmerking: De gepresenteerde identiteit is een identificator die wordt aangeboden door een server X.509 public key certificate die meer dan één gepresenteerde identificatoren van verschillende typen kan bevatten. In het geval van een SMTP-dienst, is het opgenomen als een subjectAltName-uitbreiding van het type dNSName of als de CN (Common Name) afgeleid van het veld onderwerp.

Opmerking: De referentie-identiteit is een identificator die is samengesteld uit een volledig gekwalificeerde DNS-domeinnaam die een klant verwacht dat een applicatie-dienst in het certificaat aanwezig zal zijn.

Het verificatieproces is vooral belangrijk voor een TLS-client, omdat een client over het algemeen een TLS-sessie start en een client de communicatie moet authenticeren. Om dit te bereiken moet een client controleren of de aangeboden identiteit overeenkomt met de referentie-identiteit. Het belangrijkste is om te begrijpen dat de beveiliging van het TLS-verificatieproces voor het bezorgen van post bijna volledig is gebaseerd op de TLS-client.

Stap één

De eerste stap in de validatie van de serveridentiteit is het bepalen van de referentie-identiteit door de TLS-client. Het hangt van de toepassing af welke lijst van referentie-identificatoren TLS-client aanvaardbaar acht. Ook moet een lijst van aanvaardbare referentie-identificatoren worden opgesteld onafhankelijk van de door de dienst ingediende identificatoren. [rfs6125#6.2.1]

De referentie-identiteit moet een volledig gekwalificeerde DNS-domeinnaam zijn en kan worden geparsed van elke input (die acceptabel is voor een client en veilig is).  De referentie-identiteit moet een DNS-hostnaam zijn waarmee de client probeert verbinding te maken. 

De ontvangende e-mail domeinnaam is referentie-identiteit die direct wordt uitgedrukt door de gebruiker, door de intentie om een bericht te verzenden naar een bepaalde gebruiker in een bepaald domein en dit voldeed ook aan een vereiste om een FQDN te zijn waarmee een gebruiker probeert te verbinden. Het is alleen consistent in het geval van zelfgehoste SMTP-server, waarbij de SMTP-server eigendom is van en beheerd wordt door dezelfde eigenaar en de server niet te veel domeinen hoopt. Zoals elk domein moet worden vermeld in certificaat (als een van subjectAltName: dNSName waarden). Vanuit implementatieperspectief beperken de meeste certificeringsinstanties (CA) het aantal domeinnamen tot 25 vermeldingen (tot wel 100). Dit wordt niet geaccepteerd in het geval van de gehoste omgeving, laten we denken aan Email Service Providers (ESP) waar de bestemming-SMTP-servers duizenden en meer domeinen hosten. Dit is gewoon niet schaalbaar.

De expliciet ingestelde referentie-identiteit lijkt het antwoord te zijn, maar dit legt een aantal beperkingen op, aangezien het nodig is om een referentie-identiteit handmatig te koppelen aan een brondomein voor elk doeldomein of "de gegevens te verkrijgen van een third-party domain mapping service waarin een menselijke gebruiker expliciet vertrouwen heeft gesteld en waarmee de client communiceert via een verbinding of associatie die zowel wederzijdse authenticatie als integriteitscontrole biedt". [RFC6125#6.2.1]

Conceptueel kan dit worden gezien als een eenmalige "beveiligde MX query" op het moment van configuratie, met het resultaat permanent gecached op de MTA om te beschermen tegen een DNS compromis tijdens het uitvoeren van de staat. [2]

Dit geeft een sterkere authenticatie alleen met "partner" domeinen, maar voor generiek domein dat niet in kaart is gebracht dit niet het examen en dit is ook niet immuun voor configuratieveranderingen aan de kant van het doeldomein (zoals hostname of IP adreswijzigingen).

Stap 2

De volgende stap in het proces is om een voorgestelde identiteit te bepalen. De voorgestelde identiteit wordt verstrekt door een server X.509 openbaar zeer belangrijk certificaat, als subjectAltName uitbreiding van type dNSName of als Gemeenschappelijke Naam (CN) die in het onderwerp gebied wordt gevonden. Waar het volledig aanvaardbaar is dat het onderwerpveld leeg is, zolang het certificaat een subjectAltName-extensie bevat die ten minste één subjectAltName-vermelding bevat.

Hoewel het gebruik van de algemene naam nog steeds in de praktijk is, wordt het geacht te worden afgekeurd en de huidige aanbeveling is om subjectAltName-vermeldingen te gebruiken. De ondersteuning voor de identiteit van Common Name blijft voor achterwaartse compatibiliteit. In dat geval moet eerst een naam van subjectAltName worden gebruikt en alleen wanneer deze leeg is, wordt de algemene naam gecontroleerd.

Opmerking: de algemene naam is niet sterk getypt omdat een algemene naam een mensvriendelijke string voor de dienst zou kunnen bevatten, in plaats van een string waarvan de vorm overeenkomt met die van een volledig gekwalificeerde DNS-domeinnaam

Aan het einde van de periode waarin beide soorten identiteiten zijn bepaald, moet de TLS-client elk van zijn referentie-identificatoren vergelijken met de gepresenteerde identificatoren om een overeenkomst te vinden.

TLS-verificatie ESA

ESA maakt het mogelijk TLS en certificaat verificatie op levering naar specifieke domeinen (met behulp van de Bestemmingscontroles pagina of destconfig CLI commando). Als TLS-certificaatverificatie vereist is, kunt u een van de twee verificatieopties kiezen sinds AsyncOS versie 8.0.2. Het verwachte verificatieresultaat kan variëren afhankelijk van de ingestelde optie. Van 6 verschillende instellingen voor TLS, beschikbaar onder bestemmingscontrole zijn er twee belangrijke die verantwoordelijk zijn voor de certificaatverificatie:

1. TLS vereist - Verifiëren
2. TLS vereist - Controleer gehoste domeinen.

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

Een TLS-verificatieproces voor optie (4) - Verifiëren is identiek aan (5) Vereist - Verifiëren, maar de actie die wordt ondernomen op basis van resultaten verschilt zoals weergegeven in onderstaande tabel. De resultaten voor optie (6) Vereist - Controleer Hosted Domains is identiek aan (5) Vereist - Controleer maar een TLS-verificatiestroom is heel anders. 

TLS-instellingen	Betekenis
4. Voorkeurs (controleren)	TLS wordt via het e-mail security applicatie onderhandeld naar de MTA(s) voor het domein. Het apparaat probeert het domeincertificaat te verifiëren. Drie uitkomsten zijn mogelijk: TLS wordt besproken en het certificaat wordt geverifieerd. De mail wordt geleverd via een versleutelde sessie. TLS wordt onderhandeld, maar het certificaat wordt niet geverifieerd. De mail wordt geleverd via een versleutelde sessie. Er wordt geen TLS-verbinding gemaakt en het certificaat wordt vervolgens niet geverifieerd. Het e-mailbericht wordt in onbewerkte tekst verzonden.
5. Vereist (controleren)	TLS wordt via het e-mail security applicatie onderhandeld naar de MTA(s) voor het domein. Het certificaat betreffende de domeinen moet worden geverifieerd. Drie uitkomsten zijn mogelijk: Er wordt onderhandeld over een TLS-verbinding en het certificaat wordt geverifieerd. Het e-mailbericht wordt geleverd via een versleutelde sessie. Er wordt onderhandeld over een TLS-verbinding, maar het certificaat wordt niet geverifieerd door een vertrouwde certificeringsinstantie. De post wordt niet afgeleverd. Er wordt niet onderhandeld over een TLS-verbinding. De post wordt niet afgeleverd.

Het verschil tussen de opties TLS Vereist - Verifieer en TLS Vereist - Verifieer Hosted Domain opties ligt in het identiteitsverificatieproces. De wijze waarop de voorgestelde identiteit wordt verwerkt en welk soort referentie-identificatoren mogen worden gebruikt, maken een verschil in het eindresultaat. Het doel van de onderstaande beschrijving en het gehele document is om dit proces dichter bij de eindgebruiker te brengen. Aangezien het onjuiste of onduidelijke begrip van dit onderwerp een veiligheidseffect op gebruikersnetwerk kan hebben.

TLS vereist voor verificatie

De voorgestelde identiteit wordt eerst afgeleid van subjectAltName - dNSName extensie en als er geen match of subjectAltName extensie is, bestaat deze niet dan CN-ID - algemene naam van onderwerp veld wordt gecontroleerd.

De referentie-identiteitslijst (REF-ID) is samengesteld uit een ontvankelijk domein of ontvankelijk domein en hostname afgeleid van een PTR DNS-query die wordt uitgevoerd tegen het IP-adres waarmee de client is verbonden.  Opmerking: In dat specifieke geval worden verschillende referentie-identiteiten vergeleken met verschillende gepresenteerde identiteitscontroles.

~= staat voor exacte of overeenkomsten met jokerteken

De aangeboden identiteit (dNSName of CN-ID) wordt vergeleken met de aanvaarde referentie-identiteiten totdat deze wordt gematcht en in de onderstaande volgorde. 

• Als NSName uitbreiding van subjectAltName bestaat:
  • de exacte of jokerteken match wordt alleen tegen het ontvangende domein gedaan
    
    De referentie-identiteit in het geval van subjectAltName match is alleen afgeleid van het ontvangende domein. Als het ontvangende domein niet overeenkomt met een van de NetName-vermeldingen, wordt er geen verdere referentie-identiteit gecontroleerd (zoals hostnaam afgeleid van DNS-resolutie MX of PTR)

• Indien GN van onderwerp DN bestaat (CN-ID):
  • de exacte of jokerteken match wordt gedaan tegen het ontvangende domein
  • exacte of wildcard match wordt gedaan tegen hostname afgeleid van PTR query uitgevoerd tegen een IP van de doelserver
    
    Waar het PTR-record een consistentie in DNS tussen doorsturen en oplosser heeft behouden. Wat hier moet worden vermeld, dat CN-veld wordt vergeleken met een hostnaam van PTR alleen wanneer een PTR-record bestaat en een opgelost A-record (een doorgeefster) voor deze hostnaam (referentie-identiteit) geeft een IP-adres terug dat overeenkomt met een doelserver IP waartegen een PTR-query is uitgevoerd.
    
    A(PTR(IP)) == IP
    
    De referentie-identiteit in het geval van CN-ID wordt afgeleid van het ontvangende domein en wanneer er geen overeenkomst is wordt een DNS-query uitgevoerd tegen een PTR-record van bestemming IP om een hostname te krijgen. Als een PTR bestaat, wordt er een extra query uitgevoerd tegen een A-record op een hostnaam afgeleid van een PTR om te bevestigen dat een DNS-consistentie behouden blijft! Er wordt geen verdere referentie gecontroleerd (zoals hostname afgeleid van MX query)

Samenvattend, met 'TLS Vereist - Verifiëren' optie is er geen MX hostname vergeleken met NSName of CN, een DNS PTR RR wordt alleen gecontroleerd voor CN en wordt alleen aangepast als DNS consistentie behouden A(PTR(IP)) = IP, zowel exacte als wildcard test voor dNSName en CN worden uitgevoerd.

TLS vereist - Hosted domain

De voorgestelde identiteit wordt eerst afgeleid van subjectAltName extensie van het type dNSName. Als er geen overeenkomst is tussen de dNSName en een van de geaccepteerde referentie-identiteiten (REF-ID), mislukt de verificatie ongeacht of GN in het onderwerpveld bestaat en kan verdere identiteitsverificatie doorstaan. De van onderwerp afgeleide GN wordt slechts gevalideerd wanneer het certificaat geen van subjectAltName uitbreiding van type dNSName bevat.

Rappel dat de aangeboden identiteit (dNSName of CN-ID) wordt vergeleken met aanvaarde referentie-identiteiten tot deze is gematcht en in de onderstaande volgorde. 

• Als NSName uitbreiding van subjectAltName bestaat:
  
  Als er geen overeenstemming is tussen de dNSName en een van de geaccepteerde referentie-identiteiten hieronder vermeld, is validatie mislukt
   
  • De exacte of wildcard match wordt gedaan tegen het ontvangende domein: Een van de dNSName moet overeenkomen met een ontvangend domein
  • exacte of wildcard match wordt gedaan tegen expliciet geconfigureerde hostname met SMTPROUTES (*)
  • exacte of wildcard match wordt gedaan tegen MX hostname afgeleid van (een onveilige) DNS-query tegen de ontvangende domeinnaam
    
    Als het ontvangende domein niet expliciet SMTP-route heeft geconfigureerd met FQDN-vermeldingen en het ontvangende domein niet is aangepast dan wordt een FQDN-terugkeer door een MX-record van (een onveilige) DNS-query tegen een ontvangend domein gebruikt. Als er geen overeenkomst is geen verdere tests worden uitgevoerd, worden geen PTR-records gecontroleerd 
• Indien GN van onderwerp DN bestaat (CN-ID):

  
  CN wordt alleen gevalideerd als dNSName niet in het certificaat voorkomt. De GN-code wordt vergeleken met onderstaande lijst van geaccepteerde referentie-identiteiten.
  
  

  • de exacte of jokerteken match wordt gedaan tegen het ontvangende domein
  • exacte of wildcard match wordt gedaan tegen expliciet geconfigureerd hostname in SMTPROUTES (*)
  • exacte of wildcard match wordt gedaan tegen MX hostname afgeleid van (een onveilige) DNS-query tegen de ontvangende domeinnaam

Expliciet geconfigureerde SMTPROUTES

Wanneer de SMTP-route is geconfigureerd en de aangeboden identiteit niet overeenkomt met het e-mailontvangerdomein, worden alle FQDN-routenamen vergeleken en als ze niet overeenkomen, worden er geen verdere controles uitgevoerd. Met expliciet ingestelde SMTP-routes wordt geen MX-hostnaam beschouwd als te worden vergeleken met een gepresenteerde identiteit. De uitzondering maakt hier een SMTP-route die als IP-adres is ingesteld.

De volgende regels zijn van toepassing in het geval van expliciet geconfigureerde SMTP-routes:

• Wanneer er een SMTP-route bestaat voor een ontvankelijk domein en het een volledig gekwalificeerde DNS-domeinnaam (FQDN) is, wordt het beschouwd als een referentie-identiteit. Deze hostname (een routenaam) wordt vergeleken met de gepresenteerde identiteit die wordt ontvangen van een certificaat dat is afgeleid van een doelserver waarnaar het verwijst.

• Meerdere routes voor een ontvankelijk domein zijn toegestaan. Als het ontvangende domein meer dan één SMTP-route heeft, worden de routes verwerkt tot de aangeboden identificatoren van het certificaat van de bestemmingsserver overeenkomen met de naam van de route waarop de verbinding tot stand is gebracht. Als de hosts op de lijst verschillende prioriteiten hebben, worden degenen met de hoogste (0 is de hoogste en de standaard) eerst verwerkt. Als allen de zelfde prioriteit hebben wordt de lijst van routes verwerkt in de orde de routes door de gebruiker werden geplaatst.

• In het geval dat de host niet reageert (niet beschikbaar is) of dat het reageert maar de TLS-verificatie heeft gefaald dat de volgende host uit de lijst wordt verwerkt. Wanneer de eerste host beschikbaar is en de verificatie doorgeeft, worden de anderen niet gebruikt.

• Als meerdere routes naar dezelfde IP-adressen worden verzonden, wordt slechts één verbinding met dit IP tot stand gebracht en moet de aangeboden identiteit die is afgeleid van het certificaat dat door de doelserver is verzonden, overeenkomen met een van deze routenamen.

• Als er een SMTP-route bestaat voor ontvangende domeinen maar als IP-adres is geconfigureerd, wordt de route nog steeds gebruikt om een verbinding te maken, maar wordt een gepresenteerde identiteit van het certificaat vergeleken met het ontvangende domein en verder met de hostnaam die is afgeleid uit het DNS/MX-bronrecord.

Wanneer we het hebben over de optie TLS Required verify voor gehoste domeinen, is de manier waarop ESA verbinding heeft gemaakt met een doelserver belangrijk voor het TLS-verificatieproces vanwege de expliciet ingestelde SMTP-routes die extra referentie-identiteit bieden die in het proces moet worden overwogen.

~= staat voor exacte of overeenkomsten met jokerteken

Voorbeeld

Neem een voorbeeld uit het echte leven, maar voor het ontvangende domein: example.com. Hieronder heb ik geprobeerd om alle stappen te beschrijven die nodig zijn om de identiteit van de server handmatig te verifiëren. 

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

Opmerking: de MX hostnamen en de revDNS namen komen in dit geval niet overeen

$ 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   

•   gepresenteerde identiteit: dNSName bestaat (doorgaan met vergelijken met toegestane referentie-identiteit)
  
  
  • referentie-identiteit = ontvankelijk domein (example.com) wordt gecontroleerd en komt niet overeen met de dNSName DNS:*.emailhost.not, DNS:emailhost.not
•   gepresenteerde identiteit: CN bestaat (doorgaan met de volgende voorgestelde identiteit zoals voor de vorige was er geen match)
  
  
  • referentie-identiteit = ontvangend domein (example.com) wordt gecontroleerd en komt niet overeen met de GN *.emailhost.not
    
    
  • referentie-identiteit = PTR(IP) : een PTR-query wordt uitgevoerd tegen het IP van de server waarop de TLS-client (ESA) een verbinding tot stand heeft gebracht en een certificaat heeft ontvangen, en deze query retourneert: mx0a.emailhost.not
    
    
    • DNS-consistentie is ingeschakeld om deze hostnaam als geldige referentie-identiteit te beschouwen:
      
      
      Consistentie bestaat: 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
      

    • De waarde van mx0a.emailhost.not. wordt vergeleken met CN *.emailhost.not en daar komt het overeen.

De PTR-domeinnaam valideert de identiteit en aangezien het certificaat een CA-ondertekend certificaat is, valideert het het gehele certificaat en wordt de TLS-sessie ingesteld.

• voorgelegde identiteit: dNSName bestaat (in dat geval wordt de GN dus niet verwerkt)
  • referentie-identiteit = ontvangend domein (example.com) wordt gecontroleerd en
    komt niet overeen met de DNS:*.emailhost.not, DNS:emailhost.not
  • referentie-identiteit = FQDN (smtp-route) - er zijn geen smetproutes voor dit ontvangende domein 
    
    Aangezien er geen SMTPROUTES worden gebruikt:
    
    
  • referentie-identiteit = MX(ontvangend domein) - een DNS MX-query wordt uitgevoerd tegen het ontvangende domein
    en retourneert: mx01.subd.emailhost.not - dit komt niet overeen met de dNSName DNS:*.emailhost.not, DNS:emailhost.not
• gepresenteerde identiteit: CN bestaat maar wordt overgeslagen als dNSName bestaat ook.