S/MIME und/oder Sandbox-Erweiterung

[Hunduster]

Hallo zusammen,

ich sehe mich aktuell vor einem großen Problem stehen:

Wir sind mitten in der Migration von Sophos UTM auf Fortinet.

Hierzu haben wir uns Anfang 2022 von einem Systemhaus beraten lassen und neben Fortigate auch Fortimail (200F) und Fortisandbox bestellt. Durch den Corona-Effekt konnte Fortinet erst Anfang 2023 liefern. Nun befinden wir uns mitten im Migrations-Projekt und mussten feststellen, dass die Fortimail in Summe nur 10 S/MIME bzw. PGP Zertifikate händeln kann/will.

Wir dachten, dass dies ein Lizenzthema wäre und man die Anzahl an Zertifikaten erhöhen könnte, leider ist dem nicht so; wir müssten auf die nächst größere Appliance wechseln, was bei redundanter Auslegung gut 30TEUR kosten würde. Und auch die Fortimail 400F kann dann „nur“ 100 Zertifikate verwalten - was ich nun angesichts des Preises auch nicht viel finde.

Wir sind aktuell um die 180 Mitarbeiter verschlüsseln aber nur etwa 5% unserer Mails mittels S/MIME - immer nur dann, wenn die Kunden (meist aus dem Finanzsektor) vehement auf S/MIME bestehen.

Aktuell bin ich etwas am verzweifeln, da die Sophos UTM eine Eierlegende Wollmilchsau war und es offenbar kein Produkt auf dem Markt gibt, was all unsere Kriterien erfüllt (MTA, AntiSPAM/Antivir/Encryption/Sanbox). Wie ich es drehe und wende muss ich immer irgendein Drittprodukt als weiteren Hop dazwischen klemmen.

Privat bin ich vor einigen Monaten von Sophos UTM zu OPNsense und PMG gewechselt und bin mega Happy mit der Lösung von PMG. Daher wäre meine Frage, ob jemand schon einmal das PMG um die Themen S/MIME und ggf. auch Sandbox erweitert hat. Wir wären definitiv bereit im Mail Bereich von Fortinet weg zu gehen.

 

[floh8]

Sophos zu ersetzen ist wahrlich nicht einfach, aber der richtige Weg. Sucht euch doch eine andere Lösung im Markt. Ich denke da an
XnetSolution, proofpoint
NoSPAMProxy, Reddoxx
.....um einige zu nennen.

 

[Hunduster]

Danke, das Reddoxx werde ich mir mal genauer ansehen. Finde es schade, dass PMG die Funktion leider nicht anbietet.

 

[floh8]

Ich sehe es auch so, dass es bei PMG noch viel Entwicklungspotential nach oben gibt, wie PGP/SMIME, Sandbox, Archiv......

 

[tom]

Um Emails mit S/MIME oder PGP Verschlüsselung zu verwenden (end-to-end), braucht man weder Sophos noch Fortinet noch Proxmox Mail Gateway. (Private Keys der User am Gateway zu speichern ist der falsche Ansatz).

Viel besser:
End-to-end Verschlüsselung am Ende (also beim User im Email Client).

Spart euch das Geld für teure Gateways und macht stattdessen Schulungen für euer User, wie man sowas richtig benutzt.

Thunderbird kann S/MIME und PGP gut verwalten, auch bei MS Outlook geht zumindest S/MIME sehr einfach.

 

[floh8]

Ich denke, auf den ersten Blick scheint End-to-End die einfacherer Lösung zu sein.
Ich habe damals, wo Sophos mit einer der Ersten war, die das SSL-Aufbrechen beim WEb-Proxy umgesetzt hatten, die AV-SSL Überprüfung implementiert. Die administrative Pflege, die damit einher kam, würde mich heute dazu bewegen, es eher dem Client zu überlassen. Zumal Spam heutzutage beim Surfen anders blockierbar ist.
Bei Spam-Mails sehe ich es allerdings nicht so. Der Mailheader reicht nun mal nicht aus, um sehr gute Spamerkennung zu gewährleisten. Einen verschlüsselten Mailbody kannste nunmal nicht scannen. Hier sehe ich die zentrale Lösung als sinnvoller an. Klar kann man jetzt sagen, dass die Mails auch am Client auf Spam gescannt werden können oder der Mailserver bringt es mit. Dann bist du aber wieder auf bestimmte Lösungen und Programme angewiesen, die das in der Kombination unterstützen und dezentrale Clients sind schwierig mit SPAM-Regeln zu konfigurieren. Was machste mit einem Webmailer, wenn der Server es nicht unterstützt. Und wie flexibel ist die SPAM-Konfiguration am Server. Habe ich da so viel Einstellungen wie am PMG usw. usw. Ich denke viele, die jetzt den PMG einsetzen, sind mit der SPAM-Lösung ihres Servers nicht zufrieden gewesen.

 

[tom]

Ihr bekommt wirklich mit dem S/MIME oder PGP verschlüsselte Email SPAM?

 

