Sophos Email: TLS und Secure Message sicher konfigurieren

Eine Secure Message policy legt fest, wie Sophos Email Nachrichten absichert und was geschieht, wenn die gewählte Methode nicht möglich ist. Für die meisten TLS-Verbindungen ist Preferred TLS 1.3 der robuste Ausgangspunkt: Sophos versucht TLS 1.3 und wechselt bei Bedarf zu TLS 1.2. Required TLS 1.3 oder Required TLS 1.2 sollte man nur für Partner erzwingen, deren empfangendes beziehungsweise sendendes System genau diese Anforderung nachweislich erfüllt.

Schnellweg: Zuerst TLS 1.3 und die benötigten Cipher auf dem eigenen Mailserver oder Maildienst aktivieren und den Mailfluss zu Sophos testen. Danach unter My Products > Email Security > Policies eine Policy vom Typ Secure Message erstellen, internen und bei Bedarf externen Scope festlegen, unter Settings die Richtung und Methode wählen und mit einer kleinen Pilotgruppe auf Policy is enforced setzen. Für ausgehende Nachrichten vorab entscheiden, ob ein TLS-Fehler unverschlüsselte Zustellung erlauben oder mit Fallback to push encrypt the entire message abgefangen werden darf. Anschliessend pro Partner und Richtung in Message History TLS-Version und Zustellstatus prüfen.

Warnung: TLS muss auf dem eigenen Mailserver oder Maildienst aktiv sein, bevor eine Secure-Message-Methode konfiguriert wird. Vor Required TLS 1.3 muss insbesondere das eigene E-Mail-Gateway TLS 1.3 unterstützen. Andernfalls kann die Verbindung zu Sophos abbrechen und ein- wie ausgehende E-Mail ausfallen.

Vor der Änderung Voraussetzungen und Rückweg sichern

Die Anleitung gilt für Sophos Email in Sophos Fusion (ehemals Sophos Central), nicht für die On-Box Mail Protection einer Sophos Firewall. Im EMS mode lassen sich Secure Message Policies nicht konfigurieren.

Vor dem Change hält man fest:

aktuellen Policy-Namen, Scope, Reihenfolge, Richtung, Enforcement-Status und einen gegebenenfalls gesetzten Deaktivierungszeitpunkt;
interne Benutzer, Gruppen oder Domains und die betroffenen externen Adressen beziehungsweise Domains;
TLS-Versionen und Cipher des eigenen Mailservers sowie der Pilot-Gegenstellen;
ob die Gegenstelle ein Zertifikat für ihre Empfängerdomain vorlegt;
zugelassene Fallback-Entscheidung je Kommunikationspartner;
Testsender, Testempfänger, Message-IDs, Change-Fenster und Owner beider Mailplattformen.

Sophos empfiehlt TLS 1.3. Der dokumentierte Cipher-String lautet exakt TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 und TLS 1.1 werden seit dem 1. Januar 2024 weder für eingehende noch für ausgehende E-Mail-Zustellung unterstützt. Der eigene Server darf daher nicht auf diese alten Versionen beschränkt sein.

Für den Rückweg sichert man Screenshots oder Exportdaten der bisherigen Policy. Eine neue oder geklonte Pilot-Policy kann man auf Policy Bypassed zurücksetzen und die vorherige Reihenfolge wiederherstellen. Eine bestehende funktionierende Policy wird nicht gelöscht, bevor alle Tests abgeschlossen sind.

Methode und Fehlerverhalten bewusst wählen

TLS: Transportverschlüsselung im normalen E-Mail-Client

Secure using TLS schützt die SMTP-Verbindung während des Transports; Absender und Empfänger arbeiten weiterhin in ihrem üblichen E-Mail-Client. Die Auswahl bedeutet nicht, dass die Nachricht nach der Zustellung im Postfach dauerhaft in einem verschlüsselten Container liegt.

Die TLS-Stufen haben unterschiedliche Folgen:

