Verschlüsseln und Signieren auf dem Gateway - Signierter Versand

Beim Versand über ein Gateway betrachten wir zuerst einmal die Anforderung, jede Mail zu "signieren". Dazu muss man wissen, dass ein System ein Zertifikat für den Absender benötigt, um die Mail damit zu signieren. Ob die Mails mit dem Zertifikat dann auf dem Arbeitsplatz oder auf einem Gateway signiert wird, macht für den Empfänger dann keinen unterschied. Zur Signatur benötigt das signierende System aber Zugriff auf den privaten Schlüssel. Beim Einsatz auf einem Gateway muss daher der Schlüssel auf dem Gateway vorliegen. Wenn es mir als Angreifer von innen also gelänge, eine Mail mit einer anderen "Absenderadresse" einzuschleusen, dann würde das Gateway auch diese Mail signieren. Es ist daher wichtig, dass die Mails von innen nicht anonym angenommen werden und alle Zugangswege zum Mailserver geschützt sind. Die Thematik Senden als ist hier also sehr wichtig, damit intern niemand mit der "falschen" Absenderadresse Mails verwendet und die vom Gateway sogar noch signiert werden.

Etwas anders liegt der Fall, wenn die Mail zwar vom Benutzer gesendet wird, aber die Signatur mit einem anderen Zertifikat erfolgt. Es ist durchaus möglich, dass zur Signatur ein anderes Zertifikat zum Einsatz kommt.

Outlook

In Outlook 2007 kann man dies sogar sehr elegant sehen. Outlook "warnt" aber nicht deutlicher, wenn Signaturgeber und Absender nicht übereinstimmen. Zwischen Outlook 2007 und 2016 hat sich das Aussehen verändert aber es gibt keine Warnung

  • Outlook 2007
  • Outlook 365 (Click to Run Stand 27. Nov 2018)

Windows Live Mail

Anders sieht es z.B. mit Windows Live Mail (Unter Windows 7) aus. Wenn ich die gleiche Mail per IMAP4 abrufe, dann erhalte ich gleich mehrere Informations- und Warnungsfenster. Das erste Fenster informiert mich über die Bedeutung einer signierten Mail. Das ist schon mal lobenswert, dass Microsoft so eine Kurzeinweisung mitliefert. Wer zukünftig diese Meldung nicht mehr sehen will, kann dies per Checkbox sofort einstellen.

Sie sehen aber auch hier schon oberhalb der Mail, dass Absender und Signaturgeber nicht übereinstimmen. Möchte man die eigentliche Mail nun aber mit einem Klick auf "Weiter" lesen, dann kann Windows Mail einen unbedarften Anwender auch schon mal erschrecken: Aber auch diese Meldung erscheint nur bis sie unten über eine Checkbox auch diese explizite Warnung für die Zukunft abschalten und dann die Mail öffnen. Über die weiteren Funktionen kann man die Digitale ID oder auch den Vertrauensstatus anzeigen lassen. Allerdings gibt es keine Möglichkeit die Warnung ab oberen Teil abzuschalten, dass der Signaturgeber nicht mit dem Absender übereinstimmt. Das ist aber auch nicht weiter schlimm, gibt es doch den korrekten Sachverhalt wieder. Die Mail ist ja nicht durch den Anwender selbst, sondern durch das Gateway signiert worden.

Windows 10 Mail

Mit Windows 10 übernimmt eine neue MailApp die Funktion. Hier scheint SMIME gar kein Thema zu sein. Die Mail wird angezeigt und das SMIME-Attachment ist einfach eine Anlage

Es gibt zwar unter den Optionen eine Einstellung, dass ich per SMIME signieren und verschlüsselt könnte, aber die kann ich auf meines meiner Konten aktivieren.

Ein Blick in die Anleitung liefert dann auch die "Voraussetzungen" offenbart dann:

S/MIME ist für Exchange-Konten aktiviert (lokal und Office 365).
Benutzer können die S/MIME-Signierung und -Verschlüsselung nicht mit einem persönlichen Konto verwenden, z. B. Outlook.com.
Quelle: Konfigurieren von S/MIME für Windows 10 und Windows 10 Mobile (https://docs.microsoft.com/de-de/windows/security/identity-protection/configure-s-mime )

Anscheinend ist SMIME nur für Konten unterstützt, die mittels ActiveSync abgeglichen werden.

Da kann ich nur den Kopf schütteln, dass dieser Client den Support für SMIME an dem Übertragungsprotokoll fest macht. Es gibt technische keine Begründung dafür, denn die erhaltene bzw. gesendete Mail enthält die Signatur und ist Verschlüsselt. SMIME ist ja gerade unabhängig von der Transportverschlüsselung und vom Transportprotokoll.

Thunderbird

Der häufig Thunderbird unterstützt hingegen wieder SMIME. Allerdings wird die Signatur als ungültig angezeigt.

Das ist streng genommen natürlich auch richtig und zeigt die Problematik der Verschlüsselung von Benutzermails mit einem generischen Gateway-Zertifikat.

Zusammenfassung

Eine Lösung dieser Problematik und nur möglich, indem das Gateway letztlich für jeden Versender ein individuelles Zertifikat erstellt bzw. von einer CA anfordert und damit signiert und entschlüsselt. Technisch ist auch dies möglich wenn gleich ein solch automatisches Rollout von offiziellen Zertifikaten bestimmte Sicherheitsanforderungen erfüllen muss und natürlich auch eine Kostenfrage ist.

Den Ansatz von Windows 7 Mail finde ich natürlich schon bestechend. Der Benutzer sieht nicht die Mail sondern einen Erklärung, warum die Mail eventuell nicht authentisch ist und muss durch einen Klick bestätigen, dass er Sie lesen will.

Der Einsatz solcher "Gateway-Zertifikate" erlaubt eine relativ kostengünstige Signierung von Mails "als Gateway" ohne individuelle Zertifikate für jeden Absender zu erstellen. Leider gibt es keine Wildcard-Zertifikate "*@firma.tld" für diesen Zweck. Wenn eine Mail so signiert wird, dann können die meisten Anwendungsprogramme aber darauf nicht verschlüsselt antworten. In dem Beispiel würde eine Antwort an meine Mailadresse gehen, aber der Client findet kein passendes Zertifikat. Er hat nur ein Zertifikat für das Gateway. Diverse Gateways können aber auch in diesem Fall eine Mail an eine Person mit dem Zertifikat des Gateways verschlüsseln.