Um es nochmal klar zu sagen:
gegen das Mitlauschen durch Sicherheitsbehörden aller Art hilft eine
SSL-Verschlüsselung des Transportwegs in den weitaus meisten Fällen
exakt gar nicht, denn diese holen sich die Daten direkt von den
Mailservern.
Außerdem muß SSL selbst als kompromittiert betrachtet werden, denn es
existieren gefälschte Zertifikate für root CAs und es ist außerdem
davon auszugehen, daß zumindest alle amerikanischen root CAs ihre
Private Keys längst bei der NSA abgeliefert haben oder diese dort
erschnüffelt wurden. Im Klartext: SSL ist vollständig kompromittiert!
Aber selbst wenn man SSL für "ausreichend sicher" hält, hilft das nur
bedingt gegen einen einzigen Angriffsvektor, der noch dazu nicht
wirklich einer ist: gegen das Mitlesen bei der Übertragung zwischen
Mailservern. Dies ist allerdings auch mit SSL möglich, wenn man eine
Man-in-the-middle-Attack betreiben kann - und wer Traffic mitlesen
kann, kann ihn in aller Regel auch umleiten oder manipulieren. Da
eine manuelle Zertifikatsprüfung zwischen unbekannten Hosts für
Provider nicht praktikabel ist, gibt es im Rahmen von SMTP/SSL keine
funktionierende Maßnahme gegen "MITM"-Angriffe.
Der einzige praktisch auftretende Fall, in dem SMTP/SSL wirklich
einen Sicherheitsgewinn bringt, ist die Verwendung von SMTP AUTH.
Das findet aber praktisch nie zwischen "großen" Mailservern statt,
sondern nur wenn ein Absender eine E-Mail bei seinem Smarthost
einliefert. In diesem einen, speziellen Fall ist SSL sinnvoll, um die
SMTP AUTH Zugangsdaten vor unbefugtem Mitlesen auf dem
Übertragungsweg zu schützen. Gegen ein lesen der Zugangsdaten auf dem
Provider- oder Kundenrechner (z.B. mit Malware) hilft das aber auch
nicht.
In allen anderen Fällen hingegen erhöht SSL nur massiv den Aufwand
(Rechenleistung, Speicher, Zertifikatsmanagement) und die
Komplexität, ohne einen Sicherheitsgewinn zu bringen. Da
Sicherheitsrisiken proportional zur Komplexität steigen, wird das
System im Gegenteil sogar prinzipbedingt unsicherer.
Was ansonsten in Grenzen hilft, ist Ende-zu-Ende-Verschlüsselung. In
Grenzen, weil:
- sie hilft nicht, wenn der Private Key eines Kommunikationspartners
kompromittiert wird. Das ist bereits der Fall, wenn dieser einen
Webmailer zum Verschlüsseln benutzt, den Key auf fremder Hardware
(Internet-Cafe o.ä.) exponiert oder sich einen Key "extern" erzeugen
läßt. Nur ein persönlich selbst erzeugter Private Key, den man unter
keinen Umständen aus der Hand gibt und der niemals den eigenen
Rechner verläßt, bietet überhaupt so etwas wie Sicherheit!
- Ende-zu-Ende-Verschlüsselung kann prinzipbedingt keine Metadaten
schützen. Diese können bei E-Mails gar nicht gegen das Ausspähen auf
Provider-Hosts geschützt werden. Die einzige Maßnahme, Metadaten zu
schützen, wäre eine direkte Übertragung "am Provider vorbei" zum
Empfänger, was aber nur für Inhouse-Mails praktikabel ist.
Indes macht Ende-zu-Ende-Verschlüsselung SSL auf dem Transportweg
erst Recht überflüssig, weil die zu schützenden Inhalte dort dann
ohnehin schon geschützt sind.
gegen das Mitlauschen durch Sicherheitsbehörden aller Art hilft eine
SSL-Verschlüsselung des Transportwegs in den weitaus meisten Fällen
exakt gar nicht, denn diese holen sich die Daten direkt von den
Mailservern.
Außerdem muß SSL selbst als kompromittiert betrachtet werden, denn es
existieren gefälschte Zertifikate für root CAs und es ist außerdem
davon auszugehen, daß zumindest alle amerikanischen root CAs ihre
Private Keys längst bei der NSA abgeliefert haben oder diese dort
erschnüffelt wurden. Im Klartext: SSL ist vollständig kompromittiert!
Aber selbst wenn man SSL für "ausreichend sicher" hält, hilft das nur
bedingt gegen einen einzigen Angriffsvektor, der noch dazu nicht
wirklich einer ist: gegen das Mitlesen bei der Übertragung zwischen
Mailservern. Dies ist allerdings auch mit SSL möglich, wenn man eine
Man-in-the-middle-Attack betreiben kann - und wer Traffic mitlesen
kann, kann ihn in aller Regel auch umleiten oder manipulieren. Da
eine manuelle Zertifikatsprüfung zwischen unbekannten Hosts für
Provider nicht praktikabel ist, gibt es im Rahmen von SMTP/SSL keine
funktionierende Maßnahme gegen "MITM"-Angriffe.
Der einzige praktisch auftretende Fall, in dem SMTP/SSL wirklich
einen Sicherheitsgewinn bringt, ist die Verwendung von SMTP AUTH.
Das findet aber praktisch nie zwischen "großen" Mailservern statt,
sondern nur wenn ein Absender eine E-Mail bei seinem Smarthost
einliefert. In diesem einen, speziellen Fall ist SSL sinnvoll, um die
SMTP AUTH Zugangsdaten vor unbefugtem Mitlesen auf dem
Übertragungsweg zu schützen. Gegen ein lesen der Zugangsdaten auf dem
Provider- oder Kundenrechner (z.B. mit Malware) hilft das aber auch
nicht.
In allen anderen Fällen hingegen erhöht SSL nur massiv den Aufwand
(Rechenleistung, Speicher, Zertifikatsmanagement) und die
Komplexität, ohne einen Sicherheitsgewinn zu bringen. Da
Sicherheitsrisiken proportional zur Komplexität steigen, wird das
System im Gegenteil sogar prinzipbedingt unsicherer.
Was ansonsten in Grenzen hilft, ist Ende-zu-Ende-Verschlüsselung. In
Grenzen, weil:
- sie hilft nicht, wenn der Private Key eines Kommunikationspartners
kompromittiert wird. Das ist bereits der Fall, wenn dieser einen
Webmailer zum Verschlüsseln benutzt, den Key auf fremder Hardware
(Internet-Cafe o.ä.) exponiert oder sich einen Key "extern" erzeugen
läßt. Nur ein persönlich selbst erzeugter Private Key, den man unter
keinen Umständen aus der Hand gibt und der niemals den eigenen
Rechner verläßt, bietet überhaupt so etwas wie Sicherheit!
- Ende-zu-Ende-Verschlüsselung kann prinzipbedingt keine Metadaten
schützen. Diese können bei E-Mails gar nicht gegen das Ausspähen auf
Provider-Hosts geschützt werden. Die einzige Maßnahme, Metadaten zu
schützen, wäre eine direkte Übertragung "am Provider vorbei" zum
Empfänger, was aber nur für Inhouse-Mails praktikabel ist.
Indes macht Ende-zu-Ende-Verschlüsselung SSL auf dem Transportweg
erst Recht überflüssig, weil die zu schützenden Inhalte dort dann
ohnehin schon geschützt sind.