[floh8]

Ich kann nicht aus Erfahrung sprechen, wie hoch das SPAM-Aufkommen bei verschlüsselten Mails ist. Was ich aber absehen kann, ist, wenn die öffentlichen Schlüssel öffentlich im Internet zugänglich gemacht werden, dann werden diese auch die Spammer nutzen. Natürlich.

 

[tom]

Ok, also eine Vermutung.

Der Aufwand für das generieren solcher Spamemails ist für den Versender sehr hoch, und man muss die Keys ja auch nicht öffentlich zugänglich machen.

 

[floh8]

Zwischen Absehen und Vermuten würde ich einen größeren Unterschied sehen.
Viele Sicherheitsexperten im Internet meinen ja , dass die Verschlüsselung die Spamflut eindämmen würde, wenn sie nur immer genutzt werden würde. Also ich kann auch absehen, dass eine flächendeckende Nutzung nie eintreten wird. Ich sehe auch kein Problem für die Spammer verschlüsselte und signierte Mails zu versenden. PMG sollte, auch wenn es keine Zertifikate verwaltet, auf jeden Fall Spamregeln anbieten, die bestimmte Verschlüsselungskonstellationen überprüfen bzw. als SPAM definieren können. Z.B.
- s/mime verschlüsselte Mails, die nicht signiert sind, as SPAM deklarieren
- nicht signierte Mails als Spam deklarieren
- self-signed certificate als SPAM deklarieren
- etc.

 

[Hunduster]

Um Emails mit S/MIME oder PGP Verschlüsselung zu verwenden (end-to-end), braucht man weder Sophos noch Fortinet noch Proxmox Mail Gateway. (Private Keys der User am Gateway zu speichern ist der falsche Ansatz).

Viel besser:
End-to-end Verschlüsselung am Ende (also beim User im Email Client).

Spart euch das Geld für teure Gateways und macht stattdessen Schulungen für euer User, wie man sowas richtig benutzt.

Thunderbird kann S/MIME und PGP gut verwalten, auch bei MS Outlook geht zumindest S/MIME sehr einfach.

Ich verstehe deinen Gedanken dahinter und der ist, technisch, auch vollkommen richtig. Eine End-zu-End Verschlüsselung macht nur Sinn, wenn die Verschlüsselung bis zum Endgerät geht, alles andere ist nonsense.

Das Problem ist nur, dass die Gateway-Lösung einfach mittlerweile das ist, was die Benutzer erwarten, denn sie wollen mit nichts was zu tun haben. Zu Outlook kämen ja noch Geräte wie iPhones und iPads die konfiguriert werden wollen. Auch unsere Kunden, die nach SMIME schreien, setzen auf Gateway-Lösungen. Das Problem ist nur, dass sie meist ihre Systeme und damit insbesondere die Verschlüsselung nicht im Griff haben und nicht einsehen wollen, dass eine ordinäre TLS Verschlüsselung es bei dem Vorgehen genauso gut tun würde.

Das nächste Problem was ich aber bei End-to-End sehe: E-Mail Archivierungspflicht. Die einzige anerkannte Methode in DE zur revisionssicheren Archivierung ist das Journaling. Entschlüssle ich die Mail erst am Client, und verschlüssle sie bereits am Client, kann die die Mails nicht archivieren und verstoße somit gegen meine Archivierungspflicht.

Hinzu kommt, dass wir bisher auch nie öffentliche Zertifikate genutzt haben/nutzen mussten. Wir haben nur für SMIME eine eigene CA erstellt und dem Kunden die CA nebst den User Certs geschickt. Hat auch nie jemanden interessiert.

Ich weiß, dass Proxmox die Meinung vertritt, dass die Verschlüsselung am Client stattfinden muss (habe das hier schon öfters gelesen). Ihr habt auch wirklich vollkommen recht nur ob das immer praktikabel ist, ist halt die Frage.

Ich sehe es wie @floh8, dass Ihr eigentlich, gerade mit der Untergang der Sophos UTM nun eine wirkliche Marktlücke schließen könntet, denn bisher hat hier niemand eine „sexy“ Alternative am Start. Zumindest aber wäre es hilfreich, wenn man die Möglichkeit hätte, Themen wie Ver-/Entschlüsselung und ggf. auch das Sandboxing irgendwie sauber an PMG anbinden zu können - Ciphermail, Cuckoo etc.

Ich kam auf PMG weil es für mich, von der UTM kommend, ein MTA ist, wie ich ihn kannte und mir vorstelle. Das wird anderen mit Sicherheit auch so gehen. Ich kenne zumindest keinen UTM Admin, der bei Sophos bleibt und auf deren neuen Produkte umsteigt. Alle gehen zu Forti, Palo oder OPN und suchen für die verbleibenden Funktionen eben Alternativen.

 

[tom]

Ich sehe auch kein Problem für die Spammer verschlüsselte und signierte Mails zu versenden.

