TLS-Nutzung: Wer, Wo, Was

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 mail.leisi.net der MX für die Domain leisi.net; im CN des Zertifikats steht ebenfalls mail.leisi.net). Analog zum Einsatz von Wildcards in CNs bei HTTPS wird dies auch bei TLS praktiziert (sehr intensiv beispielsweise von Postini).

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:

• Für Mailserver, die vor allem von Endkunden genutzt werden (zum Beispiel AOL, Bluewin usw), macht der Schutz des Transportweges durch TLS weniger Sinn.
• Manche Mailserver werden durch PIX Content Inspectors “geschützt”. Daseinsberechtigung für den Content Inspector ist das Misstrauen, welches gegenüber der Sicherheit mancher Mailserver-Software durchaus angebracht sein mag. Ob es sinnvoll ist, durch den Content Inspector auch TLS zu verhindern, bleibe dahingestellt.
• Das Know-How über SMTP/TLS ist manchenorts nicht sehr verbreitet. Sichere Verbindungen zwischen Mailservern werden im Firmenumfeld gerne über ein VPN getunnelt. Das skaliert zwar wesentlich schlechter, aber das entsprechende Know-How dürfte besser verbreitet sein (jeder Cisco- oder sonstwie netzwerkzertifizierte Admin hat zumindest schon mal von VPNs gehört).
• Die Betreiber von kleineren Mailservern (u.a. im Privatumfeld) dürften von den Kosten für Zertifikate abgeschreckt werden.

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.

Schlussfolgerungen

Der 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:

1. TLS für ein- und ausgehende Mails ermöglichen (PIX Content Inspector “entschärfen”, Mailserver TLS-fähig konfigurieren, Zertifikat Marke Eigenbau oder von einer Well-Known CA).
2. Beobachten des “Verifizierungserfolgs” der Zertifikate, und ggf. die CA Zertifikate der wichtigen Gegenstellen übernehmen.
3. Erzwingen von TLS (ohne Verifizierung) beim Senden von Mails an gewisse Gegenstellen.
4. Koordination mit der Gegenstelle, damit diese ebenfalls TLS (ohne Verifizierung) erzwingt.
5. Wechseln von TLS ohne Verifizierung auf TLS mit Verifizierung mit den wichtigen Gegenstellen.

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.