Verschlüsseln und Signieren auf dem Gateway - Probleme

Auch wenn PGP bzw. SMIME einen gewissen Standard darstellen, so knirscht es manchmal schon. hier ein paar Beispiele.

Signierte Terminanfragen mit Outlook und Exchange

Ein Problem kann bei der Nutzung der Terminfunktion von Outlook erfolgen. Wenn Sie eine Mail mit Outlook selbst senden, dann können Sie "signieren" einschalten. Wenn Sie aber einen Termin vereinbaren, kann können Sie diesen nicht signieren, selbst wenn Sie wollten.

Kommt nun ein Gateway mit ins Spiel, dann ist auch einer Einladung zu einem Termin einfach nur eine SMTP-Mail, die vom Gateway natürlich signiert wird. Wenn eine signierte Mail bei Outlook ankommt, dann funktioniert aber die Logik nicht mehr. Outlook "versteht" zwar, dass es sich um eine signierte Mail handelt, aber akzeptierte diese nicht als Termineinladung. Das gleich gilt für Zusagen, die auch signiert sein könnten. Je nach Formatierung der Mail erkennt Outlook diese als "IPM.Note.SMIME.MultipartSigned" oder als Termineinladung. Das Problem tritt aber nur auf, wenn Outlook die Mails z.B. per POP3 oder IMAP4 selbst abholt. Kommen die signierten Mails aber über Exchange herein, dann liest zumindest Exchange 2007 diese signierte Terminanfragen und bucht sie zum Teil schon im Kalender ein. Die Anfrage landet dann aber im Postfach ohne Signatur, so dass Outlook auch dies sauber erkennen kann. Allerdings ist es dem Anwender nicht mehr möglich, die Signatur zu prüfen.

Insofern sind auch hier Gateways sinnvoll, die Signaturen prüfen und bei ungültigen Signaturen z.B. warnen oder blockieren.

Man kann diese Mail sogar öffnen, aber sieht dann nur eine normale signierte Text-Mail:

 

Es gibt keine Optionen zum Zusagen und Absagen. Nutzt man dagegen auch hier ein Gateway, welches die Signaturen prüfen aber dann entfernt, dann kann Outlook die gleiche Mail wieder "verstehen".

 

Es ist also durchaus eine nützliche Funktion, die Signaturen von eingehenden Mails zu lesen, zu prüfen und dann zumindest bei Terminen zu entfernen. Den Fehler sehe ich hier aber natürlich bei Outlook. Es gibt keinen Grund, warum eine signierte Einladung oder signierte Zusage nicht akzeptiert werden sollte.

Verschlüsselter Versand an Empfänger ohne Zertifikat