Preferred TLS 1.3 versucht TLS 1.3 und verwendet TLS 1.2, wenn die Gegenstelle TLS 1.3 nicht unterstützt. Sophos empfiehlt diese flexiblere Auswahl, weil sie seltener den Nachrichtenaustausch unterbricht.
Required TLS 1.3 akzeptiert nur TLS 1.3. Unterstützt die Gegenstelle diese Version nicht, wird die Nachricht nicht über eine andere TLS-Version ausgetauscht.
Required TLS 1.2 akzeptiert nur TLS 1.2. Auch TLS 1.3 ist dann kein Ersatz; die festgelegte Version wird erzwungen.

Ohne eine solche Erzwingung versucht Sophos standardmässig TLS, wenn eine TLS-Verbindung möglich ist. Das ist opportunistisches Verhalten: Es bietet Kompatibilität, aber keine Garantie, dass jede Gegenstelle verschlüsselt erreicht wird. Sobald eine bestimmte Version oder Zertifikatsprüfung Vertragsanforderung ist, benötigt der Partner einen eng begrenzten Required-Scope und einen dokumentierten Fehlertest.

Bei Required TLS 1.3 oder Required TLS 1.2 kann man für ausgehende Verbindungen zusätzlich Verify certificate aktivieren. Sophos prüft dann, ob das Zertifikat für die Empfängerdomain ausgestellt wurde. Schlägt diese Prüfung fehl, wird nicht zugestellt. Deshalb setzt man in den externen Scope die tatsächliche Empfängerdomain und prüft, welchen Host und welches Zertifikat deren MX-Pfad präsentiert; eine ähnlich geschriebene Partnerdomain ist kein Ersatz.

Push Encryption und Portal Encryption nicht mit TLS verwechseln

Push Encryption ist nur ausgehend verfügbar. Sophos wandelt den Nachrichteninhalt in eine passwortgeschützte Dokumentdatei um; Microsoft-Office-, ZIP- und PDF-Anhänge verwenden ihre native Verschlüsselung, andere Formate können als PDF bereitgestellt werden. Der Empfänger richtet beim ersten Mal über die Benachrichtigung ein Sophos-Secure-Message-Passwort ein. Deren Link läuft nach 30 Tagen ab. Das Passwort gilt nur für Nachrichten aus derselben Region wie die ursprüngliche Nachricht. Das Öffnen beim Empfänger, die Passwortverwendung und die sichere Antwort beschreibt Sophos Email Portal- und Push-Verschlüsselung betreiben.

Portal Encryption ist ebenfalls nur ausgehend verfügbar und benötigt eine Sophos-Email-Lizenz mit Portal Encryption Add-on. Der Empfänger liest und beantwortet die Nachricht in Sophos Secure Message und legt bei der ersten Nachricht ein Konto an. Branding, Empfängeradministration, Ablauf und Recall sind ein eigener Portal-Betriebsablauf; dieser Artikel wählt die Methode lediglich in der Policy aus.

Secure using S/MIME setzt vorab eingerichtete CAs, Benutzer- und Empfängerzertifikate sowie private Schlüssel voraus. S/MIME kann signieren, ohne zwingend zu verschlüsseln. Zertifikatsbereitstellung, Trust, Extraktion und Reset gehören deshalb in einen separaten S/MIME-Ablauf und werden nicht durch Verify certificate für TLS ersetzt.

Für ausgehendes TLS bietet Sophos bei einer nicht TLS-fähigen Gegenstelle Allow unencrypted delivery oder Fallback to push encrypt the entire message an; Sophos empfiehlt den Push-Fallback. Ist der Push-Fallback konfiguriert und schlägt die TLS-Aushandlung fehl, sendet Sophos die Nachricht per Push Encryption, statt sie für weitere TLS-Zustellversuche in die Queue zu stellen. Unverschlüsselte Zustellung wählt man nur, wenn die Datenklassifikation dies ausdrücklich erlaubt. Push-Fallback ist nur passend, wenn Empfänger passwortgeschützte Dokumente öffnen dürfen und der Prozess für Erstregistrierung akzeptiert ist. Gibt es weder einen erlaubten Fallback noch eine funktionierende TLS-Aushandlung, darf man keinen stillen Klartext-Rückfall erwarten.

Secure Message Policy erstellen und eingrenzen

