Wie sicher ist der Mailversand via SMTP?
Wie sicher ist der Mailversand via SMTP?
Kurz gesagt: Der Mailversand via SMTP ist überhaupt nicht sicher. Aber keine Sorge, es lässt sich verbessern.
Das Simple Mail Transfer Protocol (SMTP) stellt eines der am häufigsten verwendeten Netzwerkprotokolle im Internet dar und ist für den Mailversand zwischen den einzelnen Mailservern, wie beispielsweise Gmail, GMX oder T-Online, von essentieller Bedeutung. Das Protokoll wurde im Jahr 1981 im RFC 788 standardisiert und gehört somit zu den ältesten Netzwerkprotokollen. Es wurde jedoch nie mit der Intention entwickelt, einen sicheren Mailversand zu gewährleisten. Es ist bis heute als reines Transportprotokoll für E-Mails zu betrachten.
Bis in die 1990er Jahre war es im Internet gängige Praxis, dass Mailserver als sogenannte "Open Relays" fungierten. Jede Nutzerin und jeder Nutzer war in der Lage, mittels des Simple Message Transfer Protocol (SMTP) E-Mails mit beliebigen Absender- und Empfängeradressen über diese Mailserver zu versenden. Dies wurde zunehmend durch Spammer missbraucht, welche diese Server dazu nutzten, um E-Mails mit gefälschter Absenderadresse zu verteilen. Heutzutage gehört es zu einer der kritischsten Fehlkonfigurationen, wenn ein Mailserver die uneingeschränkte Weiterleitung von E-Mails erlaubt, ohne die Absenderadresse zu prüfen oder eine vorherige Authentifizierung zu verlangen. Das SMTP-Protokoll selbst bietet keinen direkten Schutz dagegen. Die Prüfung der Absenderadresse muss demnach durch den Mailserver selbst erfolgen, bevor eine E-Mail an den Mailserver der Empfangsadresse weitergeleitet wird. Empfehlenswert ist eine Konfiguration der Mailserver dahingehend, dass die Weiterleitung einer E-Mail erst nach erfolgter Authentifizierung des jeweiligen Nutzers des absendenden Postfaches innerhalb der SMTP-Sitzung sowie der Prüfung der Übereinstimmung der Absenderadresse mit dem jeweiligen Postfach erfolgt. Die Authentifizierung wurde erst 1999 mit dem RFC 2554 als Erweiterung im SMTP-Protokoll eingeführt.
Im Gegensatz zu HTTPS findet bei SMTP keine explizite Verschlüsselung via SSL/TLS statt. Der Kommunikationskanal zwischen zwei Mailservern wird stets unverschlüsselt aufgebaut. Zunächst existierte keine standardisierte Möglichkeit, E-Mails verschlüsselt zu versenden. Erst 1999 wurde mit dem RFC 2487 eine Erweiterung im SMTP-Protokoll eingeführt, die unter dem Namen STARTTLS bekannt ist und eine Verschlüsselung ermöglicht. Damit war es möglich, den anfänglich unverschlüsselten Kommunikationskanal via SSL/TLS zu verschlüsseln. Es existieren jedoch nach wie vor zwei grundlegende Probleme mit STARTTLS bei SMTP. Einerseits ist die Verwendung von STARTTLS bis heute optional. Gemäß dem Standard ist es nicht erforderlich, die Verbindung kryptografisch abzusichern, bevor die Mail übertragen wird. Zudem findet keine Prüfung der Authentizität des Zertifikats der Gegenstelle während der TLS-Aushandlung statt. So ist es nicht erforderlich, dass das vom Mailserver verwendete TLS-Zertifikat von einer öffentlich anerkannten Zertifizierungsstelle (CA) ausgestellt wurde, und auch der im Zertifikat angegebene Domainname muss nicht mit der E-Mail-Domain des sendenden Mailservers übereinstimmen.
Um den zuvor genannten Problemen zu begegnen, haben sich im Laufe der Jahre zahlreiche Mechanismen etabliert, die den Mailversand unabhängig vom SMTP-Protokoll sicherer gestalten sollen. Zu den wichtigsten gehören:
SPF, DKIM und DMARC sind miteinander kompatibel und können genutzt werden, um die eigene Mail-Domain gegen Missbrauch zu schützen. Konkret wird verhindert, dass Dritte Mails im Namen der eigenen Domain missbräuchlich versenden.
Mittels SPF kann festgelegt werden, welche IP-Adressen dazu autorisiert sind, E-Mails im Namen einer Domain (beispielsweise example.com) zu versenden. Die Realisierung erfolgt durch einen DNS-Eintrag für die eigene Domain, in dem die berechtigten IP-Adressen publiziert werden. Der empfangende Mailserver ruft den DNS-Eintrag der sendenden Mail-Domain ab und prüft, ob die IP-Adresse des sendenden Mailservers darin enthalten ist. Zudem besteht die Möglichkeit, im Eintrag festzulegen, wie sich der empfangende Mailserver im Falle einer nicht passenden IP-Adresse zu verhalten hat. So kann festgelegt werden, dass die E-Mail abgewiesen wird oder als Spam im Postfach des Empfängers gekennzeichnet wird. Ein typischer DNS-Eintrag für SPF sieht folgendermaßen aus:
Mithilfe von DKIM besteht die Möglichkeit, eine ausgehende E-Mail vom sendenden Mailserver digital zu signieren. Die Signatur umfasst insbesondere die Mail-Adressinformationen (Absender- und Empfängeradresse) und wird mit dem privaten Schlüssel des sendenden Mailservers erstellt und der Mail angehängt. Der dazugehörige öffentliche Schlüssel wird ebenfalls über einen DNS-Eintrag der Absenderdomain veröffentlicht und wird vom empfangenden Mailserver abgerufen, um die Signatur und damit die Integrität der empfangenen E-Mail zu überprüfen. Ein exemplarischer DNS-Eintrag zur Veröffentlichung des öffentlichen Schlüssels ist im Folgenden dargestellt:
Aufbauend auf den Mechanismen SPF und DKIM wurde DMARC eingeführt, um den Missbrauch der eigenen Mail-Domain weiter einzuschränken. Mittels der DMARC-Richtlinie wird festgelegt, wie das Empfänger-Mailsystem die Authentifizierung von E-Mails durchführen soll und wie im Falle einer Abweichung zu verfahren ist. Die Richtlinie wird über einen DNS-Eintrag der Absenderdomain veröffentlicht und vom empfangenden Mailserver abgerufen. Die Authentifizierungsprüfung erfolgt dabei mittels SPF sowie DKIM. Für eine erfolgreiche Prüfung einer empfangenen E-Mail nach DMARC muss entweder die SPF- oder die DKIM-Prüfung erfolgreich sein und die Absenderdomain mit der Domain in der E-Mail-Adresse des Absenders übereinstimmen. Darüber hinaus kann in der Richtlinie festgelegt werden, welche Maßnahmen bei einem fehlgeschlagenen Prüfvorgang zu ergreifen sind. So kann die E-Mail entweder verworfen oder in Quarantäne gestellt werden. Ein typischer DNS-Eintrag für DMARC sieht folgendermaßen aus:
Im Rahmen des sogenannten rua-Tags der Richtlinie besteht die Möglichkeit, eine E-Mail-Adresse zu spezifizieren, über die die Ergebnisse der DMARC-Prüfungen der eigenen Domain benachrichtigt werden sollen. Diese Vorgehensweise stellt ein effektives Mittel zur Identifizierung von Missbrauch der eigenen Mail-Domain dar. Die DMARC-Berichte, die in der Regel aggregiert sind, enthalten eine Auflistung aller Mailserver, einschließlich der IP-Adressen, die im vergangenen Zeitraum E-Mails im Namen der betreffenden Mail-Domain an die jeweilige Empfängerdomain versendet haben. Zudem lassen sich die Ergebnisse der Prüfungen nach SPF und/oder DKIM erkennen. Die Auswertung dieser Informationen ermöglicht die Identifizierung von Mailservern, die von Spammern genutzt werden, und die Meldung der entsprechenden IP-Adressen an öffentliche Spam-Listen bzw. IP-Blacklists. Diese Listen werden üblicherweise von den großen E-Mail-Providern wie Gmail oder Microsoft genutzt, um eine SMTP-Verbindung von solchen IP-Adressen direkt zu unterbinden.
Obwohl DMARC, SPF und DKIM für den Mailversand nicht obligatorisch sind, sind sie heutzutage weit verbreitet. Es trägt zur Steigerung der Reputation der eigenen Mail-Domain bei und reduziert das Risiko, dass die eigenen E-Mails von anderen Mailservern als Spam klassifiziert werden, sofern die zuvor genannten Mechanismen für die eigene Mail-Domain nicht implementiert sind.
Darüber hinaus wird empfohlen, dass der eigene Mailserver die SMTP-Erweiterung STARTTLS und damit den verschlüsselten Mailversand unterstützt und während der SSL/TLS-Aushandlung ein vertrauenswürdiges Zertifikat nutzt, das von einer öffentlich anerkannten CA für die eigene Mail-Domain ausgestellt wurde. Dies trägt zur Steigerung der Reputation des eigenen Mailsystems bei. Obwohl es möglich ist, STARTTLS und die Zertifikatsvalidierung bei einigen Mailservern (z. B. Postfix) zu erzwingen, würde dies gegen den entsprechenden RFC verstoßen. Dies könnte dazu führen, dass E-Mails von oder zu besonders alten Mailservern nicht zugestellt werden können. Um das Risiko des unverschlüsselten Versands von E-Mails im Internet dennoch zu minimieren, kann der Einsatz von MTA-STS hilfreich sein.
Im Kontext der Administration einer Mail-Infrastruktur besteht die Möglichkeit, mittels MTA-STS dem sendenden Mailserver durch einen DNS-Eintrag die Informationen zu übermitteln, dass der eigene Mailserver die Transportverschlüsselung mittels STARTTLS unterstützt und eine Zertifikatsprüfung durchgeführt werden kann.
Es sei darauf hingewiesen, dass Endnutzern in der Regel keine Möglichkeit zur Einflussnahme auf die Konfiguration von Mailservern zur Verfügung steht. Dies betrifft sowohl das Verschicken von E-Mails als auch deren Empfang. Ebenso ist es Endnutzern in der Regel nicht möglich, die ordnungsgemäße Umsetzung der zuvor genannten Maßnahmen zu überprüfen. Jedoch besteht für die Endnutzerin bzw. den Endnutzer die Möglichkeit, auf eine Ende-zu-Ende-Verschlüsselung mittels S/MIME oder PGP zurückzugreifen.
Sie möchten Ihre Infrastruktur auf die Probe stellen? Unsere Expertinnen und Experten aus dem Bereich Offensive Security beraten Sie gern.
Das Simple Mail Transfer Protocol (SMTP) stellt eines der am häufigsten verwendeten Netzwerkprotokolle im Internet dar und ist für den Mailversand zwischen den einzelnen Mailservern, wie beispielsweise Gmail, GMX oder T-Online, von essentieller Bedeutung. Das Protokoll wurde im Jahr 1981 im RFC 788 standardisiert und gehört somit zu den ältesten Netzwerkprotokollen. Es wurde jedoch nie mit der Intention entwickelt, einen sicheren Mailversand zu gewährleisten. Es ist bis heute als reines Transportprotokoll für E-Mails zu betrachten.
Bis in die 1990er Jahre war es im Internet gängige Praxis, dass Mailserver als sogenannte "Open Relays" fungierten. Jede Nutzerin und jeder Nutzer war in der Lage, mittels des Simple Message Transfer Protocol (SMTP) E-Mails mit beliebigen Absender- und Empfängeradressen über diese Mailserver zu versenden. Dies wurde zunehmend durch Spammer missbraucht, welche diese Server dazu nutzten, um E-Mails mit gefälschter Absenderadresse zu verteilen. Heutzutage gehört es zu einer der kritischsten Fehlkonfigurationen, wenn ein Mailserver die uneingeschränkte Weiterleitung von E-Mails erlaubt, ohne die Absenderadresse zu prüfen oder eine vorherige Authentifizierung zu verlangen. Das SMTP-Protokoll selbst bietet keinen direkten Schutz dagegen. Die Prüfung der Absenderadresse muss demnach durch den Mailserver selbst erfolgen, bevor eine E-Mail an den Mailserver der Empfangsadresse weitergeleitet wird. Empfehlenswert ist eine Konfiguration der Mailserver dahingehend, dass die Weiterleitung einer E-Mail erst nach erfolgter Authentifizierung des jeweiligen Nutzers des absendenden Postfaches innerhalb der SMTP-Sitzung sowie der Prüfung der Übereinstimmung der Absenderadresse mit dem jeweiligen Postfach erfolgt. Die Authentifizierung wurde erst 1999 mit dem RFC 2554 als Erweiterung im SMTP-Protokoll eingeführt.
Im Gegensatz zu HTTPS findet bei SMTP keine explizite Verschlüsselung via SSL/TLS statt. Der Kommunikationskanal zwischen zwei Mailservern wird stets unverschlüsselt aufgebaut. Zunächst existierte keine standardisierte Möglichkeit, E-Mails verschlüsselt zu versenden. Erst 1999 wurde mit dem RFC 2487 eine Erweiterung im SMTP-Protokoll eingeführt, die unter dem Namen STARTTLS bekannt ist und eine Verschlüsselung ermöglicht. Damit war es möglich, den anfänglich unverschlüsselten Kommunikationskanal via SSL/TLS zu verschlüsseln. Es existieren jedoch nach wie vor zwei grundlegende Probleme mit STARTTLS bei SMTP. Einerseits ist die Verwendung von STARTTLS bis heute optional. Gemäß dem Standard ist es nicht erforderlich, die Verbindung kryptografisch abzusichern, bevor die Mail übertragen wird. Zudem findet keine Prüfung der Authentizität des Zertifikats der Gegenstelle während der TLS-Aushandlung statt. So ist es nicht erforderlich, dass das vom Mailserver verwendete TLS-Zertifikat von einer öffentlich anerkannten Zertifizierungsstelle (CA) ausgestellt wurde, und auch der im Zertifikat angegebene Domainname muss nicht mit der E-Mail-Domain des sendenden Mailservers übereinstimmen.
Um den zuvor genannten Problemen zu begegnen, haben sich im Laufe der Jahre zahlreiche Mechanismen etabliert, die den Mailversand unabhängig vom SMTP-Protokoll sicherer gestalten sollen. Zu den wichtigsten gehören:
- SPF (Sender Policy Framework),
- DKIM (DomainKeys Identified Mail),
- DMARC (Domain-based Message Authentication, Reporting & Conformance),
- MTA-STS (Mail Transfer Agent-Strict Transport Security)
SPF, DKIM und DMARC sind miteinander kompatibel und können genutzt werden, um die eigene Mail-Domain gegen Missbrauch zu schützen. Konkret wird verhindert, dass Dritte Mails im Namen der eigenen Domain missbräuchlich versenden.
Mittels SPF kann festgelegt werden, welche IP-Adressen dazu autorisiert sind, E-Mails im Namen einer Domain (beispielsweise example.com) zu versenden. Die Realisierung erfolgt durch einen DNS-Eintrag für die eigene Domain, in dem die berechtigten IP-Adressen publiziert werden. Der empfangende Mailserver ruft den DNS-Eintrag der sendenden Mail-Domain ab und prüft, ob die IP-Adresse des sendenden Mailservers darin enthalten ist. Zudem besteht die Möglichkeit, im Eintrag festzulegen, wie sich der empfangende Mailserver im Falle einer nicht passenden IP-Adresse zu verhalten hat. So kann festgelegt werden, dass die E-Mail abgewiesen wird oder als Spam im Postfach des Empfängers gekennzeichnet wird. Ein typischer DNS-Eintrag für SPF sieht folgendermaßen aus:
Mithilfe von DKIM besteht die Möglichkeit, eine ausgehende E-Mail vom sendenden Mailserver digital zu signieren. Die Signatur umfasst insbesondere die Mail-Adressinformationen (Absender- und Empfängeradresse) und wird mit dem privaten Schlüssel des sendenden Mailservers erstellt und der Mail angehängt. Der dazugehörige öffentliche Schlüssel wird ebenfalls über einen DNS-Eintrag der Absenderdomain veröffentlicht und wird vom empfangenden Mailserver abgerufen, um die Signatur und damit die Integrität der empfangenen E-Mail zu überprüfen. Ein exemplarischer DNS-Eintrag zur Veröffentlichung des öffentlichen Schlüssels ist im Folgenden dargestellt:Aufbauend auf den Mechanismen SPF und DKIM wurde DMARC eingeführt, um den Missbrauch der eigenen Mail-Domain weiter einzuschränken. Mittels der DMARC-Richtlinie wird festgelegt, wie das Empfänger-Mailsystem die Authentifizierung von E-Mails durchführen soll und wie im Falle einer Abweichung zu verfahren ist. Die Richtlinie wird über einen DNS-Eintrag der Absenderdomain veröffentlicht und vom empfangenden Mailserver abgerufen. Die Authentifizierungsprüfung erfolgt dabei mittels SPF sowie DKIM. Für eine erfolgreiche Prüfung einer empfangenen E-Mail nach DMARC muss entweder die SPF- oder die DKIM-Prüfung erfolgreich sein und die Absenderdomain mit der Domain in der E-Mail-Adresse des Absenders übereinstimmen. Darüber hinaus kann in der Richtlinie festgelegt werden, welche Maßnahmen bei einem fehlgeschlagenen Prüfvorgang zu ergreifen sind. So kann die E-Mail entweder verworfen oder in Quarantäne gestellt werden. Ein typischer DNS-Eintrag für DMARC sieht folgendermaßen aus:Im Rahmen des sogenannten rua-Tags der Richtlinie besteht die Möglichkeit, eine E-Mail-Adresse zu spezifizieren, über die die Ergebnisse der DMARC-Prüfungen der eigenen Domain benachrichtigt werden sollen. Diese Vorgehensweise stellt ein effektives Mittel zur Identifizierung von Missbrauch der eigenen Mail-Domain dar. Die DMARC-Berichte, die in der Regel aggregiert sind, enthalten eine Auflistung aller Mailserver, einschließlich der IP-Adressen, die im vergangenen Zeitraum E-Mails im Namen der betreffenden Mail-Domain an die jeweilige Empfängerdomain versendet haben. Zudem lassen sich die Ergebnisse der Prüfungen nach SPF und/oder DKIM erkennen. Die Auswertung dieser Informationen ermöglicht die Identifizierung von Mailservern, die von Spammern genutzt werden, und die Meldung der entsprechenden IP-Adressen an öffentliche Spam-Listen bzw. IP-Blacklists. Diese Listen werden üblicherweise von den großen E-Mail-Providern wie Gmail oder Microsoft genutzt, um eine SMTP-Verbindung von solchen IP-Adressen direkt zu unterbinden.Obwohl DMARC, SPF und DKIM für den Mailversand nicht obligatorisch sind, sind sie heutzutage weit verbreitet. Es trägt zur Steigerung der Reputation der eigenen Mail-Domain bei und reduziert das Risiko, dass die eigenen E-Mails von anderen Mailservern als Spam klassifiziert werden, sofern die zuvor genannten Mechanismen für die eigene Mail-Domain nicht implementiert sind.
Darüber hinaus wird empfohlen, dass der eigene Mailserver die SMTP-Erweiterung STARTTLS und damit den verschlüsselten Mailversand unterstützt und während der SSL/TLS-Aushandlung ein vertrauenswürdiges Zertifikat nutzt, das von einer öffentlich anerkannten CA für die eigene Mail-Domain ausgestellt wurde. Dies trägt zur Steigerung der Reputation des eigenen Mailsystems bei. Obwohl es möglich ist, STARTTLS und die Zertifikatsvalidierung bei einigen Mailservern (z. B. Postfix) zu erzwingen, würde dies gegen den entsprechenden RFC verstoßen. Dies könnte dazu führen, dass E-Mails von oder zu besonders alten Mailservern nicht zugestellt werden können. Um das Risiko des unverschlüsselten Versands von E-Mails im Internet dennoch zu minimieren, kann der Einsatz von MTA-STS hilfreich sein.
Im Kontext der Administration einer Mail-Infrastruktur besteht die Möglichkeit, mittels MTA-STS dem sendenden Mailserver durch einen DNS-Eintrag die Informationen zu übermitteln, dass der eigene Mailserver die Transportverschlüsselung mittels STARTTLS unterstützt und eine Zertifikatsprüfung durchgeführt werden kann.
Es sei darauf hingewiesen, dass Endnutzern in der Regel keine Möglichkeit zur Einflussnahme auf die Konfiguration von Mailservern zur Verfügung steht. Dies betrifft sowohl das Verschicken von E-Mails als auch deren Empfang. Ebenso ist es Endnutzern in der Regel nicht möglich, die ordnungsgemäße Umsetzung der zuvor genannten Maßnahmen zu überprüfen. Jedoch besteht für die Endnutzerin bzw. den Endnutzer die Möglichkeit, auf eine Ende-zu-Ende-Verschlüsselung mittels S/MIME oder PGP zurückzugreifen.
Sie möchten Ihre Infrastruktur auf die Probe stellen? Unsere Expertinnen und Experten aus dem Bereich Offensive Security beraten Sie gern.