Immer öfter bekommen wir die Frage gestellt, wie es denn möglich wäre, die Transportverschlüsselung (TLS) für E-Mail mit Domino zu gewährleisten. Diese Frage wird insbesondere durch die DSGVO nun häufiger motiviert, da diese zum Schutz von personenbezogenen Daten in allen "Lebenslagen", also auch bei der Übertragung per E-Mail, auffordert. Hier hat man grundsätzlich zwei Optionen, die jeweils für sich betrachtet meines Erachtens (bitte konsultieren Sie für Gewissheit diesbezüglich Ihren Datenschutzbeauftragten) ausreichend sein sollten, die Anforderungen des Gesetzes zu erfüllen:
- Inhaltsverschlüsselung (S/MIME, PGP)
- Transportverschlüsselung (SSL/TLS/StartTLS)
Natürlich ist es überhaupt keine schlechte Idee, beide Maßnahmen miteinander zu kombinieren ;). So könnte der konsequente Einsatz von TLS auch die eFail-Lücke überwiegend schließen.
Transportverschlüsselung hat den großen Vorteil, dass:
- Sie nahezu kostenlos ist (nur das TLS-Zertifikat muss angeschafft werden)
- Der Implementierungs- und Pflegeaufwand verschwindend gering ist
- Keinerlei Verhaltensanpassung bei Nutzern notwendig ist
Der Nachteil wiederum ist, dass ich insbesondere im B2C nicht sicher sein kann, dass mein Gesprächspartner TLS unterstützt oder dieses auch nur kompatibel ist. Ich kann also nicht einfach daher gehen und meinen Servern sagen, dass sie nur noch TLS-Verbindungen akzeptieren sollen. Tue ich das, kann es mir passieren, dass E-Mails nicht ausgetauscht werden können und mir deshalb Geschäft entgeht. Ich muss also ggf. das Risiko eingehen, dass zumindest bei manchen Verbindungen keine Verschlüsselung zustande kommt.
Der wünschenswerte Fall ist daher, dass ich für die mir bekannten Organisationen oder Servern einstellen kann, ob TLS erzwungen werden soll oder nicht.
TLS im Domino SMTP einstellen
Es kann jeweils eingehend wie ausgehend festgelegt werden, ob TLS für SMTP genutzt werden bzw. wie restriktiv Domino das handhaben soll.
Wenn die Einstellung auf "Enabled" gestellt wird, versuchen sich sendender Server und unser Server darauf zu einigen, ob sie TLS nutzen. Können sie sich nicht auf eine Verschlüsselung einigen, wird unverschlüsselt übertragen. Wird "required" gewählt, würde die Verbindung in diesem Fall abgebrochen.
Das kann passieren, wenn es sich bei einem der Server um einen veralteten oder schlecht konfigurierten Server handelt, wie es zum Beispiel besonders bei kleinen Organisationen oder Privatpersonen mit eigener Maildomäne und -Server passieren kann.
Ausgehend gilt Vergleichbares, nur dass die notwendige Einstellung nicht in der Serverkonfiguration vorgenommen wird, sondern im Serverdokument:
Achtung Falle!
Da steht jetzt zwar negotiated/ausgehandelt, aber aus Gründen, die wahrscheinlich nur IBM kennt, erzwingt(!) Domino entgegen der Begrifflichkeit die TLS-verschlüsselte ausgehende Verbindung. Dies kann man ändern indem in der notes.ini des Servers der folgende Parameter hinzugefügt wird (danach einmal den SMTP-Dienst neu starten):
RouterFallbackNonTLS=1Diese Einstellungen gelten pro Domino-Server zu allen potentiellen Kommunikationspartnern
Die obige Beschreibung impliziert bereits, dass wir nicht etwa basierend einzelne Konnektoren für einzelne Ziel- oder Quelldomänen einrichten können, sondern auf dem einzelnen Domino-Server nur ganz oder gar nicht. Das ist ein uralter Wunsch den, wenn Sie ihn auch haben, gegenüber IBM zum Ausdruck bringen können, indem Sie für diese Idee stimmen. (Leider nicht ganz eindeutig formuliert, aber hoffentlich richtig verstanden :( )
Wir können unser Ziel trotzdem auf zwei Wegen erreichen.
Alternative 1: Einrichten eines zusätzlichen Routing-Servers der ausschließlich für Force TLS zuständig ist
Als Workaround für die benannte Einschränkung können wir einen neuen Domino-Server einrichten, der die obigen Einstellung zum erzwungenen TLS hat und alle Mails routet, die nur transportverschlüsselt gesendet werden sollen - oder gar nicht. Nennen wir diesen Server einfach "UnserNeuerServer". Wichtig ist, dass er in einer anderen Domino-Domäne ist, die wir zum Beispiel "TLSOnly" nennen.
Wenn wir nun eine Kunden/Partner-Domäne kennen, von der wir wissen, dass wir TLS erzwingen können, erzeugen wir ein neues Domänendokument vom Typ "Non-adjacent Domain"/"Nicht-benachbarte Domäne". Es muss nicht viel mehr enthalten sein als der Name der Zieldomäne und der Name der Domäne, über die die Mail geroutet werden soll. Das wäre in unserem Fall die Domäne "TLSOnly".
Wenn jetzt also ein interner Nutzer, eine E-Mail an die Domäne "bekannteDomäne.de" senden will, weiß der Domino-Server, dass er die fragliche Mail nicht auf dem "üblichen" Weg routen soll, sondern erst einmal an die Domäne "TLSOnly". Dafür ist natürlich ein Verbindungsdokument erforderlich:
Done!
Zu berücksichtigen ist hier, dass TLS eingehend nur bedingt zu erzwingen ist, da unser neuer Server voraussichtlich nicht von extern erreichbar ist (kein MX-Eintrag). Hier sind also Absprachen mit den Betreibern der bekannten Domäne erforderlich, dass diese ggf. ihrerseits TLS erzwingen, um die Übertragung in beide Richtungen vollständig zu schützen.
Alternative 2: Nutzung der Möglichkeiten des ggf. bereits vorhandenen Mail-Gateways
Bei den meisten unserer Kunden stehen die Domino-Server nicht mit dem SMTP-Fuß im Internet. Ihr MX zeigt im Regelfall auf eine Mailgateway-Appliance die E-Mails eingehend und ausgehend routet und sie dabei auch noch auf SPAM, Malware prüft und vielleicht auch weitere Maßnahmen wie DLP oder Inhaltsverschlüsselung anbietet.
Diese Appliance bietet möglicherweise genau die Features die wir benötigen, indem TLS im Rahmen von "Gruppen" oder Konnektoren erzwungen werden kann.
Sprechen Sie ggf. mit Ihrem Anbieter darüber. Gerne unterstützen wir Sie bei der Einrichtung und/oder Koordination mit dem Anbieter.
Diskussion
Domino macht es uns an dieser Stelle nicht leicht, aber wir können die Anforderungen für Transportverschlüsselung durch einen Workaround erfüllen. Und auch wenn wir hier einen erhöhten Aufwand hatten, um einen neuen Server einzurichten und uns mit den bekannten Domänen zu koordinieren, so ist das immer noch günstiger und m.E. nicht weniger sicher als S/MIME. Aber wie gesagt: die Kombination von beiden Maßnahmen ist sicher auch nicht falsch ;).
Sichere Kommunikation mit Kunden und Partnern ist und bleibt eine Herausforderung, zu der das letzte Wort nicht gesprochen ist. Das "S" in "SMTP" steht halt für "Simple" und nicht für "Secure". Gerade im Kontakt mit dem Endverbraucher (B2C) haben wir eine nur schwer überwindbare Hürde, weil hier "Simple" oft Vorrang hat. Wir können uns nicht darauf verlassen, dass TLS möglich ist, auch wenn die meisten Anbieter von Webmail das unterstützen. Inhaltsverschlüsselung (S/MIME, PGP) erfordert auf Seiten des Kunden eigene Infrastruktur und einen Schlüssel. Das dürfte für < 1% der Mailnutzer zutreffen. Es ist also vielleicht besser, für alles was über die Erstanbahnung und sporadische Kontakte hinaus geht, andere Kommunikationsmöglichkeiten als E-Mail zu suchen.
Wie wäre es mit einem eigenen Kundenportal? Vielleicht mit Authentifizierung durch bereits vorhandene Identitäten von Anbietern (z.B. Facebook, Google, Microsoft) denen die Nutzer bereits vertrauen, um es ihnen zu erleichtern (ja, das hat weitergehende Implikationen)?
Wie wäre es mit Chats statt E-Mail? So etwas wie WhatsApp für Unternehmen...
Kontakt: Gerne beraten wir Sie, welche Möglichkeiten für Ihr Unternehmen in Frage kommen. Kontaktieren Sie uns dazu einfach unter +49 4307 900 408 oder per Mail an kontakt@assono.de.
