Sunday, August 27. 2006TLS-Nutzung: Wer, Wo, WasDie Artikelserie über sicheres E-Mail (siehe hier, hier, hier, hier und hier, weitere Teile in Vorbereitung) handelt von der grundsätzlichen Handhabung von SSL/TLS. Im Rahmen eines Projektes wollte ich testen, wie gut TLS bei Mailservern genutzt wird. Mit Hilfe eines Scripts,
Vorab zur Interpretation der Resultate: Die Liste der Domains wurde aus einer Spam-Whitelist extrahiert, es handelt sich also nicht um einen repräsentativen Querschnitt durch das Internet als solches; diese Whitelist enthält nicht nur solche Domains, bei denen es tatsächlich schon zu false positives gekommen ist, sondern auch “vorsorgliche” Einträge für wichtige Partnerfirmen. Da die Whitelist für ein Unternehmen der Finanzindustrie gepflegt wird, sind naturgemäss Einträge aus eben dieser Branche übervertreten. Daneben enthält die Whitelist aber auch viele Einträge anderer Branchen (zum Beispiel aus der Reiseindustrie, welche notorisch ist für ihre false positives — ich rieche da einen Beratungsbedarf…). Aggregierte Daten
Der Content Inspector der PIX Firewall erlaubt es, dahinter liegende Mailserver zu schützen; dazu wird der SMTP-Datenstrom auf im Sinne des Content Inspectors unerwünschte Merkmale untersucht. Erkannte Befehle und Antworten werden durch “****” ersetzt (zum Beispiel “EHLO”, “STARTTLS”).
Mailservern steht es frei, neben ihrem eigenen auch die zugehörigen CA-Zertifikate auszuliefern, allenfalls über mehrere Stufen. Manche Domains teilen sich den gleichen Mailserver, und damit auch das gleiche Server Zertifikat. Besonders augenfällig ist dies bei Mail-Dienstleistern wie Postini oder MessageLabs. Da MessageLabs zum Zeitpunkt des Tests Probleme mit der Auslieferung der vollständigen Zertifikate hatten, fehlen 25 Server Zertifikate (Differenz zwischen 280 TLS-fähigen Servern und 265 erhaltenen Server Zertifikaten).
Als “verifizierbar” wurde ein Zertifikat dann angesehen, wenn es von einem der CA-Zertifikate von OpenSSL ausgestellt und signiert wurde (OpenSSL Version 0.9.8a). Eine der Strategien zur Überprüfung der Gültigkeit von TLS-Zertifikaten ist, die Übereinstimmung zwischen dem Namen im MX-Record und im CN-Feld des Zertifikats zu überprüfen (beispielsweise ist
Durch das weit verbreitete Outsourcing von Mailempfang und -versand wird die Verteilung der CA-Zertifikate verzerrt (ähnliches sieht man zum Beispiel in der Webserver-Statistik, wenn ein “Domainparker” zwischen IIS und Apache wechselt).
Die MessageLabs eigene CA (s. unten) wurde zu den “Well-Known” gezählt, da es wohl sinnvoll ist, Zertifikaten eines derart weit verbreiteten Dienstleisters zu vertrauen.
InterpretationÄhnlich wie bei den in Browsern oder Mailprogrammen eingebauten Zertifikaten sieht man auch beim Einsatz von TLS neben der Häufung von “Well-Known” Certificate Authorities eine Vielzahl von Zertifikaten Marke Eigenbau (wie sie die erwähnte Artikelserie ebenfalls beschreibt). Der Netzwerkeffekt ist nicht ganz so stark wie bei millionenfach installierter Endbenutzer-Software, weil einerseits einigermassen Wissende Administratoren leicht CA Zertifikate hinzufügen und löschen können; trotzdem ist es organisatorisch sinnvoll, sich auf (sagen wir mal) 10 CA Zertifikate verlassen zu können, als dass jeder von (angenommen) 100 Administratoren mit jedem Einzelnen die Zertifikate austauschen muss. Unter diesem Aspekt sind die auf den ersten Anschein völlig überrissenen Preise für Server Zertifikate nicht überraschend: Aus wirtschaftlicher Perspektive lohnt es sich allemal (und man kann im Allgemeinen davon ausgehen, dass die “Well-Known” CAs weniger Fehler machen als wenn jeder selbst basteln würde). Es gibt viele Gründe, warum 70% der Mailserver kein TLS anbieten. Einige mögliche Gründe sind:
Konsequenterweise sind es dann auffallend häufig Mail-Outsourcing-Anbieter und grössere Firmen, welche TLS im Einsatz haben, und diese haben zu einem grossen Teil verifizierbare Zertifikate. Zudem ist auffällig, dass viele Banken TLS einsetzen. Offenbar ist das Bewusstsein für den Bedarf an Transportverschlüsselung bei diesen grösser als bei anderen. SchlussfolgerungenDer Einsatz von TLS macht besonders dann Sinn, wenn die “häufigsten” oder “wichtigsten” Partner ebenfalls TLS unterstützen. Im Business-to-Business-Umfeld mit relativ stabiler Anzahl von Partnern ist der Nutzen besonders hoch, und wird durch den Einsatz von verifizierbaren Zertifikaten noch erhöht. Selbst Eigenbau-Zertifikat bringen bereits einen deutlichen Nutzen, werden dadurch doch zumindest zufällige Mitlauscher ausgeschlossen. Gegen eine fortgeschrittene “Man-in-the-middle”-Attacke nützen selbstverständlich nur verifizierbare Zertifikate. Um den Verkehr zwischen zwei Partnern wirksam zu schützen, müssen die Zertifikate nicht nur verifiziert werden, sondern es muss auch sichergestellt werden, dass die Mails zwischen den Partnern nur über SMTP/TLS ausgetauscht werden (zum Beispiel um sich gegen DNS-basierte Angriffe zu schützen). In welchem Ausmass das tatsächlich gemacht wird, lässt sich mit den vorliegenden Tests und Testdaten nicht prüfen. Dazu wäre Einblick in die jeweiligen Policies notwendig.Trotzdem lässt sich eine Reihenfolge von wünschbaren Schritten beim Einsatz von SMTP/TLS aufstellen:
Im Business-to-Business-Umfeld macht es natürlich Sinn, wenn diese gegenseitige Koordination nicht zwischen den einzelnen Peers direkt, sondern zum Beispiel über Branchenorganisationen abläuft. Damit wird der Aufwand für alle Beteiligten deutlich reduziert, und eine durchgängige Sicherung des Mailverkehrs wird wesentlich beschleunigt. Anhang: TLS und SpamÜber den Beobachtungszeitraum von einer Woche wurde genau ein Spam gefunden, welches über SMTP/TLS eingeliefert wurde (via einen gekaperten Rechner an einer Uni, der via den Mailserver der Uni ausgeliefert hat). Der Einsatz von SMTP/TLS könnte also helfen, zumindest false positives von Spamfiltern zu reduzieren. Einen wirklichen Schutz vor Spam, Phishing etc bietet SMTP/TLS aber nicht, da die aller meisten Mailprogramme nicht anzeigen (können), ob eine Nachricht über einen sicher verifizierten Kanal eingeliefert wurde. Trotzdem bietet SMTP/TLS ein gewisses Potential zum Schutz vor einigen Formen von Missbrauch von E-Mail. |
QuicksearchSicheres E-MailEinführung
CA Postfix Cyrus IMAP Apache Signieren Postfix: TLS erzwingen für eingehende / ausgehende Mails TLS Statistik Test-Script OpenSSL Cheat Sheet Blog abonnierenBlog AdministrationRights & Wrongs |

Add Google Reader
Ein Untersuchung der Zürcher Hochschule Winterthur aus dem Jahr 2004 ergibt, dass 30% der Mailserver für aktive .ch- und .li-Domains TLS unterstützen. Das stimmt erstaunlich gut mit meiner eigenen Untersuchung überein, die ebenfalls au
Tracked: Sep 02, 10:50