E-Mail made in Germany… mit Exchange!

Es ist ja im Moment in aller Munde: Die Geheimdienste lesen mit.

Telekom, GMX und Web.de nutzen die aktuellen Diskussionen um das Thema und bieten seit kurzen “E-Mail made in Germany” an. Ein bisschen Hintergrund: Die 3 haben sich überlegt den Transportweg der Mails zu verschlüsseln, also die Kommunikation zwischen GMX, Telekom und Web.de Mailserver. Die Mail an sich wird jedoch nicht verschlüsselt, sondern nur die Verbindung mit der sie übertragen wird. Das erschwert zwar wahrscheinlich das Mitlesen der Mail, verhindert es jedoch nicht, denn solange ggf. Mails direkt beim Provider am Mailserver abgegriffen werden können, kann der Transportweg so hoch verschlüsselt sein wie er will. Beim Provider liegt eine normale Mail unverschlüsselt vor. Kleines Beispiel aus der Exchange Welt: Outlook überträgt mittels verschlüsselter Verbindung eine Mail den Exchange Server, der Exchange Server nutzt die Journal Funktion und überträgt die Mail an ein Journal Postfach und wiederrum auf verschlüsseltem Weg (wenn möglich) zum Empfänger. Der böse Admin/Geheimdienst/Chef braucht nur das Journal Postfach mitzulesen und kann die Mail ausdrucken und an das schwarze Brett der Firma hängen. Nur den Transportweg abzusichern, erschwert es jemanden also nur eine Mail zwischen Mailserver und Mailserver abzufangen, gänzlich unmöglich ist es aber nicht, gerade weil eine deutlich sicherere Methode (Perfect forward secrecy) scheinbar nicht bei den großen 3 zum Einsatz kommt. Der CCC äußert sich da ähnlich skeptisch, aber sei es drum: Das Verfahren ist nicht neu und Exchange unterstützt es auch, also können wir “E-Mail made in Germany “ auch mit Exchange nachbauen und gehen dann noch einen Schritt weiter. Mehr dazu weiter unten.

Um SMTP über TLS (SMTPS) zu nutzen brauchen wir ein Zertifikat, das Zertifikat sollte natürlich von einer Öffentlichen CA stammen und kein selbstsigniertes oder von einer eigenen CA ausgestelltes Zertifikat sein. Der Name auf dem Zertifikat muss mit dem EHLO Einträgen der Empfangsconnectoren eures Exchange Servers übereinstimmen. Ein kostenloses Zertifikat bekommt ihr zum Beispiel hier: www.startssl.com

Wenn ihr also einen Empfangsconnector mit dem EHLO Eintrag “mail.frankysweb.de” habt, dann muss auch der Name für das Zertifikat auf “Mail.frankysweb.de” ausgestellt sein. Das Zertifikat muss kein SAN-Zertifikat sein, denn ihr könnt dem öffentlichen Zertifikat nur das Protokoll SMTP zuweisen. Ich gehe hier nicht näher auf den Empfangsconnector ein, da die Verbindung zwischen Outlook und Exchange Server generell verschlüsselt stattfindet, bei Exchange 2013 läuft das via HTTPS:

Hier muss also kein SMTPS eingesetzt werden, es sei denn jemand möchte SMTPS für andere Clients (andere Mailclients, Anwendungen, etc) anbieten. Kommen wir also direkt zum Nachteil von TLS: Der Client entscheidet im Normalfall ob TLS genutzt wird, es sei denn es wird vom Exchange Server erzwungen. Ob TLS genutzt wird oder nicht wird während der Session über das SMTP-Kommando “STARTTLS”, welches der Client/Anwendung senden muss, festgelegt:

Wie man auf dem Bild oben sieht, baut gerade “anwendungsserver.frankysweb.local” eine Verbindung zum Exchange Server auf. Auf das EHLO antwortet Exchange mit den verfügbaren Optionen. Hier sieht man das STARTTLS angeboten wird, was im Prinzip soviel heißt wie “Ich kann TLS, wenn du willst”. Der Client muss dann das Kommando STARTTLS absetzen, damit die Verbindung gesichert wird. Hier liegt also die meiste Konfigurationsarbeit beim Client und nicht am Exchange Server. TLS lässt sich am Exchange Server erzwingen und zwar für jeden Connector einzeln, man könnte also einen Connector für unsichere Verbindungen und einen für sichere Verbindungen erstellen:

Set-ReceiveConnector Sichere-Verbindung -RequireTLS $true

Ungesicherte Verbindungen werden auf einem Connector mit “-RequireTLS $true” nicht mehr angenommen, eine Mail ohne SMTPS kann also dann nicht mehr abgeliefert werden.

Den gleichen Parameter gibt es übrigens auch für den Sendeconnector, also den Weg vom Exchange Server zum Empfänger Mailserver/Smarthost:

