Was Sie über die Verwendung von SSL/TLS zur Verschlüsselung der von Ihren E-Mail-Servern hergestellten Verbindungen wissen müssen

Als ich mit dem Thema für diesen Blog-Beitrag angesprochen wurde, habe ich gerne zugesagt. Hier ist eine Umschreibung
des Ablaufs:

„Könntest du
einen Beitrag über die Bedeutung von TLS in E-Mail-Servern schreiben?“, fragte Patrick.

„Sicher“, sagte ich.

Wow, das war ein verrücktes
Gespräch, das ich noch einmal erleben wollte! Wie ein Wirbelwind!

Dann habe ich ein bisschen darüber nachgedacht. Gibt es da draußen wirklich E-Mail-Server, die keine Verschlüsselung für die Übertragung verwenden? Ich spreche nicht von einer Ende-zu-Ende-Verschlüsselung, wie wir sie in der Vergangenheit behandelt haben (S/MIME, PGP, etc.). Ich spreche von einer Verschlüsselung von Server zu Server oder von allem, was dazwischen liegt, um die Daten auf ihrem Weg zu schützen.

Natürlich würde heutzutage niemand mehr seine ein- und ausgehende Post im Klartext über Gott weiß welchen Weg schicken, um abgefangen und ausgenutzt zu werden. Viele Menschen nutzen E-Mail-Dienste, und es ist nicht vorstellbar, dass sie die Transitverschlüsselung aus ihren Diensten ausschließen würden. Datenschutzverletzungen kosten sie Millionen in
Rechtsstreitigkeiten und Geschäftsverlusten und beschämen……Hmmmm…..

Ich ging zurück zu Patrick
mit einer Frage.

„Haben wir Statistiken
oder Informationen über E-Mail-Server, die keine Verschlüsselung verwenden? Ich vermute, dass die Zahl gering ist
. Mit anderen Worten, was hat Sie dazu veranlasst, mich nach diesem Artikel zu fragen?“

Patrick antwortete: „Ich
weiß es eigentlich nicht. Ich dachte, es wäre ein gutes Thema, wenn man bedenkt, wie wichtig
E-Mails sind und welche Sicherheitsaspekte es gibt.“

OK. Das macht Sinn. Es gibt wahrscheinlich einige E-Mail-Server, die es überhaupt nicht verwenden, obwohl zweifellos ein viel größerer Prozentsatz veraltete Protokolle oder abgelaufene Zertifikate verwendet und vielleicht nur eine Auffrischung benötigt.

Dieser Artikel gibt einen Überblick über den aktuellen Stand der E-Mail- und Transitverschlüsselung, um sicherzustellen, dass Sie mit dem optimalen Sicherheitsniveau arbeiten, das Ihnen zur Verfügung steht.

Verschlüsselung in E-Mail-Servern

An dieser Stelle haben wir wahrscheinlich ein allgemeines Verständnis davon, wie TLS funktioniert, aber lassen Sie uns zusammenfassen, falls Sie neu auf diesem Gebiet sind.

Person A möchte eine
sichere Kommunikation an Mensch B senden. Person A und Mensch B haben ein vorher erstelltes
Zertifikat. Person A verwendet das Zertifikat, um die Informationen zu verschlüsseln und sendet
die verschlüsselten Informationen an Mensch B. Die Informationen sind unlesbar, bis Mensch
B das Zertifikat verwendet, um die verschlüsselten Informationen zu entschlüsseln.

Wenn Person B Person A mit verschlüsselten Informationen antworten will, dann würde Person B das Zertifikat verwenden, um die Daten zu verschlüsseln, und Person A würde das Zertifikat verwenden, um die Nachricht zu entschlüsseln.

So funktioniert im Allgemeinen die
Verschlüsselung/Entschlüsselung. Ersetzen Sie nun die in diesem Beispiel aufgeführten Personen durch
Server und andere solche Verbindungen.

Wenn nun Person B Person A mit verschlüsselten Informationen antworten möchte, verwendet Person B den soeben erzeugten symmetrischen Schlüssel, und sie können nun gegenseitig Daten verschlüsseln und senden bzw. empfangen und entschlüsseln.