Man öffnet My Products > Email Security > Policies und klickt auf Add Policy.
Man wählt Secure Message und Continue und vergibt einen eindeutigen Namen, zum Beispiel SM-Outbound-Partner-TLS13.
Unter Internal fügt man Benutzer, Gruppen oder Domains hinzu. Ein Treffer in einer dieser Listen genügt. Beim Überfahren eines Benutzernamens kann man dessen E-Mail-Adresse kontrollieren.
Bei einer partnerspezifischen Regel öffnet man External und fügt die genaue E-Mail-Adresse oder Domain manuell oder per Datei hinzu. Man prüft, ob die Liste eingeschlossen oder ausgeschlossen wird; der Standard ist Include all. Die Policy gilt, wenn ein interner Eintrag mit einem externen Eintrag kommuniziert.
Unter Settings wählt man Inbound oder Outbound und aktiviert Secure inbound messages beziehungsweise Secure outbound messages.
Unter Select the method to secure messages wählt man die freigegebene Methode. Für TLS setzt man danach Preferred TLS 1.3, Required TLS 1.3 oder Required TLS 1.2.
Bei Required TLS für ausgehende Partner aktiviert man bei Bedarf Verify certificate. Fallback beziehungsweise Fehlerverhalten legt man ausdrücklich fest und leitet es nicht vom Namen der Policy ab.
Bei Push oder Portal Encryption wählt man die Sprache der Benachrichtigungs- und Registrierungsnachrichten für die Empfänger.
Unter Choose how to secure legt man fest, ob alle Nachrichten geschützt werden oder Benutzer dies über einen Subject-Tag auslösen. Der feste Standard-Tag secure: löst die Verschlüsselung immer aus, auch wenn eigene Trigger definiert sind. Eigene Trigger wie secureTest: oder secureFull: müssen vollständig und exakt am Anfang des Betreffs stehen; ein Teilstring genügt nicht.
Man setzt die Pilot-Policy auf Policy is enforced, speichert sie und kontrolliert ihre Priorität. Optional kann man Datum und Uhrzeit für die automatische Deaktivierung setzen.

Für mehrere ähnliche Scopes kann man eine Policy mit Clone kopieren. Ein Klon steht zunächst auf Policy Bypassed, ein Klon der Base Policy besitzt noch keine Benutzer, Gruppen oder Domains, und der Klon erhält standardmässig Vorrang vor dem Original. Scope, Einstellungen und Reihenfolge müssen daher vor Policy is enforced geprüft werden.

Bereits migrierte Tenants können Policies sehen, deren Name mit Migrated beginnt. Sie enthalten die früheren TLS- und Verschlüsselungseinstellungen aus Global Settings und die damals geschützten Benutzer und Domains. Man darf sie bearbeiten, umbenennen, zusammenführen oder löschen, aber erst nach einem Vergleich von Scope, Methode, Fallback und Priorität mit dem heutigen Sollzustand.

Wechselwirkung mit Data Control

Eine ausgehende Verschlüsselungsaktion in einer Data Control Policy überschreibt die in der Secure Message Policy gewählte Verschlüsselungsmethode. Wenn eine Nachricht unerwartet per Push oder Portal statt per TLS verarbeitet wird, prüft man deshalb nicht nur die Secure Message Policy, sondern auch passende Data-Control-Regeln. Scope und Reihenfolge prüft man getrennt, weil die Policy-Familien unterschiedliche Aufgaben erfüllen.

Mit repräsentativen Empfängern validieren

Für die Abnahme sendet man kontrollierte, nicht vertrauliche Nachrichten an mindestens einen Empfänger im Policy-Scope und einen Vergleichsempfänger ausserhalb. Bei einer partnerspezifischen TLS-Regel gehören folgende Fälle in den Testplan:

Gegenstelle unterstützt die ausgewählte TLS-Version und präsentiert bei aktivem Verify certificate ein passendes Zertifikat;
Gegenstelle unterstützt TLS 1.2, aber nicht TLS 1.3, um Preferred TLS 1.3 kontrolliert zu prüfen;
freigegebener Negativtest mit nicht erfüllter TLS- oder Zertifikatsanforderung;
bei konfiguriertem Push-Fallback ein Empfänger, der Benachrichtigung, Passwortanlage und Öffnen der Nachricht vollständig testet;
bei Subject-Tags je eine Nachricht mit exaktem Trigger, unvollständigem Trigger und ohne Trigger.

