SMTP und MTLS
Wir nutzen alle täglich eine TLS-Verbindungen, um Datenübertragungen per HTTPS oder auch SMTPS abzusichern. Der Client fragt dabei eine TLS-Verbindung an und der Server sendet sein Zertifikat und einige andere Informationen mit. Deutlich seltener ist aber der Einsatzzweck, dass auch der Client ein Zertifikat nutzt, um sich am Server anzumelden. Bei Exchange Hybrid ist eine Authentifizierung per Zertifikat zwingend erforderlich. Exchange Online identifiziert sich dabei gegenüber dem lokalen Exchange Server, der dann entsprechende Header der Mail passieren lässt. Hier beschreibe ich die Punkte, auf die ihr in einem Netzwerk-Trace mit Wireshark achten könnte.
Exchange und MTLS
Wenn Sie Mails von Exchange Online zu einem Exchange OnPremises Server senden, dann fordert Microsoft eine transparente Verbindung ohne SSL-Inspektion, Offloading oder andere Veränderungen. Nur dann kann Exchange Online sich bei Exchange entsprechend authentifizieren. Der HCW - Hybrid Configuration Wizard konfiguriert für das Hybrid Mail Routing auf dem Default Frontend Connector ihres Exchange Servers folgende Einstellungen:
[PS] C:\>Get-ReceiveConnector "EX2016\Default Frontend EX2016" | fl
TlsCertificateName : CN=GlobalSign RSA OV SSL.....CN=hybrid.msxfaqdev.de, O=....
TlsDomainCapabilities : {mail.protection.outlook.com:AcceptCloudServicesMail}
Wenn sich die Gegenseite mit einem Zertifikat meldet, welches auf den Namen "mail.protection.outlook.com" ausgestellt ist, dann bekommt es die Berechtigung "AcceptCloudServicesMail" und wird als vertrauenswürdig angesehen, wenn der Absender aus ihrer Domain kommt und im Adressbuch bekannt ist. Sollte nun eine Firewall oder ein Loadbalancer aber irgendetwas an dem TLS-Handshake verändern, dann kommt zwar die Verbindung zustande, aber die Mail wird als "Extern" eingestuft. Der Absender bekommt nur externe OOF-Meldungen und Empfänger mit Empfangsbeschränkungen, z.B. Postfächer oder Verteiler kann er nicht anschreiben.
Exchange Online Tracking
Wenn ich eine Mail von Exchange Online nicht korrekt zu Exchange OnPremises zustellen kann, dann schaue ich erst einmal in das Messagtracking von Exchange Online, welche Connector Sie denn genommen hat. Das Exchange Admin Center liefert erste Hinweise aber erst in der Exchange Online PowerShell kann ich die gewünschten Informationen finden. Ich hole mir mit einem "Get-MessagetrackingV2 erst den Eintrag und dann mit Get-MessageTrackingDetailsV2 die Details und hier interessiert mich das Feld "Data"
Get-MessageTracev2 ` -Subject "test" ` -SubjectFilterType contains ` -ResultSize 1 ` | Get-MessageTraceDetailV2 ` -Event "Sendexternal" ` | fl data
Die Ausgabe verrät mir, ob und welche TLS-Version genutzt wurde, ob ich TLS erzwungen habe, welcher Connector und welcher Server ausgehend genutzt wurde und welche Gegenstelle ich erreicht habe.
Ich sehe aber nicht, on Exchange Online sein Client-Zertifikat gesendet hat.
Exchange OnPremises SMTPReceiveLogs
In meinem Fall habe ich dann im Exchange OnPremises Server die SMTPReceiveLogs kontrolliert und dort folgendes Verhalten gesehen:
Ich sehe die eingehende Verbindung mit der EHLO-Anfrage und mein Server antwortet auch brav mit STARTTLS aber dann kommt kein STARTTLS. Mein Verdacht war hier, dass ein System dazwischen meine Antwort verändert, um STARTTLS zu verhindern oder ein Offloading passiert. Nachdem dies dann korrigiert wurde, hat sich die Aussage etwas verändert. Ich sehen das STARTTLS aber dann immer noch kein Zertifikat ankommt
Anscheinend ist bei meinem Exchange Server immer noch kein ClientZertifikat angekommen. Daher hat Exchange Online nicht das "Vertrauen" erhalten, welches ich gerne hätte. Damit war meine Fehlersuche auf Exchange Online und Exchange OnPremises aber noch nicht vorbei.
Wireshark und STARTLS mit SMTP
In Exchange Online kann ich leider nicht mehr Informationen erhalten und ich muss einfach glauben, dass Exchange Online mir immer ein Client Zertifikat anbietet, wenn der Server es denn anfordert. Der Prozess für STARTLS/SMTP ist folgender. Wenn Sie eine direkte TLS-Verbindung zu Port 465 oder 443 aufbauen, dann beginnt die Kommunikation direkt bei 7. mit dem "Client sendet Client Hello". Der Test wurde mit OpenSSL und folgendem Aufruf durchgeführt.
.\openssl.exe s_client -starttls smtp -connect netatwork.mail.protection.outlook.com:25 -showcerts
Die Payload der Verbindung ist folgende:
Die Pakete bedeuten:
| Paket | Bedeutung |
|---|---|
1-3 |
Das ist der klassische TCP-Handshake zum Aufbau der Verbindung zum anderen System. Siehe dazu auch TCP SYN ACK RES |
4 |
SMTP ist eines der wenigen Protokoll, wo nicht der Client das erste Datenpaket sendet, sondern sich der Server aktiv meldet. |
5 |
Der Client sendet ein "EHLO", um auch die erweiterten Befehle zu erhalten. |
6 |
Der Server meldet sich u.a. mit einem STARTTLS. Das ist ein deutliches Zeichen, dass auf dem Weg vom Server zum Client keine Firewall das STARTTLS unterdrückt. Es könnte aber immer noch ein TLS-Offloading oder Inspection möglich sein. Eine Firewall kann auch selbst die Gegenstelle der TCP-Verbindung sein und sich ähnlich wie ein Exchange Server verhalten. |
7 |
Der Client sendet seinerseits STARTTLS, um auf eine verschlüsselte Verbindung zu wechseln. |
8 |
Der Server quittiert dies mit einem "220 2.0.0 SMTP server ready" und wartet auf den nun folgenden TLS Handshake |
9-11 |
Der Client startet die
Kommunikation mit einem
"Client Hello", in dem er
dem Server jede Menge
CipherSuites u.a. Optionen
anbietet: |
12-13 |
Der Server wählt nun aus dem Angebot eine passende Zusammenstellung aus und antwortet dem Client. Hier ist aber insbesondere die Option 13 interessant:
Diese Erweiterung teilt dem Client mit, dass er seinerseits in Client-Zertifikat senden darf. Der Server gibt dabei auch gleich die Zertifikattypen und möglichen Signatur-Algorithmen vor. |
14 |
Mein Client hat hier
kein Clientzertifikat. Daher
enthält die Antwort auf den
Server Hello zwar die
Struktur aber ist leer. Es obliegt nun dem Server zu überlegen, wie er mit einer Verbindung weiter umgeht, für die der Client kein Zertifikat gesendet hat. Wenn der eingehende Mailserver ein eigenes Zertifikat liefert, dann finden Sie dies bis TLS 1.2 im Trace lesbar. Hier am Beispiel von Exchange Online:
Hier ist gut zu sehen, dass das Client Zertifikat den Namen "mail.protection.outlook.com" enthält |
15 |
Danach kommt nur noch der Cipher Wechsel und die Encrypted Handshake Message, ehe es dann mit den Nutzdaten weitergeht. |
Für eine Untersuchung mit Wireshark ist der Server Hello und die Antwort des Clients am interessantesten. Natürlich habe ich auch auf einem Exchange OnPremises Server mal genau hingeschaut, wie sich Exchange Online bei dem Server meldet.
Exchange SMTP Tracing Hybrid
Der Vollständigkeit sehen Sie hier den Auszug aus dem Exchange OnPremises SMTP-Tracing. So sieht eine korrekt konfigurierte Hybrid-Verbindungen von Exchange Online zu Exchange OnPremises aus:
Exchange Online kommt mit dem EHLO an, welches der lokale Server u.a. mit einem STARTTLS-Angebot beantwortet. Damit ist sicher, dass es lokal ein gültiges Zertifikat gibt. Exchange Online fordert dann STARTTLS an und sie sehen in der Folge die beiden ausgetauschten Zertifikate. Wenn alles passt, dann wendet Exchange OnPremises die "TlsDomainCapabilities" an und bewertet die Mail als Internet.