PGP und S/MIME sind ja keine neuen Technologien. Aber bisher hab ich noch keinen signierten und verschlüsselten Spam gesehen. Daher die Frage an die Community - hat wer sowas?

 

[floh8]

Ich vermute, dass das Spamaufkommen für verschlüsselte Mails gering bis gar nicht vorhanden sein wird. Ist auch logisch. Die Spammer werden erst auf diesen Zug aufspringen, wenn sie mit "normalen" Mails kein Erfolg mehr haben. Denn wie du schon andeutest. Es ist ein Mehraufwand für sie, den sie sich natürlich erstmal nicht antuen werden.
Wenn ihr bestimmte Funktionen weglasst, dann könntet ihr ins Hintertreffen geraten, denn Admins versuchen natürlich möglichst eine Lösung zu implementieren und nicht mehrere. Wenn andere es anbieten, wird euer Produkt unattraktiv. In Themen wie Sicherheit sind auch die Entscheider heutzutage gewillt, mehr zu bezahlen. Euer Preisvorteil ist dann nicht mehr Kaufkriterium.

Das nächste Problem was ich aber bei End-to-End sehe: E-Mail Archivierungspflicht. Die einzige anerkannte Methode in DE zur revisionssicheren Archivierung ist das Journaling. Entschlüssle ich die Mail erst am Client, und verschlüssle sie bereits am Client, kann die die Mails nicht archivieren und verstoße somit gegen meine Archivierungspflicht.

Ich weiß nicht, wie da die Vorgaben sind, aber ich habe mir auch schon überlegt, dass das ein Problem darstellt, wenn ich verschlüsselte Mails archivieren will. Wenn ich sie verschlüsselt archiviere, dann kann ich nicht drin suchen. Das macht natürlich keinen Sinn. Archivierungslösungen müssten dann, z.B. eine Funktion einbauen, dass man private Schlüssel temporär hochladen kann. Die Entschlüsselung müßte dann on the fly passieren, was sehr viel Power benötigt. Wenn ich die Funktionen alle in einem Gateway verschmelze, ist es natürlich viel einfacher, verschlüsselte Mails unverschlüsselt zu speichern oder sich den Upload zu sparen. Keine Ahnung wie das z.B. Reddoxx umsetzt.

Anderer Weg wäre, ich suche mir einen E-Mail-Server, der SPAM und verschlüsselte Mails unterstützt. Dann wird aber wieder euer PMG obsolet.

 

[tom]

Zum Thema Verschlüsselung, Archivierungspflicht, gesetzliche Vorgaben in Deutschland:

So mancher Gesetzgeber (und Softwareanbieter) versteht End-to-end Verschlüsselung nicht. Manche glaube, man kann verschlüsseln aber dann doch noch irgendwie Zugreifen. End-to-end Verschlüsselung kann man schon archivieren, aber nur die Person die den Key hat, kann auch zugreifen.

Das - und andere Vorgaben - führen dann am Ende zur Digitalisierung im "German style", also zur deutschen Leitzkulutur (digitale Inhalte werden ausgedruckt und in Ordnern zur Bearbeitung abgelegt, dann zur Archivierung aber wieder eingescannt ...). Ausserhalb Deutschland versteht das niemand.

Wie auch immer: bitte alle Featurerequests - möglichst mit genauer Beschreibung und einem Usecase - über https://bugzilla.proxmox.com übermitteln.

 

[Bob.Dig]

Daher die Frage an die Community - hat wer sowas?

Nope.

Aber nur bei PGP ist mein Key öffentlich. Und ich vermute, keys.openpgp.org lässt auch keine massenhafte Schlüsselsuche zu, also nicht wirklich öffentlich. Zur Spam-Bekämpfung wird das ganze Thema aber in der Praxis nicht beitragen.

Die E2E-Verschlüsselung aufbrechen tun ja viele große Institutionen eh schon. Kann daher den Wunsch nach einer zentralisierten Lösung durchaus nachvollziehen.

 

[c02]

wie sieht es mit einer sandbox funktion aus - steht sowas auf eurer roadmap ?
thx
lg

 

[magicpeter]

Daher die Frage an die Community - hat wer sowas?

Nein

Zur Archivierung, wir nutzen bei verschiedenen Kunden S/Mine Verschlüsselung mit Zertifikaten im Outlook. Die verschlüsselte E-Mail wird dann entschlüsselt und in einen Passwortgeschützten Ordner im Archivierungsprogramm (Office-n-PDF) abgelegt.
Funktioniert einfach und schnell.
Fertig!!!

 

[TFrenz]

In meinem alten Job haben wir eine Appliance von Zertificon verwendet.
Die konnte PGP, S/Mime und WebMail mit Veraschlüsselten E-Mails.
Von der End-to-End haben wir abstand genommen, da ein wechsel des Rechners bzw. neu aufsetzen des Betreibssystemes alle Zertifikate verloren gingen.
Auch musste der User sich um den Zertifikats Austausch und Import kümmern.
Das machte die Zertificon fast alles von selbst.