TLS-Verifizierungsprozess für Cisco Email Security

Einleitung

Dieses Dokument beschreibt den TLS-Prozess (Transport Layer Security) zur Verifizierung der Serveridentität für die Cisco E-Mail Security Appliance (ESA)

TLS-Verifizierungsprozess für Cisco Email Security

Der TLS-Verifizierungsprozess umfasst im Wesentlichen zwei Phasen:

I - ZERTIFIKATSPRÜFUNG

Dies umfasst die Überprüfung

• Gültigkeitsdauer des Zertifikats - Lebensdauer des Zertifikats
• Zertifikatskettenaussteller
• Widerrufsliste usw.

II - SERVERIDENTITÄTSPRÜFUNG

Hierbei handelt es sich um einen Validierungsprozess der vom Server präsentierten Identität (enthalten im X.509-Public-Key-Zertifikat) anhand der Serverreferenzidentität.

Hintergrund

Befolgen wir nun die Identitätsnamensterminologie, die in RFC 6125 beschrieben ist.  

Hinweis: Die präsentierte Identität ist ein Bezeichner, der von einem öffentlichen X.509-Schlüsselzertifikat des Servers präsentiert wird, das mehr als einen präsentierten Bezeichner verschiedener Typen enthalten kann. Im Fall des SMTP-Diensts ist er entweder als subjectAltName-Erweiterung vom Typ dNSName oder als vom Betrefffeld abgeleiteter CN (Common Name) enthalten.

Hinweis: Die Referenzidentität ist ein Bezeichner, der aus einem vollständig qualifizierten DNS-Domänennamen erstellt wird, den ein Client im Zertifikat von einem Anwendungsdienst erwartet.

Der Verifizierungsprozess ist vor allem für einen TLS-Client wichtig, da ein Client im Allgemeinen eine TLS-Sitzung initiiert und die Kommunikation von einem Client authentifiziert werden muss. Dazu muss ein Client überprüfen, ob die präsentierte Identität mit der Referenzidentität übereinstimmt. Wichtig ist, dass die Sicherheit des TLS-Verifizierungsprozesses für die E-Mail-Zustellung fast vollständig auf dem TLS-Client basiert.

Schritt 1