So funktioniert im Allgemeinen die Ver-/Entschlüsselung mit SSL/TLS. Ersetzen Sie nun die in diesem Beispiel aufgeführten Personen durch Server und andere derartige Verbindungen. Dasselbe Konzept. So funktioniert TLS bei E-Mails, was sich etwas von der Erleichterung einer HTTPS-Verbindung unterscheidet, da E-Mails andere Protokolle verwenden. Dennoch gibt es einige deutliche Ähnlichkeiten:

• Ein Handshake findet statt
• Eine Authentifizierung findet statt (obwohl sich in diesem Zusammenhang beide Parteien authentifizieren)
• Sitzungsschlüssel werden verwendet, um den E-Mail-Fluss zu übertragen.

Ebb und (Mail-)Fluss

Der nächste Schritt in diesem
„Verstehen warum“ Artikel ist der „Verstehen wie“-Teil.

Kurz gesagt, sendet ein E-Mail-Client eine E-Mail an den Ausgangsserver. Der Ausgangsserver führt eine DNS-Suche durch, die auf der Ziel-E-Mail-Domäne basiert, und der MX-Eintrag des DNS bestimmt, an welchen Server die E-Mail zu senden ist, und möglicherweise bestimmt dieser Server, ob sie weitergeleitet werden muss, bis sie den Mail Delivery Agent (MDA) des Zielpostfachs erreicht.

Es reicht nicht aus, den DNS MX-Einträgen zu vertrauen, das ist ein ganz anderes Thema, sondern der SMTP
(ausgehende Post, MTA, etc.) Server und die eingehende Post (über POP3, IMAP,
Exchange) müssen sich gegenseitig identifizieren können und die richtigen Schlüssel haben, um miteinander zu kommunizieren
. Und je nach Route kann die Kommunikation zwischen den E-Mail-Servern mehr
als nur einen Schritt betragen. Entlang der Route könnten Mail Exchanger, Proxy
Server und andere vorhanden sein. Jeder Hop (sollte) eine verschlüsselte Verbindung erfordern. Oftmals ist dies der Fall. Manchmal aber auch nicht. Die Benutzer würden es vorziehen, wenn sensible Informationen auf dem Weg verschlüsselt werden. Eine Ende-zu-Ende-Verschlüsselung
hilft sicherzustellen, dass es eine Art von Verschlüsselung auf dem gesamten Weg gibt, aber
Schichten der Sicherheit sind immer besser.

Respect Thy Securi-Tie

Fürs Protokoll,
Securi-Tie ist kein echtes Wort. Ich habe das Wort nur erfunden, weil es sich reimt. Es ist
eine Anspielung auf das Wort Sicherheit.

Um an den vorherigen Abschnitt anzuknüpfen, sollten wir über Sicherheitsoptionen sprechen, die zwar
von der Client-Seite aus gesetzt werden, aber eigentlich dem Mail-Server einige Anweisungen
für sicherheitsrelevante Zwecke geben.

Bei der Konfiguration eines
E-Mail-Clients (Outlook, Thunderbird, etc.) ist die Voreinstellung eine unverschlüsselte
Konfiguration. Aber, und darum geht es in diesem Artikel, wir wollen in der Regel die verschlüsselte Option wählen
. In gewissem Sinne liegt es nicht nur am Client: Es hängt davon ab, was der Server unterstützen kann. Angenommen, Ihr eingehender
und Ihr ausgehender Server können die Verschlüsselung unterstützen, warum sollten Sie das nicht tun? Wenn Sie in einem Restaurant ein
Steak bestellen und es wird Ihnen zum gleichen Preis ein Lendenstück oder ein Kobe(wagyu)-Ribeye
angeboten, warum sollten Sie dann nicht das qualitativ bessere Stück bestellen?

Wenn Sie also
TLS/SSL für Ihre E-Mails verwenden wollen (dies gilt für den Transit-Teil und nicht für den Ende-zu-Ende-
S/MIME-Teil, der in anderen Blog-Beiträgen behandelt wird), schalten Sie es ein. Verwenden Sie die Ports 465
oder 587 für SMTP (‚member, outbound mail) und 993 (IMAP) oder 995 (POP3) für
inbound traffic.

