Spam und UCE - Filter: TLS

Für viele Administratoren unbemerkt hat sich mit Exchange 2007 eine Funktion den Weg zum Standard gebahnt, die mittelfristig ein effektiver Spamschutz und Phishingschutz sein könnte. Auf der Seite SMTP und die Sicherheit stelle ich die verschiedenen AbsicherungsMöglichkeiten einer Mailübertragung gegenüber. Der Einsatz von Zertifikaten auf dem Mailserver erlaubt es dem Versender, die Nachrichten zu verschlüsseln, so dass diese nicht auf dem Übertragungsweg abgehört werden können. Natürlich ist diese Verschlüsselung immer nur zwischen den MTAs vorhanden. Die Mail selbst ist unverschlüsselt und es gibt auch keine Weg eine Verschlüsselung über Relays zu erzwingen. Wenn der Versender ebenfalls ein Zertifikat hat, dann kann der Empfänger dessen Identität verifizieren. Auch wenn dies noch etwas Zukunftsmusik ist, so eröffnet diese Lösung interessante Aspekte. Betrachten wir diese erst einmal bezüglich Spam.

So funktioniert es

Ein großes Problem beim Thema SPAM ist die Anonymität des Absenders. Spammer verstecken sich hinter dynamischen IP-Adressen, offenen Relays und spamfreundlichen Providern. Anscheinend gibt es keine Anzeichen, dass sich die Betreiber des Internet (namentlich die Provider) gegen diese Machenschaften wehren, solange damit Geld zu verdienen ist.

Auf der anderen Seite ist SMTP ein sehr altes und damit vertrauensseliges Protokoll. Verschlüsselung und Identitätsprüfung waren lange Zeit nicht erforderlich. SMTP erlaubt aber schon länger die Nutzung von Zertifikaten zur Verschlüsselung und Signatur von SMTP-Verbindung (Nicht einzelner Mails !!). Im ersten Schritt könnten (und sollten) alle Mailserver ein Zertifikat anbieten und nutzen. Dies muss im ersten Schritt kein offizielles Zertifikat sein. auch ein privates Zertifikat erlaubt die Verschlüsselung von Daten auf dem Transportweg. Die Mailserver sollten dann selbst ein "StartTLS" anbieten und bei ausgehenden Verbindungen ein entsprechendes Angebot auch nutzen. Exchange 2007 tut das:

Opportunistic TLS Encryption
If the destination SMTP server supports TLS (via the “STARTTLS” SMTP command) when sending outbound e-mail from Exchange Server 2007, Exchange Server will automatically encrypt the outbound content using TLS. In addition, inbound e-mail sent to Exchange Server 2007 from the internet will be encrypted if the sending server supports TLS (Exchange Server 2007 automatically installs SSL certificates).
Quelle:http://www.microsoft.com/exchange/evaluation/features/default.mspx

Interessant wird dies, wenn man nun anhand dieser Zertifikate eine Wissensbasis aufbaut, welcher Server welches Zertifikat verwendet und man die Zertifikate noch bewertet, z.B. ein offizielle Zertifikat ist mehr wert. Dazwischen ist ein Zertifikat, welches durch eine ausgehende Verbindung eingesammelt wurde und am Ende stehen unbekannte Zertifikate. Zudem kann der Empfänger sich für "befreundete" Domains auch eine Liste von Zertifikaten anlegen, so dass die Verschlüsselung gefordert wird und eine Fälschung des Absenders nicht mehr möglich ist.

Das ist im wesentlichen die Triebfeder, warum dieses Verfahren in kurzer Zeit bei Firmen besonders interessant sein kann. Hiermit ist es möglich, Nachrichten an andere Firmen verschlüsselt und "firmen"-signiert zu senden, ohne aufwändige S/MIME oder PGP-Rollouts durchzuführen oder auf zentralen Virenschutz, Contentfilter und Archiv verzichten zu müssen. In der ersten Phase können quasi Partnerfirmen mit eigenen Zertifikaten sofort damit starten. Die Reputation von fremden Absendern kann dann durch öffentliche Zertifikate und entsprechende Sperrlisten geprüft werden. Aber selbst private Zertifikate sind möglich, wenn sich entsprechende "Clearingcenter" finden, die eine Zuordnung eines Server zu einem Zertifikat und einem Verhaltenskodex durchführen. Die Veröffentlichung des eigenen Zertifikats im DNS oder auf der Webseite könnte ähnlich zu DKIM ein wichtiger Schritt zur Verhinderung von Fälschungen sein, die zudem sehr früh erkannt und blockiert werden können.

Probleme

Auch wenn Exchange 2007 von Hause aus ein Selbstzertifikat installiert und alle Exchange Server intern mit TLS kommunizieren, so ist dies erst der erste Schritt. Viele Firmen schalten zwischen Exchange und Internet ein relativ "dummes" Relay, welches meist nur Spam, Viren und Empfänger prüft aber (noch) kein TLS unterstützt. Auch andere Mailserver können zwar schon TLS aber die wenigsten Administratoren haben entsprechende Zertifikate installiert. Insofern ist der Ansatz noch in einer sehr frühen Phase.

Solange die Mailserver keine offiziellen Zertifikate nutzen und ein Empfänger basierend darauf filtern oder blockieren kann, eignet sich dieses Verfahren auch noch nicht für eine effektive Spambekämpfung. Es ist sogar davon auszugehen, dass gerade Spammer sehr früh auch dieses Verfahren adaptieren und private Zertifikate anbieten. Als Spamschutz kann dieses System daher nur arbeiten, wenn öffentliche Zertifikate durch den Empfänger verpflichtend gemacht würden. Kaum ein Spammer würde sich anfangs die Mühe machen, ein öffentliches Zertifikat zu kaufen und zu nutzen.