Ein Gateway vereinfacht zwar den Einsatz von Verschlüsselung und Signatur in unternehmen aber nicht jede Gegenstelle ist soweit kompatible, dass das Gateway eine Mail immer verschlüsselt senden kann. Der Empfänger muss dazu einen öffentlichen Schlüssel bereit stellen oder der Mailserver per TLS erreichbar sein. Schreibt die Policy eine Verschlüsselung vor, dann darf das Gateway die Mail nicht unverschlüsselt senden. Die meisten Gateway bieten ein oder mehrere Alternativen an:

  • Mail ablehnen mit unzustellbarkeit an den Absender
    Da die Nachricht von "intern" gekommen ist, ist der Absender als gültig anzusehen und das Gateway kann eine unzustellbarkeitsmeldung generieren. So erfährt der Absender, dass seine Mail aufgrund der Richtlinien nicht weiter gesendet werden konnte. Das hilft dem Absender natürlich nicht und könnte ihn eher dazu veranlassen einen anderen unsicheren Kommunikationskanal zu wählen.
  • Mail mit Kennwort verschlüsseln und weitersenden, Kennwort an Absender
    Daher könnte das System die Mail z.B. in eine "verschlüsselte PDF"-Datei konvertieren oder als EML-Datei mit Kennwort "packen" und an den Empfänger weiter senden. Das Kennwort muss der Empfänger über einen anderen Weg erhalten, z.B.: indem das Gateway das Kennwort an den Absender sendet, welcher dann per Telefon den Empfänger darüber in Kenntnis setzen kann. Problematisch kann hier sein, dass die Teilnehmer nicht wissen, was sie tun müssen und eine verschlüsselte PDF-Datei nicht mehr die eigentliche Mail ist. Auch ein verschlüsseltes ZIP-File könnte beim Empfänger durch einen Spamfilter o.ä. blockiert werden oder ist vom Empfänger nicht einfach lesbar (z.B. auf einem Blackberry oder anderem mobilen Gerät.
  • Mail in einem "Gateway-Postfach" ablegen und dem Empfänger einen Zugriff drauf erlauben
    Wenn der Empfänger nicht verschlüsselt erreicht werden kann, dann kann die Mail auf dem Gateway zum Abruf bereit gehalten werden. Viele Lösungen bieten einen Weg an, dem Empfänger eine Informationsnachricht zu senden, dass eine verschlüsselte Mail zum Abruf wartet. Der Empfänger muss dann z.B. per Browser die Mail auf dem Gateway des Absender einsehen oder abholen, wozu er sich natürlich auch erst einmal legitimieren muss. Ich stelle es mir ziemlich unpraktisch vor, von mehreren Firmen derart Mails zu erhalten und auf jedem Gateway eine eigene Anmeldung nutzen zu müssen. Zudem besteht eine rechtliche Grauzone, ab wann die Mail dann als "Zugestellt" gilt und wie der Empfänger einer eventuell bestehenden Archivpflicht nachkommt, wenn die Mail nie per SMTP empfangen wurde.

Es gibt keinen Königsweg, wie mit dieser Problemstellung umzugehen ist. Jede Option hat ihre Vor- und Nachteile. Hinzu kommt, dass einige Gateways Mails mit PGP Verschlüsseln und Signieren und damit dem Empfänger die Installation von Zusatzkomponenten aufzwingen. Andererseits ist es für Empfänger nicht immer einfach, ein Zertifikat auf dem Arbeitsplatz zu installieren und entsprechend zu sichern. Geht dieses Zertifikat verloren (z.B. PC Neuinstallation) dann ist kein Zugriff mehr auf mit dem Public Key verschlüsselte Mails möglich-. Viele Firmen blocken z.B. signierte und verschlüsselte Mails, damit die Anwender eben nicht selbständig auf dem Arbeitsplatz verschlüsseln und signieren.

Warnungen bei Empfängern

Nicht alle Mailsystem können mit Gateway-Signaturen umgehen bzw. warnen natürlich zurecht. Hier am Beispiel von Windows Live Mail, einem klassischen Privatkundenprogramm. Korrekterweise zeigt es an, dass die Signatur mit einem vertrauenswürdigen digitalen ID erstellt wurde aber der Signaturgeber natürlich nicht mit dem Absender übereinstimmt.

Schöner wäre hier natürlich, wenn die Warnung nicht ganz so "bedrohlich" erscheinen würde, wenn die Domain des Signaturgebers und des Absender übereinstimmen. in den Details kann der Anwender sich dann die Signatur auch genauer anschauen.

Hier gibt es dann plötzlich keine sichtbare Warnung mehr. Alles schein "ok" zu sein.

Risiko SMTP-Relay

Der Einsatz eines Gateways ist "bequem", da die komplette Funktion Signatur und Verschlüsselung von Client auf das Backend verlagert wird. Eine Firma kann ihr System so betreiben, das das interne System als "sicher" angesehen wird und alle Nachrichten intern unverschlüsselt übertragen werden. Es gibt keine Abhängigkeiten von Clients, Betriebssystemen und Versionen. Stellvertreter und Weiterleitungen funktionieren ebenso wie Archivierung, Auswertungen und automatische Verarbeitungen. Zugriffe per Browser (OWA) oder mobile Geräte (Blackberry, ActiveSync etc.) sind problemlos möglich.

Aber sind sie sicher, dass sie "sicher" sind ?. Das Crypto-Gateway kann so konfiguriert werden, dass es nur Mails vom internen Mailserver annimmt und Quereinsteiger zuverlässig unterbindet. Aber wie sicher ist ihr Mailsystem geben einen internen Relaymissbrauch? natürlich betreibt heute hoffentlich niemand mehr ein "offenes Relay" im Internet. Selbst wenn, würde dieses System sehr schnell auf den einschlägigen Blocklisten erscheinen und zurecht ausgegrenzt werden.

Aber viele Firmen erlauben internen Clients sehr wohl die Verbindung zum Mailserver per SMTP und nehmen die Mails an. Einige ältere Server sind vermutlich sogar noch als Relay konfiguriert, d.h. Sie leiten die Mails auch in das Internet weiter. Oft ist dies gewünscht, z.B. damit ein SAN-Storage eine Fehlermeldung an den Dienstleister senden kann. Es wäre für jemanden daher sehr einfach, eine Mail mit einem gefälschten Absender an ihr internes Mailsystem zu senden. Beim externen Empfänger würde dann sogar eine digital signierte Mail ankommen. Er geht zurecht davon aus, dass die Mail authentisch ist.

Wer nun seine Mailserver mit eine Authentifizierung auch von intern absichert, verhindert zwar den anonymen Versand von Mails über den Server aber nicht alle Mailserver prüfen, ob die verwendete Absenderadresse auch zum angemeldeten Benutzer passt. Bei Exchange ist die erst ab Exchange 2007/2010 möglich. Aber auch dann wird es immer wieder Prozesse geben, die im Auftrag des Benutzers Mails versenden müssen und sich mit einem Dienstkonto authentifizieren.

Aber auch die Authentifizierung ist eine mögliche Schwachstelle, da eine Anmeldung per SMTP meist im Klartext erfolgt. Nicht jeder Client und Server unterstützt eine starke Authentifizierung (NTLM oder Kerberos) und nicht jeder Anwender verwendet STARTTLS um die Verbindung insgesamt zu verschlüsseln. Spätestens wenn ein Multifunktionsgerät eingescannte Dokumente per Mail ohne Authentifizierung und SSL versenden will, werden die ersten Löcher in den Mailserver gebohrt.

Vor der Inbetriebnahme eines Gateways ist es daher unerlässlich, dass die komplette interne Mailserverstruktur auf ihre Vertrauenswürdigkeit untersucht wird und es keinen Zugang gibt, über den ein Angreifer, Virus, Trojaner, Anwender, Gast etc. eine Mail mit einem gefälschten Absender zum Versand über das Gateway einliefern kann. Dies kann durchaus mit einem kostenintensiven Update der verwendeten Server, Clients oder Anwendungen verbunden sein.

Mailgrößen

In Verbindung mit signierten Mails kann es durchaus auch Verwirrung bei den "Größen" geben. Outlook zeigt die Größe der Mail ohne die angehängten Signaturen an. Die P7B und P7S-Dateien werden  einfach in der Größe unterschlagen. Aufgefallen ist dies z.B. bei einer Mail, die vom Absender mit einem Astaro-Gateway signiert wurden. Bestimmte Versionen haben an die Mail zusätzlich alle vertrauenswürdigen Stammzertifizierungsstellen gehängt. (gefixt seit Version 7.502). So wurde aus einer Mail, die Windows Live Mail mit 6 KB anzeigt, in Realität ein 317kB Monster:

Bei aller Intelligenz der Mailprogramme sollte die Signatur nach meiner Meinung nicht ganz "unerreichbar" für den Anwender sein. Schließlich schlägt sie sich auf auf seiner Quota nieder.