Es gibt ein
interessantes Verschlüsselungsprotokoll, das immer noch von E-Mail-Servern verwendet wird. Es
hat seine guten und schlechten Seiten, wie das bei den meisten Dingen so ist. Letztendlich würde ich sagen, dass
seine Absichten gut sind, aber die Anwendung in der realen Welt ist nicht ganz so ideal, wie sie
sein könnte. Meine Damen und Herren, dieses Protokoll ist STARTTLS.

STARTTLS ist ein Sicherheits
protokoll, das im Grunde genommen SSL/TLS ist. Ganz einfach, STARTTLS nimmt eine
bestehende Klartext- und damit unsichere Verbindung und versucht,
sie mit Hilfe von TLS (oder SSL) in eine sichere Verbindung zu verwandeln. Das Sicherheitsniveau von
STARTTLS und SSL/TLS unterscheidet sich also eigentlich nicht. Wenn alles richtig eingestellt ist, werden beide
Informationen mit TLS (oder SSL) verschlüsseln.

Der Hauptunterschied beruht
auf dem Zustand einer Verbindung und/oder der Einleitung der Kommunikation. STARTTLS
garantiert keine verschlüsselte Kommunikation. Es bedeutet im Grunde: „Wenn die
Verbindung unverschlüsselt ist und Sie dazu in der Lage sind, machen Sie daraus eine sichere
Verbindung. Wenn der Verbindungsknoten (wahrscheinlich ein Server) nicht in der Lage ist, die
Verbindung in eine verschlüsselte Verbindung umzuwandeln, kann es dem Client überlassen bleiben, wie er damit umgeht.

Während ich den
qualifizierenden Begriff von STARTTLS als „nützlich“ verwendet habe, könnte er als weniger sicher
als die Auswahl von SSL/TLS betrachtet werden. Die Standard-SSL/TLS-Auswahl bedeutet im Grunde: „Verwende
Verschlüsselung oder du fliegst raus.“ STARTTLS sagt: „Ähm, wenn Sie es könnten, tun Sie es bitte. Wenn
nicht, können wir auf der Grundlage anderer Anweisungen fortfahren.“

Hier sind einige schlüssige Aussagen

Manchmal muss das Offensichtliche gesagt und vielleicht
überbetont werden. Also hier ist es, ähem: Verwenden Sie Verschlüsselung. Vor allem für etwas, das so wichtig ist, so entscheidend und in die überwiegende Mehrheit jeder Organisationsstruktur integriert ist, die Informationen über Leben und Tod transportieren kann. Es gibt
nicht viel Aufwand, der darauf verwendet werden muss. Verwenden Sie sowohl eine Ende-zu-Ende- als auch eine Ende-zu-Transite-Verschlüsselung
. Zwei sind besser als eine.

Wenn jemand der Meinung ist, dass der zusätzliche Aufwand, einen E-Mail
Server verschlüsselt oder unverschlüsselt einzurichten, es nicht wert ist, dann ist er
es nicht wert. Das ist einfach eine Übertreibung des Offensichtlichen. Eine Ende-zu-Ende-Verschlüsselung, wie z.B. S/MIME, erfordert einen aufwändigeren Ansatz, aber es lohnt sich auch, wenn man mehrere Ebenen der
Sicherheit hinzufügt. Es gibt jedoch keine Entschuldigung dafür, sich nicht die Zeit zu nehmen, um
sichere Verbindungen einzurichten und zu pflegen.

Wenn es die Sicht erlaubt, sollte jeder E-Mail-Pfad, der nicht sicher oder kompromittiert erscheint, unter die Lupe genommen werden. Und damit wünsche ich Ihnen viel Spaß beim Hinterfragen für ein sichereres Internet. Prost!

*** Dies ist ein vom Security Bloggers Network syndizierter Blog von Hashed Out by The SSL Store™, verfasst von Ross Thomas. Lesen Sie den Originalbeitrag unter: https://www.thesslstore.com/blog/encryption-and-email-servers/