In Message History öffnet man links Filter, wählt die Kategorie Secure message und grenzt nach TLS-Version ein. Danach öffnet man den Betreff. In Message Details zeigt das Überfahren der Ellipse mit drei Punkten unter Status, ob die Verbindung mit TLS gesichert wurde und welche TLS-Version authentifiziert wurde. Wenn Sophos die Signatur der ausstellenden CA nicht prüfen konnte, nennt SMTP Text die TLS-Zustellung nicht vertrauenswürdig.

Eine erfolgreiche Abnahme dokumentiert Policy-Name und -Priorität, interne und externe Scope-Werte, Message-ID, Zeitstempel, Empfänger, gewählte Methode, beobachtete TLS-Version, Zertifikatsergebnis, Fallback und endgültigen Empfängerstatus. Ein Eintrag in Message History allein beweist nicht, dass der Empfänger die Nachricht lesen konnte.

TLS-Fehler, Queue und Zertifikate untersuchen

Kann Sophos Email eine erforderliche TLS-Verbindung nicht herstellen und greift kein konfigurierter Fallback, wird die E-Mail nicht gesendet. Sophos stellt sie bis zu sieben Tage zur erneuten Zustellung in die Queue und löscht sie danach. Jeder TLS-bedingte Sendeversuch erzeugt einen History-Eintrag im Format Processing: Check TLS; nach dem letzten Fehler wird protokolliert, dass die Nachricht wegen der TLS-Policy gelöscht wurde. Das ist kein geeigneter Mechanismus, um eine falsche Required-Konfiguration sieben Tage lang produktiv zu testen.

Man prüft in dieser Reihenfolge:

Ist die erwartete Secure Message Policy auf Policy is enforced, hat sie den richtigen internen und externen Scope und steht sie an der beabsichtigten Stelle?
Überschreibt eine Data-Control-Aktion die Methode oder löst der feste Tag secure: eine Verschlüsselung aus?
Unterstützen eigener Mailserver und Gegenstelle die ausgewählte Version? TLS 1.0 und 1.1 sind kein Fallback.
Sind TLS und die benötigten Cipher aktiv, insbesondere der dokumentierte String TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL?
Passt bei Verify certificate das präsentierte Zertifikat zur tatsächlichen Empfängerdomain, und kann Sophos die ausstellende CA prüfen?
Zeigen Message History, Processing: Check TLS und SMTP Text einen Versions-, Trust- oder Aushandlungsfehler?

Bleibt der Fehler offen, sammelt man Policy-Name, Scope, Priorität, Message-ID, Zeitstempel, Richtung, Empfängerdomain, erwartete und beobachtete TLS-Version sowie die relevanten History- und SMTP-Texte für Sophos Email Support. Private Schlüssel, Passwörter und vertrauliche Nachrichteninhalte gehören nicht in das Ticket.

Sicher zurückrollen

Bei unerwartetem Mailfluss setzt man zuerst die neue Policy auf Policy Bypassed oder nutzt den vorbereiteten Deaktivierungszeitpunkt und stellt die frühere Priorität wieder her. Danach sendet man erneut in beide Richtungen und bestätigt den bisherigen Pfad in Message History und beim Empfänger. Man lockert nicht gleichzeitig TLS-Version, Zertifikatsprüfung und Scope; sonst bleibt die Ursache unklar.

Ein temporärer Fallback auf Preferred TLS 1.3, Push Encryption oder unverschlüsselte Zustellung ist nur zulässig, wenn Daten-Owner und Change-Verantwortliche genau diese Variante freigegeben haben. Ist Klartext nicht erlaubt, bleibt die Nachricht besser angehalten, während der Partner seine TLS-Version, Cipher oder Zertifikatskette korrigiert. Erst nach erfolgreichem Pilot- und Negativtest wird der Scope erweitert oder eine alte Migrated Policy bereinigt.