E-Mail Übertragung zwischen Mailservern verschlüsselt?

Wenn beide MTAs das STARTTLS-Kommando können handeln sie untereinander eine Verschlüsselung aus.
In den Received-Headern wird dann etwas auftauchen wie ...with AES-256 encrypted SMTP... (qmail).
Das sehe ich aber insgesamt nur bei ziemlich wenigen Mails...

Hallo,

SSL zwischen Servern ist tatsächlich _sehr_ unüblich, weil SSL auf einem anderen Port horcht. Hier müsste der sendende Server wirklich erst probieren, ob er den empfangenden dort erreicht. Und ob er da auch Server-Verbindungen entgegennimmt und nicht nur Clients.
Bei TLS ist das anders: Hier wird auf Port 25 eine Verbindung aufgebaut, dann kann der empfangende mitteilen, dass er auch TLS spricht, und der sendende kann es dann nutzen (von dog erwähntes STARTTLS). Auch Zertifikate sind kein Problem. Oder musst du dir bei einer https://-Website vorher das Zertifikat vom Admin schicken lassen, um die Seite zu besuchen? Im Gegensatz zum Webbrowser vertraut ein sendender Mailserver meistens sogar jedem beliebigen Zertifikat, das ihm vorgelegt wird. Warum? Es geht nicht um autentifizierung, sondern um Verschlüsselung. Und dazu ist Idenität relativ egal (von MiM-Attacken mal abgesehen...).

Nein. Das war ursprünglich zwar nicht vorgesehen, wurde aber in den Protokollerweiterungen sauber spezifiziert. Und der Witz: Es funktioniert tatsächlich einwandfrei.

Nicht unbedingt. Dann hast du nämlich genau das, was du oben beschrieben hast: wenn sich hier mal was ändert (z.B. dein Schlüssel abläuft), dann steht ein ziemlicher Aufwand an (du musst nämlich jedem, mit dem du kommunizieren willst deinen neuen Schlüssel zuschicken).

Woher soll der Anwender das denn wissen? Bei jedem erstmal nachfragen? Eher aufwendig. Und: Du lagerst damit Verantwortung auf den Anwender ab, er muss jetzt schauen, dass er bei jeder Mail an die Verschlüsselung denkt. Wenn du dagegen z.B. zu einem Dienstleister einfach serverseitig eine Verschlüsselung einrichtest (TLS Required), dann kann da nichts mehr anbrennen; es ist sichergestellt, das Mails nur verschlüsselt übertragen werden.

Und zurück zur Frage: nein, üblich ist auch eine TLS-Verschlüsselte Übertragung noch nicht - warum auch immer.

Gruß

Filipp

Das "warum auch immer" ist recht einfach zu beantworten - diese hast du selbst nämlich schon gegeben.

TLS ist m.E. einfach nur ein schlechter Witz. Wogegen soll das denn bitte schützen? Ich sag mal so: Wo würde ein Angreiffer denn erstmal versuchen eine Email abzufangen? Da der Weg durchs Internet nur recht schwer vorherbestimmt werden kann gibts da ja nicht sooo viele Stellen:
-> Zentrale Knoten wie z.B. DeCIX: Hier sind die Router nicht so einfach zu bekommen - da die Leute dort vor Ort auch wissen was die tun. D.h. hier wird nen Angriff eher scheitern.
-> Knoten beim Provider: Ist auch nicht so einfach. Wie beim DeCIX steht hier ja nicht nur ein kleiner Router sondern mehrere. Und da der Provider auch lokale Unterteilungen hat stehen hier meist viele "kleine" Router -> und ich kann nicht einfach vorhersagen auf welchem Router was läuft. D.h. ein Angriff hier bringt wenig.

Es bleibt also nur das System beim Sender oder beim Empfänger als sinnvoller Angriff (es würde ja nichts bringen wenn ich irgendeinen Router im Netz bekomme - da dort nicht unbedingt alle Pakete der Mail drüberlaufen kann ich die dann auch bei einer unverschlüsselten Übertragung nicht zusammensetzen). Und hier kommt genau das Problem bei TLS solange du keine Zertifikate oder Passwörter verwendest: Er vertraut JEDEM Server! D.h. eine simple Regel im Router des Senders (leite alle Pakete mit Zielport 25 an den Server xyz um - und natürlich die Pakete die zu dieser Transmission gehören) und schon geht alles an meinen Server. Der spricht aber auch TLS wenn ich will - und die Welt ist wieder in Ordnung. Jetzt gehe ich noch eben bei und konfiguriere den als "open Relay" welches alle Mails kopiert (ggf. auch nur als Relay für die IP des Senders - ich möchte ja keinen Spam haben) welches aber gleichzeitig ne Kopie der Emails an mich schickt. Gut das deine Mails verschlüsselt übertragen wurden... (Das geht natürlich auch wenn ich den DNS von dir unter Kontrolle bekomme usw... - die Möglichkeiten sind ja vielfältig wie ich ein Paket an mich umleiten könnte).