Per Default gelten folgende Einstellungen für den Sendeconnector: “Wenn TLS von dir angeboten wird, dann nutz ich es (-IgnoreSTARTTLS = False), wenn nicht dann schicke ich ungesichert (-RequireTLS = False)”. Hier ergibt sich dann direkt das nächste Problem, zwar kann auf dem Sendeconnector TLS erzwungen werden, wenn der Zielmailserver TLS aber nicht anbietet, kann keine Mail übermittelt werden. Ich schicke zum Beispiel meine Mails an Strato und Strato meine Mails in die weite Welt. Der Strato Server bietet TLS an:

Hier ist ein Ausschnitt aus dem Log:

Man sieht das vom Zielmailserver (in diesem Fall mein Smarthost) TLS angeboten wird. Exchange wechselt dann auch in den TLS Modus. Die Mail wird also mittels SMTPS übertragen. Das ist also “E-Mail made in Germany”…

Ob der Strato Mailserver dann allerdings auch TLS nutzt um die Mails an den eigentlichen Zielserver zu schicken kann ich nicht mehr nachvollziehen. Auch könnte der Smarthost die Mails direkt an Böse Admins/Geheimdienste/Chefs weiterleiten.

Ich hoffe nun wird klar warum “E-Mail made in Germany” nicht die Wunderwaffe gegen Mitleser ist. Solange nicht alle TLS nutzen, hilft es nur wenig und in manchen Fällen gar nicht. Eine normale E-Mail ist also erst einmal genauso anzusehen wie eine Postkarte: Jeder der sie in die Finger bekommt kann sie lesen! Stephan Cink (viele Grüße an dieser Stelle) hat dazu einen schönen Beitrag geschrieben:

http://www.msxfaq.de/signcrypt/enqsignsa.htm

Und er stellt sogar gleich eine Lösung vor: Ein Gateway was die Mail an sich verschlüsselt und nicht nur den Transportweg. Solche Gateways gibt es von verschiedenen Anbietern und eigentlich arbeiten sie im Wesentlichen gleich:

Exchange schickt die Mails an das Verschlüsselungsgateway, das Gateway kümmert sich um die Verschlüsselung und stellt die Mail verschlüsselt dem Empfänger zu. Da gibt es verschiedene Möglichkeiten wie die Gateways das regeln. Solche Gateways erschlagen eine Vielzahl von Problemen, aber nicht alle: Die Mail kann immer noch vom bösen Admin/Chef gelesen werden, denn die Mail wird erst am Gateway verschlüsselt, via Journaling kann die Mail noch unverschlüsselt am Exchange abgegriffen werden, bevor sie das Gateway erreicht. Um den Postkartenvergleich herzustellen: Ich gebe meine Postkarte dem Briefträger und der steckt sie in einen Briefumschlag und liefert sie aus. Solange ich dem Briefträger vertraue ist alles gut.

Es hat also alles Vor- und Nachteile, wer sicherstellen will, dass eine Mail nicht von unbefugten Dritten gelesen werden kann, der muss die Mail an sich verschlüsseln. Outlook unterstützt dazu das Verfahren S/MIME. S/MIME erlaubt Ende-zu-Ende Verschlüsselung, dass heißt die Mail wird dem öffentlichen Schlüssel des Zertifikats verschlüsselt und nur der Besitzer des privaten Schlüssels kann die Mail wieder entschlüsseln. Hört sich gut an, hat aber leider auch Nachteile. Wenn ich eine Mail verschlüsseln möchte, brauche ich dazu den Öffentlichen Schlüssel des Empfängers. Der Schlüssel muss mir also bekannt sein oder ich muss ihn vorher anfordern. Mal eben eine Mail verschlüsselt verschicken, funktioniert also nicht. Auch der Empfänger der Mail muss gut auf seinen privaten Schlüssel acht geben, kommt der Schlüssel in falsche Hände, hat es sich mit der Verschlüsselung erledigt, geht er verloren können die Mails nicht mehr eingesehen werden. Wer zum Beispiel das Zertifikat mitsamt privaten Schlüssel auf seinem Smartphone mit sich rumträgt… lassen wir das.

Trotzdem halte ich S/MIME für ein gutes Verfahren, denn es funktioniert ganz gut und wird von vielen Clients unterstützt, auch von Smartphones etc. Ein kostenloses Zertifikat für die E-Mail Verschlüsselung gibt es unter anderem auch bei StartSSL.

In Outlook kann dann das Zertifikat importiert werden

Ihr könnt nun E-Mails mit dem Zertifikat signieren, damit wird dann auch der öffentliche Schlüssel an den Empfänger übertragen.

Wenn ihr signierte Mails erhaltet, dann fügt den Absender am besten direkt als Kontakt in Outlook hinzu, Outlook speichert dann das Zertifikat zu dem Kontakt ab und ihr könnt in Zukunft verschlüsselte Mails an den Kontakt verschicken

Sobald ihr eine Mail erhaltet die mit euren öffentlichen Schlüssel verschlüsselt wurde, zeigt Outlook das entsprechend an

Übrigens funktioniert S/MIME auch auf fast allen Smartphones, hier zum Beispiel beim iPhone

Übrigens in der Sophos UTM Home ist ebenfalls ein Gateway zur E-Mail Verschlüsselung enthalten

Die Möglichkeiten sind also vielfältig, welche für euch die Beste ist, müsst ihr selbst entscheiden.