Anders sieht es natürlich für Geheimdienste und Spione aus. Diversen Berichten zufolge verhindern Dienste (z.B. Echelon) die Nutzung von STARTTLS, indem sie diesen Befehl, der ja per Klartext aktiviert wird, einfach aus der Antwort entfernen. Ohne Kenntnis des STARTTLS-Befehls wird ein Sender diesen auch nicht verwenden. Selbst ein STARTTLS auf Verdacht wäre von solchen Stellen einfach abzufangen und mit einem Fehler zu quittieren.

Selbst mit erlaubtem STARTTLS könnte eine Zwischeninstanz immer noch eigene Zertifikate verwenden und damit den Verkehr über sich umleiten. für einen echten Schutz müssen Sie also mit Partnern STARTTLS erzwingen und das Zertifikat selbst überprüfen.

Wenn aber langfristig dieser Schutz sich durchsetzt, dann wird es auch immer mehr Sonderfälle geben, bei denen ein Absender als "Spammer" bezeichnet wird, während dieser nur von "normaler Werbung" spricht. Da der Absender diesmal aber nicht mehr "unbekannt" ist, können rechtliche Möglichkeiten umgesetzt werden. Unabhängig hiervon können nun aber auch wieder entsprechende Ratingsysteme effektiv arbeiten, die den Absendern eine gewisse Vertrauensstellung einräumen oder eben nicht. (Offenes Relay, Spamfreundlicher Provider etc.).

Potential

Aktuell ist der Spamschutz aufgrund "privater Zertifikate" noch gering anzusetzen ist. Aber die folgenden Argumente sollten Ihnen das Potential dieses Ansatzes aufzeigen.

  • Absender möchten sich "legitimieren" und investieren in ein Zertifikat
    Dies ist der einfachste und zugleich dezentrale Weg, seine "Kooperation" gegenüber den Empfängern zu belegen. Über ein offizielles Zertifikat kann eine Firma ihren Mailserver aus der Anonymität treten lassen. Damit fällt einer der größten Probleme bei Spam weg: Die Anonymität. Empfänger können diese Verbindungen annehmen oder über mehr oder minder statische Datenbanken bewerten. So können dann einfach auch offene Relays etc. blockiert werden, die mit einem öffentlichen Zertifikat senden. Vieleicht werden Mailserver dann auch ähnlich von Webseiten mit einem RSAC-Rating versehen.
  • Reputation aufgrund des Namens statt IP-Adressen
    Die "Bekanntheit" des absenden Mailservers durch das Zertifikat macht ihn von der IP-Adresse unabhängig, d.h. auch Firmen mit dynamischen IP-Adressen oder bei einem Providerwechsel können ungehindert arbeiten
  • Verschlüsselung und  Signierung "eingebaut"
    Quasi durch die Hintertür wird durch die Zertifikate auf dem Mailserver auch eine sichere verschlüsselte Übertragung garantiert. Wenn der empfangende Mailserver die Daten der Verbindung (Zertifikatname etc.) mit in den Header übernimmt, wäre sogar der Weg nachvollziehbar. Eine garantierte Verschlüsselung ist aber nur dann gegeben, wenn keine Relays (Stichwort Backup-MX) auf dem Weg ist.
  • Kompatibel mit Virenscanner, Contentscanner, Archiv, Compliance
    Da nur die Verbindung und nicht die Mail selbst verschlüsselt wird, hat der Mailserver selbst diese Nachricht unverschlüsselt und kann wie bisher mit Virenscanner, Contentregel und Archivfunktionen darauf zugreifen. für viele Firmen ist genau dies zwingend (Stichwort Konformität), weswegen in solchen Umfeldern eine Verschlüsselung mittels PGP und S/MIME sogar verboten ist bzw. blockiert wird

Aufgrund dieser Überlegungen bin ich ziemlich sicher, dass kommerzielle Firmen nicht nur ein privates sondern sogar offizielles Zertifikat für ihren Mailserver installieren werden und für bestimmte Domains sogar die Verschlüsselung bzw. zumindest die Signierung der Daten erzwingen. Es wird ebenfalls nicht lange dauern, bis andere Hersteller ihre Mailserver "TLS"-tauglich machen und Selbstzertifikate mit installieren. Aktuell bietet jeder Exchange 2007 Server von sich aus TLS an und nutze es auch, wenn die Gegenseite es anbietet. Das wird natürlich einen Spammer erst mal nicht abhalten, aber die bisherigen Filter sind ja uneingeschränkt weiter einsetzbar. Und irgendwann wird dann der Hebel umgelegt, dass Mailserver ohne richtiges Zertifikat nur noch Sender 2ter Klasse sind.

Ich hatte mich auch überlegt, ob es nicht genial einfach wäre, den eigenen Public Key einfach im DNS oder der Webseite zu veröffentlichen und damit den Zwang eines "öffentlichen Zertifikats" zu umgehen. Allerdings wäre es dann auch für Spammer ein leichtes damit vielleicht ein nicht vorhandenes Vertrauen zu erschleichen.
Wer richtig "mitreden" will, sollte die paar Euro/Jahr für ein offizielles Zertifikat locker investieren können.

Weitere Links