Das ist dassebe wie bei deinem HTTPS. Hast du hier jemanden der immer nur auf "Ja, ich kenne das Risiko - mach weiter" klickt dann bringt https nicht EIN STÜCK Sicherheit. Denn wenn ich dann meinen Webserver zuhause nen Self-Signed gebe und da die Seite der Sparkasse als Kopie drauf packe dann gibt die Person mir eben ALLE benötigten Daten ...

Daher ist es für mich eher ein Witz wenn man sagt das die Kommunikation sicher ist weil da was verschlüsselt wird. Ich sag mal so: Wenn ich heute auf dem Heimweg angehalten werde dann gibt es da verschiedene Möglichkeiten:
- Ein Polizeiwagen hält mich an und ein uniformierter steigt aus. Dadurch das er ein "Zertifikat" hat (Polizeiwagen + Uniform) weiss ich das er meinen Führerschein sehen darf -> also gebe ich ihm den. (Wobei ich an dieser Stelle einfach vorraussetze das nicht ein böser Mensch das Zertifikat geklaut hat - aber DAS ist noch ein anderes Thema).
- Ein Zivil-Fahrzeug hält an. Es steigt einer in Zivil aus. Entweder zeigt der mir ein vertrauenswürdiges Zertifikat (-> Dienstausweis) oder ich würde dem auch nicht meine Daten geben. Das Problem bei TLS an dieser Stelle: Wenn da IRGENDWER aussteigen würde und sagt er wäre Polizist -> TLS würde dem sofort vertrauen und sagen "Klar, nimm alle meine Daten!". Wenn ich aber als Person das Zertifikat der Person "komisch" finde dann kann ich sagen das wir zu einer Zertifizierungsstelle (-> dem nächsten Revier) fahren. TLS würde dagegen sagen "Is alles OK" - selbst wenn da nen 8jähriger Knirps vor dir steht... Er vertraut halt JEDEM Zertifikat - hauptsache es steht was drauf was "TLS" heisst... Selbst das handschriftliche ("Self-Signed") ist da kein Problem - ich hab ja nen Schlüssel...

Was dann natürlich noch dazu kommt: Du stellst deinen Server ein: TLS und "haste nich gesehen". Leider sitzt auf der anderen Seite jemand dem das ganze egal ist. Der lässt seine Clients nämlich per "POP3" oder "IMAP" (ohne SSL o.ä.) abholen. Schon ist deine vertrauliche Mail wieder im Klartext unterwegs...

Was passiert aber dagegen wenn ich die Mail am Client verschlüssel? Nun - du stellst deinen Server dazwischen und fängst meine Mail ab. Sofern die Verschlüsselung gut gewählt wurde (z.B. PGP bietet da ja einiges an) kannst du die gerne haben. Egal ob du die Mail bei mir abfängst oder beim Empfänger -> du kannst sie nicht lesen solang du nicht an den private Key des Empfängers kommst (und ggf. dessen Passphrase). Und die Argumente mit der höheren Verwaltung ziehen da auch nicht wirklich: Der Empfänger exportiert einmal seinen öffentlichen Schlüssel. Sofern du weisst das die Person Mails verschlüsselt empfangen möchte (da vertraulicher Inhalt o.ä.) kannst du das ohne Probleme machen. Ändert der seinen Schlüssel dann überträgt der den neuen Public Key auf den Server und du lädst ihn da (teilweise automatisch) runter. Es ist jetzt eine Frage der Sicherheitsanforderung ob du das automatisch machst oder ob der neue Key z.B. per Boten zu dir kommt (unabhängiger Transportweg). In jedem Fall bleibt es aber dabei das die Kommunikation dabei unerheblich ist -> meine Mail kann nur von demjenigen gelesen werden der Zugang zum Private Key hat...