Der erste Schritt bei der Serveridentitätsüberprüfung besteht darin, die Referenzidentität durch den TLS-Client zu bestimmen. Es hängt von der Anwendung ab, welche Liste von Referenz-IDs der TLS-Client als zulässig ansieht. Außerdem muss eine Liste akzeptabler Referenzkennungen unabhängig von den vom Dienst angegebenen Kennungen erstellt werden. [rfs6125#6.2.1]

Bei der Referenzidentität muss es sich um einen vollständig qualifizierten DNS-Domänennamen handeln, der von jeder beliebigen Eingabe analysiert werden kann (was für einen Client akzeptabel und als sicher anzusehen ist).  Die Verweisidentität muss ein DNS-Hostname sein, mit dem der Client eine Verbindung herzustellen versucht. 

Der E-Mail-Domänenname des Empfängers ist eine Referenzidentität, die direkt vom Benutzer durch die Absicht ausgedrückt wird, eine Nachricht an einen bestimmten Benutzer, insbesondere eine Domäne, zu senden, und dies erfüllt auch die Anforderung, ein FQDN zu sein, mit dem ein Benutzer eine Verbindung herzustellen versucht. Konsistent ist dies nur bei selbst gehosteten SMTP-Servern, bei denen der SMTP-Server dem gleichen Eigentümer gehört und von diesem verwaltet wird und der Server nicht zu viele Domänen hostet. Da jede Domäne im Zertifikat aufgeführt werden muss (als einer der Werte subjectAltName: dNSName). Aus Implementierungsperspektive begrenzen die meisten Zertifizierungsstellen (Certificate Authorities, CA) die Anzahl der Domänennamen auf bis zu 25 Einträge (bis zu 100). Dies wird in der gehosteten Umgebung nicht akzeptiert. Denken wir an E-Mail-Service-Provider (ESP), bei denen die Ziel-SMTP-Server Tausende und mehr Domänen hosten. Das ist einfach nicht skalierbar.

Die explizit konfigurierte Referenzidentität scheint die Antwort zu sein, dies setzt jedoch einige Einschränkungen voraus, da es erforderlich ist, der Quelldomäne für jede Zieldomäne manuell eine Referenzidentität zuzuordnen oder "die Daten von einem Drittanbieter-Domänenzuordnungsdienst zu erhalten, dem ein menschlicher Benutzer explizit vertraut hat und mit dem der Client über eine Verbindung oder Verbindung kommuniziert, die sowohl gegenseitige Authentifizierung als auch Integritätsprüfung bietet". [RFC6125 6.2.1]

Konzeptionell kann man sich dies bei der Konfiguration als einmalige "sichere MX-Abfrage" vorstellen, bei der das Ergebnis permanent auf der MTA zwischengespeichert wird, um im Ausführungszustand vor jeglichen DNS-Kompromittierungen zu schützen. [2]

Dies führt zu einer stärkeren Authentifizierung nur bei "Partner"-Domänen, aber für generische Domänen, die nicht zugeordnet wurden, besteht diese Prüfung nicht und ist auch nicht immun gegen Konfigurationsänderungen auf Seiten der Zieldomäne (wie Hostname- oder IP-Adressänderungen).

Schritt 2

Der nächste Schritt in diesem Prozess ist die Bestimmung einer präsentierten Identität. Die präsentierte Identität wird von einem öffentlichen Schlüsselzertifikat des Servers X.509 bereitgestellt, als subjectAltName-Erweiterung vom Typ dNSName oder als Common Name (CN) im Betrefffeld. Wenn das Betreff-Feld leer sein darf, sofern das Zertifikat eine Erweiterung subjectAltName enthält, die mindestens einen Eintrag subjectAltName enthält.

Obwohl die Verwendung von Common Name noch in der Praxis üblich ist, wird sie als veraltet betrachtet, und die aktuelle Empfehlung lautet, subjectAltName-Einträge zu verwenden. Die Unterstützung für die Identität von Common Name bleibt aus Gründen der Abwärtskompatibilität erhalten. In diesem Fall sollte zuerst ein dNSName von subjectAltName verwendet werden, und nur wenn er leer ist, wird der Common Name überprüft.

Hinweis: Der Common Name ist nicht stark typisiert, da ein Common Name möglicherweise eine benutzerfreundliche Zeichenfolge für den Dienst enthält und keine Zeichenfolge, deren Form mit der eines vollständig qualifizierten DNS-Domänennamens übereinstimmt

Wenn beide Identitätstypen ermittelt wurden, muss der TLS-Client zum Finden einer Übereinstimmung jeden seiner Referenz-Identifikatoren mit den angegebenen Identifikatoren vergleichen.

ESA TLS-Verifizierung

Die ESA ermöglicht die Aktivierung von TLS und Zertifikatsverifizierung bei der Zustellung an bestimmte Domänen (mithilfe der Zielsteuerungs-Seite oder des Befehls destconfig CLI). Wenn eine TLS-Zertifikatsüberprüfung erforderlich ist, können Sie eine von zwei Überprüfungsoptionen seit AsyncOS Version 8.0.2 auswählen. Das erwartete Verifizierungsergebnis kann je nach konfigurierter Option variieren. Von den 6 verschiedenen Einstellungen für TLS, die unter Zielsteuerung zur Verfügung stehen, gibt es zwei wichtige, die für die Zertifikatsüberprüfung verantwortlich sind:

1. TLS erforderlich - Verifizieren
2. TLS erforderlich - Verifizieren gehosteter Domänen.

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

Ein TLS-Verifizierungsprozess für Option (4) Bevorzugt - Verifizieren ist identisch mit (5) Erforderlich - Verifizieren, aber die aufgrund der Ergebnisse ergriffenen Maßnahmen unterscheiden sich, wie in der folgenden Tabelle dargestellt. Die Ergebnisse für die Option (6) Erforderlich - Verifizieren, dass gehostete Domänen identisch mit der Option (5) Erforderlich - Verifizieren sind, aber der TLS-Verifizierungsfluss ist ganz anders. 

TLS-Einstellungen	Bedeutung
4. Bevorzugt (Verifizieren)	TLS wird von der E-Mail-Security-Appliance an die MTA(s) für die Domäne ausgehandelt. Die Appliance versucht, das Domänenzertifikat zu überprüfen. Drei Ergebnisse sind möglich: TLS wird ausgehandelt und das Zertifikat verifiziert. Die E-Mail wird über eine verschlüsselte Sitzung zugestellt. TLS wurde ausgehandelt, das Zertifikat wurde jedoch nicht verifiziert. Die E-Mail wird über eine verschlüsselte Sitzung zugestellt. Es wird keine TLS-Verbindung hergestellt, und anschließend wird das Zertifikat nicht verifiziert. Die E-Mail-Nachricht wird im Nur-Text-Format zugestellt.
5. Erforderlich (Verifizieren)	TLS wird von der E-Mail-Security-Appliance an die MTA(s) für die Domäne ausgehandelt. Das Domänenzertifikat muss überprüft werden. Drei Ergebnisse sind möglich: Eine TLS-Verbindung wird ausgehandelt, und das Zertifikat wird verifiziert. Die E-Mail-Nachricht wird in einer verschlüsselten Sitzung zugestellt. Eine TLS-Verbindung wird ausgehandelt, aber das Zertifikat wird nicht von einer vertrauenswürdigen Zertifizierungsstelle überprüft. Die Post wird nicht zugestellt. Eine TLS-Verbindung wurde nicht ausgehandelt. Die Post wird nicht zugestellt.

Der Unterschied zwischen TLS erforderlich - Verifizieren und TLS erforderlich - Optionen für gehostete Domäne verifizieren liegt im Identitätsverifizierungsprozess. Die Art und Weise, wie die präsentierte Identität verarbeitet wird und welche Art von Referenzkennungen verwendet werden dürfen, macht einen Unterschied zu einem Endergebnis. Der Zweck der nachfolgenden Beschreibung sowie des gesamten Dokuments besteht darin, diesen Prozess dem Endbenutzer näher zu bringen. Da ein falsches oder unklares Verständnis dieses Themas Auswirkungen auf die Sicherheit des Anwendernetzwerks haben kann.

TLS erforderlich Verifizierung

Die angezeigte Identität wird zuerst von der Erweiterung subjectAltName - dNSName abgeleitet. Wenn keine Übereinstimmung besteht oder die Erweiterung subjectAltName nicht vorhanden ist, wird CN-ID - Common Name aus dem Feld subject aktiviert.

Die Referenzidentitätsliste (REF-ID) wird aus einer Empfängerdomäne oder Empfängerdomäne erstellt, und der Hostname, der von einer PTR-DNS-Abfrage abgeleitet wurde, wird anhand der IP-Adresse ausgeführt, mit der der Client verbunden ist.  Hinweis: In diesem besonderen Fall werden verschiedene Referenzidentitäten mit verschiedenen präsentierten Identitätskontrollen verglichen.

~= steht für exakte Übereinstimmung oder Platzhalterübereinstimmung

Die präsentierte Identität (dNSName oder CN-ID) wird mit den akzeptierten Referenzidentitäten verglichen, bis sie abgeglichen ist und in der Reihenfolge, in der sie unten aufgeführt sind. 

• Wenn die Erweiterung dNSName von subjectAltName vorhanden ist:
  • exakte Übereinstimmung oder Platzhalterübereinstimmung nur für Empfängerdomäne
    
    Die Verweisidentität im Fall einer subjectAltName-Übereinstimmung wird nur von der Empfängerdomäne abgeleitet. Wenn die Empfängerdomäne mit keinem der dNSName-Einträge übereinstimmt, wird keine weitere Referenzidentität überprüft (wie der Hostname, der von der DNS-Auflösung MX oder PTR abgeleitet wird).

• Wenn CN des Antragstellers DN vorhanden ist (CN-ID):
  • exakte Übereinstimmung oder Platzhalterübereinstimmung für Empfängerdomäne erfolgt
  • Die exakte Übereinstimmung oder der Platzhalter wird für den Hostnamen vorgenommen, der von der PTR-Abfrage abgeleitet wurde, die für eine IP des Zielservers durchgeführt wurde.
    
    Dabei konnte durch den PTR-Datensatz eine DNS-Konsistenz zwischen Forwarder und Resolver beibehalten werden. An dieser Stelle muss erwähnt werden, dass das CN-Feld nur dann mit einem Hostnamen von PTR verglichen wird, wenn ein PTR-Datensatz vorhanden ist und ein aufgelöster A-Datensatz (ein Forwarder) für diesen Hostnamen (Referenzidentität) eine IP-Adresse zurückgibt, die mit einer IP-Adresse des Zielservers übereinstimmt, gegen die eine PTR-Abfrage durchgeführt wurde.
    
    A(PTR(IP)) == IP
    
    Die Referenzidentität im Fall einer CN-ID wird von der Empfängerdomäne abgeleitet, und wenn keine Übereinstimmung besteht, wird eine DNS-Abfrage für einen PTR-Datensatz der Ziel-IP durchgeführt, um einen Hostnamen zu erhalten. Wenn ein PTR vorhanden ist, wird eine zusätzliche Abfrage für einen A-Eintrag in einem von einem PTR abgeleiteten Hostnamen durchgeführt, um zu bestätigen, dass eine DNS-Konsistenz beibehalten wird. Keine weiteren Verweise werden geprüft (wie Hostname von MX-Abfrage abgeleitet)

Zusammenfassend lässt sich sagen, dass es mit der Option "TLS Required - Verify" keinen MX-Hostnamen im Vergleich zu dNSName oder CN gibt. Ein DNS-PTR-RR wird nur für CN überprüft und nur dann zugeordnet, wenn die DNS-Konsistenz erhalten bleibt A(PTR(IP)) = IP. Es werden sowohl exakte Tests als auch Platzhaltertests für dNSName und CN durchgeführt.

TLS erforderlich verifiziert - gehostete Domäne

Die dargestellte Identität wird zuerst von der subjectAltName-Erweiterung vom Typ dNSName abgeleitet. Wenn keine Übereinstimmung zwischen dNSName und einer akzeptierten Referenzidentität (REF-ID) besteht, schlägt die Überprüfung fehl, unabhängig davon, ob CN im Betrefffeld vorhanden ist, und kann eine weitere Identitätsüberprüfung bestehen. Die vom Betreff-Feld abgeleitete CN wird nur validiert, wenn das Zertifikat keine der SubjectAltName-Erweiterung vom Typ dNSName enthält.

Denken Sie daran, dass die präsentierte Identität (dNSName oder CN-ID) mit den akzeptierten Referenzidentitäten verglichen wird, bis sie abgeglichen ist und in der Reihenfolge wie unten aufgeführt ist. 

• Wenn die Erweiterung dNSName von subjectAltName vorhanden ist:
  
  Wenn keine Übereinstimmung zwischen dNSName und einer der unten aufgeführten zulässigen Referenzidentitäten besteht, ist die Identitätsüberprüfung fehlgeschlagen.
   
  • Übereinstimmung mit exakter Adresse oder Platzhalter für Empfängerdomäne: Einer der dNSName muss mit einer Empfängerdomäne übereinstimmen.
  • Die exakte oder Platzhalterübereinstimmung erfolgt für den explizit konfigurierten Hostnamen mit SMTPROUTES (*).
  • exakte Übereinstimmung oder Platzhalterabgleich für MX-Hostnamen, der von einer (unsicheren) DNS-Abfrage für den Empfänger-Domänennamen abgeleitet wurde
    
    Wenn die Empfängerdomäne keine explizit konfigurierte SMTP-Route mit FQDN-Einträgen aufweist und die Empfängerdomäne nicht mit einem FQDN-Return übereinstimmt, wird eine MX-Abfrage von einer (unsicheren) DNS-Abfrage für eine Empfängerdomäne verwendet. Wenn keine Übereinstimmung besteht, werden keine weiteren Tests durchgeführt, keine PTR-Datensätze überprüft 
• Wenn CN des Antragstellers DN vorhanden ist (CN-ID):

  
  CN wird nur validiert, wenn dNSName nicht im Zertifikat vorhanden ist. Die CN-ID wird mit der unten stehenden Liste der zulässigen Referenzidentitäten verglichen.
  
  

  • exakte Übereinstimmung oder Platzhalterübereinstimmung für Empfängerdomäne erfolgt
  • Die exakte oder Platzhalterübereinstimmung erfolgt für den explizit konfigurierten Hostnamen in SMTPROUTES (*).
  • exakte Übereinstimmung oder Platzhalterabgleich für MX-Hostnamen, der von einer (unsicheren) DNS-Abfrage für den Empfänger-Domänennamen abgeleitet wurde

Explizit konfigurierte SMTPROUTES

Wenn die SMTP-Route konfiguriert wurde und die angegebene Identität nicht mit der E-Mail-Empfängerdomäne übereinstimmt, werden alle FQDN-Routennamen verglichen. Wenn sie nicht übereinstimmen, werden keine weiteren Prüfungen durchgeführt. Bei explizit konfigurierten SMTP-Routen wird davon ausgegangen, dass kein MX-Hostname mit einer angegebenen Identität verglichen wird. Die Ausnahme bildet hier eine SMTP-Route, die als IP-Adresse festgelegt wurde.

Bei explizit konfigurierten SMTP-Routen gelten die folgenden Regeln:

• Wenn eine SMTP-Route für eine Empfängerdomäne vorhanden und es sich um einen vollqualifizierten DNS-Domänennamen (FQDN) handelt, wird sie als Verweisidentität betrachtet. Dieser Hostname (ein Routenname) wird mit der dargestellten Identität verglichen, die von einem Zertifikat empfangen wird, das von einem Zielserver abgeleitet ist, auf den es verweist.

• Mehrere Routen für eine Empfängerdomäne sind zulässig. Wenn die Empfängerdomäne über mehr als eine SMTP-Route verfügt, werden die Routen verarbeitet, bis die vom Zertifikat des Zielservers angegebenen Bezeichner mit dem Namen der Route übereinstimmen, mit der die Verbindung hergestellt wurde. Wenn die Hosts in der Liste unterschiedliche Prioritäten haben, werden die Hosts mit der höchsten Priorität (0 ist die höchste und der Standardwert) zuerst verarbeitet. Wenn alle die gleiche Priorität haben, wird die Routenliste in der Reihenfolge verarbeitet, in der die Routen vom Benutzer festgelegt wurden.

• Wenn der Host nicht antwortet (nicht verfügbar) oder antwortet, die TLS-Verifizierung jedoch fehlgeschlagen ist, wird der nächste Host aus der Liste verarbeitet. Wenn der erste Host verfügbar ist und die Verifizierung besteht, werden die anderen nicht verwendet.

• Wenn mehrere Routen zu denselben IP-Adressen aufgelöst werden, wird nur eine Verbindung zu dieser IP hergestellt, und die dargestellte Identität, die von dem vom Zielserver gesendeten Zertifikat abgeleitet wird, muss mit einem dieser Routennamen übereinstimmen.

• Wenn eine SMTP-Route für Empfängerdomänen vorhanden, aber als IP-Adresse konfiguriert wurde, wird die Route weiterhin für eine Verbindung verwendet, aber eine präsentierte Identität aus dem Zertifikat wird mit der Empfängerdomäne und weiter mit dem Hostnamen verglichen, der vom DNS-/MX-Ressourceneintrag abgeleitet wird.

Wenn wir über die Option "TLS Required Verify" für gehostete Domänen sprechen, ist die Art und Weise, wie die ESA mit einem Zielserver verbunden ist, für den TLS-Verifizierungsprozess wichtig, da die explizit konfigurierten SMTP-Routen zusätzliche Referenzidentitäten bieten, die bei diesem Prozess berücksichtigt werden müssen.

~= steht für exakte Übereinstimmung oder Platzhalterübereinstimmung

Beispiel

Nehmen wir ein Beispiel aus dem wirklichen Leben, aber für die Empfängerdomäne: example.com. Im Folgenden habe ich versucht, alle Schritte zu beschreiben, die notwendig sind, um die Serveridentität manuell zu überprüfen. 

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

Hinweis: Die MX-Hostnamen und die revDNS-Namen stimmen in diesem Fall nicht überein.

$ 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   

•   präsentierte Identität: dNSName vorhanden (mit Vergleich mit zulässiger Referenzidentität fortsetzen)
  
  
  • Referenz-Identität = Empfängerdomäne (example.com) ist geprüft und stimmt nicht mit dem dNSName DNS:*.emailhosted.not, DNS:emailhosted.not überein
•   präsentierte Identität: KN vorhanden (fahren Sie mit der nächsten präsentierten Identität fort, da für die vorherige keine Übereinstimmung gefunden wurde)
  
  
  • Referenz-Identität = Empfängerdomäne (example.com) ist geprüft und stimmt nicht mit der CN *.emailhosted.not überein
    
    
  • Referenzidentität = PTR(IP) : Eine PTR-Abfrage wird mit der IP-Adresse des Servers durchgeführt, zu dem der TLS-Client (ESA) eine Verbindung hergestellt und ein Zertifikat empfangen hat. Diese Abfrage gibt Folgendes zurück: mx0a.emailhosted.not.
    
    
    • Die DNS-Konsistenz überprüft, um diesen Hostnamen als gültige Referenzidentität zu berücksichtigen:
      
      
      Konsistenz vorhanden: 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
      

    • Der Wert von mx0a.emailhosted.not. wird mit CN *.emailhosted.not verglichen und dort abgeglichen.

Der PTR-Domänenname validiert die Identität, und da es sich bei dem Zertifikat um ein CA-signiertes Zertifikat handelt, validiert es das gesamte Zertifikat und die TLS-Sitzung wird eingerichtet.

• präsentierte Identität: dNSName vorhanden (der CN wird in diesem Fall also nicht verarbeitet)
  • Referenzidentität = Empfängerdomäne (example.com) wird geprüft und
    stimmt nicht mit dNSName DNS:*.emailhosted.not überein, DNS:emailhosted.not
  • Referenzidentität = FQDN(smtp route) - Für diese Empfängerdomäne sind keine smtproutes vorhanden. 
    
    Da keine SMTPROUTES zusätzlich verwendet werden:
    
    
  • Referenzidentität = MX(Empfängerdomäne) - eine DNS-MX-Abfrage wird für die Empfängerdomäne ausgeführt.
    und ergibt: mx01.subd.emailhosted.not - dies entspricht nicht dem dNSName DNS:*.emailhosted.not, DNS:emailhosted.not
• präsentierte Identität: CN existiert, wird aber übersprungen, da dNSName ebenfalls existiert.