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. In Outlook 2007 kann man dies sogar sehr elegant sehen. Outlook "warnt" aber nicht deutlicher, wenn Signaturgeber und Absender nicht übereinstimmen.

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.

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.

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.