Dazu kommt aber noch der Vorteil das du diese Kommunikation signieren kannst. D.h. schicke ich eine Mail an meinen Chef kannst selbst du als Admin (sofern du meine Passphrase nicht kennst) mit dieser Mail nichts machen. Änderst du auch nur ein Zeichen an der Mail dann passt die Signatur nicht mehr und der Chef sieht das du aus "ich möchte gern mehr Geld" ein "Ich will ab morgen umsonst arbeiten" gemacht hast - ob den das Intressiert ist natürlich ne andere Sache ;).

Von daher bin ich nach wie vor überzeugt das TLS einfach nur unnütz ist. Mir fällt kein Punkt ein wo es für mich wirkliche Vorteile bei der Sicherheit bringt wenn nur die Server-Server-Kommunikation verschlüsselt wird. Mir fallen dagegen aber viele Wege ein wie ein Angreiffer eben das System zu leicht aushebeln kann. Hier kommt aber auch ein genereller Nachteil bei einer Server2Server-Kommunikation zum Tragen: Eine Maschine muss sich ans Protokoll halten. Da gibts kein "rechts oder links" -> entweder passt es oder nicht. Wenn du jedoch eine "End2End"-Verschlüsselung nutzt dann hast du das Problem nicht (bzw. nicht so extrem). Denn ich kann eben meinen public Key auch einfach auf nen USB-Stick packen und dir per Post schicken (von mir aus noch in ner verschlüsselten Datei die du erst mit einem Passwort öffnen kannst was ich mit seperater Post schicke... Wobei ich das Passwort natürlich auch noch codiert in den Brief packe und dir den Dekodieralgorithmus erst Abends am Stammtisch verrate). Und schon hast du das Problem das du eben die benötigten Schlüssel nicht einfach mit technischen Mitteln fälschen kannst -> meinen private Key den trag ich ggf. auf ner Smartcard in meiner Geldbörse mit mir rum - und das Backup liegt im Safe bei der Bank. D.h. die einzige Art wie du dann noch an den Inhalt der Mail kommst ist wenn du per Trojaner nen Screenshot vom Bildschirm beim Sender oder beim Empfänger machst (selbst wenn du als Admin in den Ausgang beim Sender guckst siehst du ja die Plain-Text-Nachricht nicht mehr - und in meinem Eingang siehst du die auch nicht ohne meinen Key...).

Meine Meinung: Wenn ich wirklich will das etwas sicher ist DANN bitte auch richtig. Ich kann nicht nur einen kleinen Teil des Weges sichern und dann hoffen das alles gut wird...

Nunja, ganz so unnütz ist TLS nun auch wieder nicht. Man muss es nur richtig einrichten und nutzen. Es besteht durchaus die Möglichkeit den SMTP Server so zu konfigurieren, dass er Verbindungen von und an bestimmte E-Mail-Domänen nur über TLS abwickelt. Des Weiteren muss er das Zertifikat und die entsprechende Zertifikatskette der Gegenseite kontrollieren. Ich gehe davon aus, dass in einem Anwendungsfall bei dem es um Datensicherheit geht, vertrauenswürdige Zertifikate zum Einsatz kommen, die von einer vertrauenswürdigen PKI ausgestellt worden sind. In einem solchen Fall kann ich dann auch davon ausgehen, dass es sich beim Server der Gegenseite auch wirklich um den Server handelt mit dem ich gerade kommuniziere. Das kann ich mit einer MiM Attacke nicht so leicht unterbrechen, da mir als Angreifer der Private Key fehlt. Wenn man TLS also aus einem Sicherheitsgedanken zum Schutz von Daten anwenden will, muss ich das schon ordentlich konfigurieren. Mit selfsigned Zertifikaten und keiner Überprüfung des Zertifikats der Gegenseite ist, wie bereits von maretz beschrieben, kein wirklich starker Schutz gegeben. Dass es noch nicht so verbreitet ist, liegt meiner Meinung einfach am mangelnden Fachwissen vieler Mailserver-Admins. Sobald das Thema Zertifikate und PKI auf den Tisch kommt, blenden die meisten aus, weil es alles "viel zu kompliziert" und "eigentlich nicht ganz so wichtig ist". Dabei ist es gar nicht so furchtbar kompliziert.
Wenn ich allerdings TLS einsetze, muss ich auch dafür sorgen, dass bei eingehenden E-Mails der ganze Weg zu meinem Postfach mit TLS geschützt wird. Der Versender müsste das entsprechend genauso tun, damit der Weg der E-Mail auch konsistent sicher ist.

