De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft het TLS-serveridentiteitscontroleproces (Transport Layer Security) voor de Cisco e-mail security applicatie (ESA)
Het TLS-verificatieproces is in wezen een tweefasenvalideringsproces:
Hierbij gaat het om de verificatie van:
Dit is een validatieproces van de server gepresenteerde identiteit (in X.509 public key certificate) tegen de server referentie identiteit.
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.
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).
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.
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:
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:
|
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:
|
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.
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.
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.
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.
CN wordt alleen gevalideerd als dNSName niet in het certificaat voorkomt. De GN-code wordt vergeleken met onderstaande lijst van geaccepteerde referentie-identiteiten.
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 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
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
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 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.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
16-Apr-2018 |
Eerste vrijgave |