Ein Wort noch zur Verteilung des Public Keys bei der E-Mail-Verschlüsselung am Client: Das ist mit Abstand der leichteste Part bei diesem Thema. Dazu schicken sich die beiden Parteien lediglich eine signierte E-Mail. Damit ist alles relevante ausgetauscht. Mit einem Doppelklick auf das Signatur-Icon der empfangenen Mail, kann ich den Public Key des E-Mail Partners auf meinem Computer installieren und in Verbindung mit meinem Private Key anschließend E-Mails an diesen einen Partner verschlüsseln. Vorausgesetzt die Gegenseite hat meinen Public Key ebenfalls installiert, kann er meine verschlüsselten Mails dann mit seinem private Key und meinem Public Key entschlüsseln. Nachteil des ganzen: Ich kann es erstmal nur von dem Client aus ver- und entschlüsseln, auf dem auch der private Key liegt. Beim Einsatz von SmartCards sieht es dann schon wieder anders aus. Probleme habe ich allerdings meistens beim Einsatz von mobilen Endgeräten (BlackBerry, iPhone, WindowsMobile und Co.). Dort muss ich die Keys ein zweites Mal installieren.
So etwas kann man noch viel leichter mit Gateway-Lösungen erreichen. Diese verwenden entweder eine vorhandene PKI oder verwalten die Zertifikate selbständig und der Benutzer bekommt nichts vom Entschlüssel- und Verschlüsselvorgang mit. Somit habe ich auch keinen Stress bei mobilen Endgeräten oder gar OWA (wenn man Exchange einsetzt).
HTH

Gruß Stefan Cink

Naja - wenn du aber TLS am Server wirklich "richtig" einrichtest dann hast du einen enormen Administrations-Aufwand. Denn du musst für JEDEN Server die nötigen Daten hinterlegen. Wenn du in nem Unternehmen mit 100 Personen bist dann müsste jeder der 100 Personen dir sagen mit wem die Kommuniziert (verschlüsselt) und du musst das dann einrichten.

Umgekehrt hast du aber immernoch das Problem: Dir möchte jemand eine Mail schicken (z.B. nen Erst-Kunde). Setzt du also jetzt TLS auf required hast du ein Problem. Deinen Key habe ich beim ersten Kontakt noch nicht - und somit müsstest du entweder wieder ein eigenes Zertifikat nutzen (inkl. aller Nachteile) oder auch plain-Empfang zulassen (wie die meisten Mailserver). Jetzt kommt der nächste Nachteil zum Tragen: Wir beide schicken uns Mails (vertrauliche) hin und her. Du hast bei dir alles gut eingerichtet - ich hab hier leider an einer Stelle gepennt. Ich nehme zwar TLS an, hab auch nen Zertifikat und alles gut und schön -> aber beim Senden hab ich vergessen das ich auch TLS beim Senden erlaube. Jetzt kommt deine Mail - ich gehe auf Antworten und schicke das ganze wieder im Klartext durch die Leitung. Der User sieht das nicht -> er hat keinen Zugriff auf die Kommunikation der Mailserver. Also geht das Ding hin und her -> und jede Antwort ist wieder im Klartext lesbar. Gebe ich dem User die Option z.B. mittels PGP zu arbeiten dann kann er selbst erkennen was da schiefläuft.

Von daher ist auch an der Stelle TLS m.E. einfach nur der falsche Ansatz. Der Aufwand das wirklich einzusetzen ist deutlich höher als wenn ich da ne saubere Struktur aufbaue (und es gibt ja durchaus die Möglichkeit die Zertifikate sogar zentral zu verwalten -> d.h. meldet sich der User morgen an nem anderen Rechner an dann bekommt er sein Zertifikat auch da). Und die Fehlermöglichkeiten sind gewaltig -> was passiert z.B. wenn jemand wie Web.de einen Cluster mit Mailservern hat und hier auf EINEM Server das Zertifikat nen Fehler aufweist? Plötzlich gehen einige Mails nicht mehr raus - viel Spass beim Suchen... Bei der C2C-Kiste ist es dagegen recht einfach: Entweder mein lokales Mailprogramm meldet mir das die Verschlüsselung fehlgeschlagen ist oder die Mail geht raus. Geht beim Empfänger was schief dann bekomme ich entweder nen NDR zurück oder der hat z.B. seinen Key verbummelt und wird dann bei mir Anrufen das er die Mail nicht öffnen kann. Und gegen einen Angreiffer der Zugriff auf den Mailserver hat (wo der Angriff nunmal auch die höchste Wahrscheinlichkeit hat) ist TLS auch machtlos -> die Mail liegt auf dem Server dann wieder im Klartext.